本来吃老本，在小公司写前端业务逻辑代码，总是兴趣不大。代码写着写着，思维就发散，上网东看看，西逛逛，一天时间很容易流失。

后来闲了一段时光，写了一小段时间的轮子后，发现又开始重拾对编程的兴趣。连番茄工作法都不需要，所谓兴趣就是最好的老师，加班都能自觉主动，完成后也很有成就感。

感觉码农这条路要坚持走下去，有两点必不国外服务器可少。

一是自我价值的认同。（虽然老板每次都说代码好，业务向更重要，但业内人人都能写的基础逻辑脚本，人员随时可以被替代，项目随时可能被舍弃，自己完全不觉得有什么好的）

二是代码的累积效应。不能一个项目写完了，历史代码就扔掉。（虽然这很难，在团队协作里，不可能总能随心所欲用上自己喜欢的技术，技术偏向总要有取舍。）

因为造轮子的最终受益者是你，决策者也是你；写业务逻辑是为公司写的，老板是受益者和决策者，你只是老板的笔而已。
这两者差异巨大

黄脸婆和小秘咯

写业务的 curd 是帮别人养孩子。。造轮子是养自己孩子。。。

因为造轮子可以让你一年积累两年的工作经验，写业务只会让你十年积累一年的工作经验

写业务代码，很多都是重复性的东西，增删改查。。。
造轮子是富有挑战性的东西。但是最好想想再放在项目上去，搞不好会被人骂。。。

造了升值加薪答辩有的说、你总不能在晋升的时候说自己一直 crud 没点技术创新把。

CRUD 也是有讲究的，你看，实际上就两种操作，一种是修改，一种是查询。
简单的 CRUD 从前端到后端甚至数据库字段都完全一致，就是面向数据库编程，Service 都不需要。
复杂一点的，把这两种操作当成两套代码来写：
修改操作多以动词命名，会精炼出业务的实际需要的操作列表，把他们全部放在 Service 里面，每一个方法就是一个事务，或者使用门面模式封装独立的命令执行（命令模式）。
查询操作完全取决于你的消费方需要什么样的数据，把查询的逻辑处理全部放到 Repository 里面，返回 View 或者 DTO 啥的，只专注于如何批量查询并组合成需要的数据，可以是 SQL，可以是 HTTP 请求。很多人喜欢把查询也放到 Service 中，但实际上两者的关注点是不一样的。
读写分离以后好处是显而易见的，查询和修改都可以单独进行优化，最重要的是更加清晰可读。
当然以上只是一种方法，从技术上来讲，写业务代码最大的难度和关键点在于需求是否足够清晰，领域知识是否完备。反之造轮子则不需要这些额外的知识，但终究来讲轮子也是服务于某一个技术点的，最终也是要服务于业务的。

同感

道理都懂，就是写 CRUD，时间一长，很难保持极大的写代码热情。
就算有点热情，也会迅速被各种需求 /开会 /沟通成本给浇灭。只想早点写完，早点收工。代码一把梭，也不会刻意去考虑复用问题。
而且你团队开发，一个人写的爽没用，你使劲的往里搬水，团队里总有菜鸟，木桶的最短板在给你往外漏水。修修补补查 BUG，一天又一天。
写轮子不一样，真的可以自己怎么爽，怎么来，随心所欲写，才是兴趣冒泡的源头。

为什么不把业务代码封装成轮子，两不误