本站于2023年9月4日。收到“大连君*****咨询有限公司”通知
说我们IIS7站长博客，有一篇博文用了他们的图片。
要求我们给他们一张图片6000元。要不然法院告我们

为避免不必要的麻烦，IIS7站长博客，全站内容图片下架、并积极应诉
博文内容全部不再显示，请需要相关资讯的站长朋友到必应搜索。谢谢！

另祝：版权碰瓷诈骗团伙，早日弃暗投明。

相关新闻：借版权之名、行诈骗之实，周某因犯诈骗罪被判处有期徒刑十一年六个月

叹！百花齐放的时代,渐行渐远!

---

     并不是代码写的越多，代码的质量就越高。思考才是。

     解决一个问题，打开电脑就手撕代码，最终的结果往往是各种代码问题，经过一系列迭代后，代码积重难返，最终的结果就是推到重来，前期的付出都白费，最典型的就是现在所谓的敏捷，听起来高大上，实际落地其实就是加班，因为没有时间思考。

     现在的很多公司已经不尊重科学和客观规律了，如果让他来管理孕妇，我觉得他们恨不得要把 10 个月的产期缩短成 2 个月。

     程序员应该坚持自己的良质，不能因为产品经理或老板而改变一些非常好的做事方法，很多问题都是可以通过沟通解决的，面对复杂的需求工期又特别短，不妨听下陈皓老师（网名：左耳朵耗子）的方法：不要说不，而是给对方选择：

     1、我可以加班加点完成，但是我不保证好的质量，有 bug 你得认，而且事后你要给我 1 个月的时间还债。

     2、我可以加班加点，还能保证质量，但我没办法完成这么多需求，能不能减少一些？

     3、我可以保质保量地完成所有的需求，但是，能不能多给我 2 周时间？

     看到这里，我想你也一定会认为：除了编程，沟通也是一门艺术。

     这两天学到了王争的专栏《设计模式之美》，其中提到的如何发现代码质量问题，可以从以下几个方面审视代码：

     目录设置是否合理、模块划分是否清晰、代码结构是否满足“高内聚、松耦合”？

     是否遵循经典的设计原则和设计思想（SOLID、DRY、KISS、YAGNI、LOD 等）？

     设计模式是否应用得当？是否有过度设计？

     代码是否容易扩展？如果要添加新功能，是否容易实现？

     代码是否可以复用？是否可以复用已有的项目代码或类库？是否有重复造轮子？

     代码是否容易测试？单元测试是否全面覆盖了各种正常和异常的情况？

     代码是否易读？是否符合编码规范（比如命名和注释是否恰当、代码风格是否一致等）？

     以上是一些通用的关注点，可以作为常规检查项，套用在任何代码的重构上。除此之外，我们还要关注代码实现是否满足业务本身特有的功能和非功能需求。还有一些比较有共性的问题，如下所示。

     代码是否实现了预期的业务需求？

     逻辑是否正确？是否处理了各种异常情况？

     日志打印是否得当？是否方便 debug 排查问题？

     接口是否易用？是否支持幂等、事务等？

     代码是否存在并发问题？是否线程安全？

     性能是否有优化空间，比如，SQL、算法是否可以优化？

     是否有安全漏洞？比如输入输出校验是否全面？

     当看到这些时，我只觉得醍醐灌顶，写代码并不难，难的是写出好代码，什么是好代码，质量高的代码？以上 14 条问题给我们指明了方向。

     以上共 14 个方面值得打印出来贴在桌子上，作为我们日常写代码的一个提示，解决这些问题过程虽然耗时，假以时日，我们一定可以写出非常优秀的代码，成为优秀的工程师。

文章来源：CSDN博客

原文链接：https://blog.csdn.net/somenzz/article/details/105592007

如有侵权，请联系本人删除