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