没错，其实说透了，写程序就是使用特定的编程语言进行CRUD（增删改查）。
作为程序员，在实际工作中需要做的事情本质上就是：把产品需求转化为程序，把产品逻辑转化为代码逻辑。
梳理产品逻辑：
产品给出的是产品原型、需求文档，你需要根据产品原型、需求文档，梳理出产品逻辑。
产品本身只关注输出的产品是否满足客户的需求，可能着眼点并不在如何实现上，逻辑是否合理上，尤其是没有技术背景的产品。这时，作为后端开发人员，需要去构想几件事情：
- 这个页面需要几个接口，这些接口分别返回什么数据？
- 根据整体的产品原型，进行核心概念领域划分：订单、库存、商品、用户、积分、还有其他什么吗？
- 以上核心概念之间是否有关联？如何关联的：新增订单时，会影响库存吗？用户下单后会影响积分吗？
就是上面的三件事情，第一件事情可以让你学会设计接口；第二件事情可以让你透过现象看到本质，抓住核心概念，设计数据库表；第三件事情，可以让你梳理清楚某个功能会涉及到哪些表的增删改查。
好，那么看来不是简简单单的CRUD了，是基于产品需求表象，深入挖掘出核心概念，然后梳理清楚几个核心概念之间的关联，然后几个核心概念相关联的CRUD。
系统设计：
要实现这个功能，需要使用那些中间件：需要使用缓存吗？需要使用消息中间件吗？需要使用定时任务吗？我们的场景有哪些特殊之处吗？针对这些场景应该如何去技术选型？
要使用单体还是微服务？需要进行服务下层吗？要如何进行服务划分？粒度粗一点好还是细一点好？
系统面对的并发量有多大？需要如何条件Tomcat参数？需要部署多少个实例？需要如何调节JVM参数？数据库可以承载这样的并发吗？
数据量是怎样的？Mysql可以满足吗？
接口设计 ：
Web接口设计满足个性化，只针对性的满足某个页面需要的数据。
RPC接口设计要满足通用化，你的RPC接口会有很多人调用到，复用率比较高，比如一个查询订单的接口，返回的订单BO字段应该尽量冗余，A会需要订单基本数据，B会需要订单联系人的手机号码，C会需要订单对应的商品名称等等。
表设计：
表设计一般情况下还是要满足三大范式。
字段尽量不要冗余，一旦字段冗余，查询时候是方便了，但是更新时就容易因为更新不到而导致脏数据。
字段长度要合理，对于手机号而言，varchar(20)足矣，没有手机号可以超过20位，如何使用默认的varchar(255)就平白无故地增加空白空间，在查询、更新等操作时给Mysql造成不必要的负担。
写代码：
没想到吧，最后一步才是写代码，只要思路清晰了，代码会很清晰。
上面我们已经根据梳理出了产品逻辑，所谓的产品逻辑，可以类比于：
新增订单：
1.插入一条订单；2.删减订单对应商品的库存；3.根据指定的规则给下订单的用户增加积分。
写代码时，也应该是在“搭积木”，而不是“玩泥巴”。
搭积木：先根据产品逻辑确定代码框架，先把主流程写出来，把需要的方法定义写出来（要对定义的方法有明确清晰的定义），然后再慢慢往里面填代码。
玩泥巴：根据思路写到哪里算哪里，从前到后，没有思维框架，拖泥带水，方法没有做到复用，逻辑重复。
最后总结一下，只要掌握正确的方法，写代码不过就是根据事先梳理出来的产品逻辑，用搭积木的方式把产品逻辑转化为代码逻辑而已。SO EASY