最近有幸接手到一个成年老项目，看到一些问题，整理一下。

不要使用Map作为返回值

强烈呼吁不要使用Map作为返回值，它的唯一好处是开发速度快，但是因为那一点点的开发速度，降低代码的可读性、可维护性，是非常不划算的。他会导致几个问题，新人接手不能从返回值中了解到业务，而是要一层一层的跟进到SQL层面；还有就是如果数据库值为null，返回的Map中又无对于的key，前端同学就会很纳闷，怎么每条数据返回的数据结构都不一致。

不在SQL里处理业务逻辑

最近修改一个迭代近10年的老项目，由于迭代时间久，业务功能很丰富，这次需要重启一个业务模块，由于无文档，业务配置项不知道入口在哪里，所以只能从代码里面查找对应功能，看到了该模块很多几屏都放不下的SQL，SQL里面有各种子查询、三元运算符，看得人是眼花缭乱，基本所有的业务，都揉杂在SQL里面了，调试也无从下手，也无备注。为了方便后续人员进行问题排查和了解业务，不要在SQL里面处理业务，可读性差，不方便业务功能调试，正确的方式应该是利用代码来处理业务逻辑。

从工具职能上解决问题

看到很多代码，总喜欢跨职能来解决问题，数据库有脏数据问题，正确的方式应该是找到脏数据产生的根因并进行生产数据修复；错误的方式就是在使用数据的时候，去处理数据，比如说从业务出发某记录数应该是不重复的，但是在使用的时候发现了重复数据，立即写代码来处理该重复数据问题。数据问题，就应该从数据上去处理好，找到根因，处理好脏数据。而不是本来是数据的工作，错误的利用代码来写逻辑处理。

结语

最近在工作中有两点感悟，一是简单的编程规则很容易掌握，但是让一个团队在工作中好好的运用这些规则，又会很难。二是把简单的、常识性的知识点运用到实际工作中，就已经胜过了80%的人。技能型的知识学习是为了运用，而不是为了徒增理论知识，先把简单的知识运用到工作中，然后再去琢磨新技术、新语法吧。