阅读本文大概需要 2.6 分钟。
并不是代码写的越多，代码的质量就越高。思考才是。
解决一个问题，打开电脑就手撕代码，最终的结果往往是各种代码问题，经过一系列迭代后，代码积重难返，最终的结果就是推到重来，前期的付出都白费，最典型的就是现在所谓的敏捷，听起来高大上，实际落地其实就是加班，因为没有时间思考。
现在的很多公司已经不尊重科学和客观规律了，如果让他来管理孕妇，我觉得他们恨不得要把 10 个月的产期缩短成 2 个月。
程序员应该坚持自己的良质，不能因为产品经理或老板而改变一些非常好的做事方法，很多问题都是可以通过沟通解决的，面对复杂的需求工期又特别短，不妨听下陈皓老师（网名：左耳朵耗子）的方法：不要说不，而是给对方选择：
1、我可以加班加点完成，但是我不保证好的质量，有 bug 你得认，而且事后你要给我 1 个月的时间还债。
2、我可以加班加点，还能保证质量，但我没办法完成这么多需求，能不能减少一些？
3、我可以保质保量地完成所有的需求，但是，能不能多给我 2 周时间？
看到这里，我想你也一定会认为：除了编程，沟通也是一门艺术。
这两天学到了王争的专栏《设计模式之美》，其中提到的如何发现代码质量问题，可以从以下几个方面审视代码：
目录设置是否合理、模块划分是否清晰、代码结构是否满足“高内聚、松耦合”？
扫描二维码关注公众号，回复： 11094697 查看本文章
是否遵循经典的设计原则和设计思想（SOLID、DRY、KISS、YAGNI、LOD 等）？
设计模式是否应用得当？是否有过度设计？
代码是否容易扩展？如果要添加新功能，是否容易实现？
代码是否可以复用？是否可以复用已有的项目代码或类库？是否有重复造轮子？
代码是否容易测试？单元测试是否全面覆盖了各种正常和异常的情况？
代码是否易读？是否符合编码规范（比如命名和注释是否恰当、代码风格是否一致等）？
以上是一些通用的关注点，可以作为常规检查项，套用在任何代码的重构上。除此之外，我们还要关注代码实现是否满足业务本身特有的功能和非功能需求。还有一些比较有共性的问题，如下所示。
代码是否实现了预期的业务需求？
逻辑是否正确？是否处理了各种异常情况？
日志打印是否得当？是否方便 debug 排查问题？
接口是否易用？是否支持幂等、事务等？
代码是否存在并发问题？是否线程安全？
性能是否有优化空间，比如，SQL、算法是否可以优化？
是否有安全漏洞？比如输入输出校验是否全面？
当看到这些时，我只觉得醍醐灌顶，写代码并不难，难的是写出好代码，什么是好代码，质量高的代码？以上 14 条问题给我们指明了方向。
以上共 14 个方面值得打印出来贴在桌子上，作为我们日常写代码的一个提示，解决这些问题过程虽然耗时，假以时日，我们一定可以写出非常优秀的代码，成为优秀的工程师。
推荐阅读：
