【工作总结】后端开发人员的坏习惯

前言

每位开发人员在自己的职业生涯、学习经历中，都会出一些坏习惯。
本文将列举开发人员常犯的坏习惯。希望大家能够意识和改变这些坏习惯。

一、不遵循项目规范

每个公司都会定义一套代码规范、代码格式规范、提交规范等，但是有些开发人员就是不遵循相关的 规范，命名不规范、魔鬼数字、提交代码覆盖他人代码等问题经常发生，如果大家能够遵循相关规范，这些问题都可以避免。
可参考我之前写的文章：sonar的安装以及使用

二、用复杂SQL语句来解决问题

程序员在开发功能时，总想着是否能用一条SQL语句来完成这个功能，于是实现的SQL语句写的非常复杂，包含各种子查询嵌套，函数转换等。这样的SQL语句一旦出现了性能问题，很难进行相关优化。
可参考我之前写的文章：MySQL表设计的经验

三、缺少全局把控思维，只关注某一块业务

新增新功能只关注某一小块业务，不考虑系统整体的扩展性，其他模块已经有相关的实现了，却又重复实现，导致重复代码严重。修改功能不考虑对其他模块的影响。
可参考我之前写的文章：这7种UML图的画法每个程序员都应该掌握

四、函数复杂冗长,逻辑混乱

一个函数几百行，复杂函数不做拆分，导致代码变得越来月臃肿，最后谁也不敢动。函数还是要遵循设计模式的单一职责，一个函数只做一件事情。如果函数逻辑确实复杂，需要进行拆分，保证逻辑清晰。
可参考我之前写的文章：谈谈我们工作中的23个设计模式

五、缺乏主动思考，拿来主义

实现相关功能，先网上百度一下，拷贝相关的代码，能够运行成功认为万事大吉。到了生产却出现了各种各样的问题，因为网上的demo程序和实际项目的在场景使用上有区别，尤其是相关的参数配置，一定要弄清楚具体的含义，不同场景下，设置参数的值不同。
可参考我之前写的文章：如何写出整洁的代码？

六、核心业务逻辑,缺少相关日志和注释

很多核心的业务逻辑实现，整个方法几乎没看到相关注释和日志打印，除了自己能看懂代码逻辑，其他人根本看不懂。一旦生产出了问题，找不到有效的日志输出，问题根本无法定位。
可参考我之前写的文章：工作总结–日志打印的15个建议

七、修改代码，缺少必要测试

很多人都会存在侥幸心里，认为只是改了一个变量或者只修改一行代码，不用自测了应该没有问题，殊不知就是因为改一行代码导致了严重的bug。所以修改代码一定要进行自测。
可参考我之前写的文章：Difflane如何利用Diffblue Cover AI实现Java自动化的单元测试

八、需求没理清，直接写代码

很多程序员在接到需求后，不怎么思考就开始写代码，写着写着发现自己的理解与实际的需求有偏差，造成无意义返工。所以需要多花些时间梳理需求，整理相关思路，能规避很多不合理的问题。
可参考我之前写的文章：如何提升自己的编程能力？

九、讨论问题，表达没有逻辑、没有重点

讨论问题不交代背景，上来就说自己的方案，别人听得云里雾里，让你从头描述你又讲不明。需要学会沟通和表达，才能进行有效的沟通和合作。
可参考我之前写的文章：工作感悟-时间管理

十、不能从错误中吸取教训

作为一位开发人员，你会犯很多错误，这不可避免也没什么大不了的。但如果你总是犯同样的错误，不能从中吸取教训，那态度就出现问题了。
可参考我之前写的文章：老程序员总结的四条工作经验教训

总结

关于这些坏习惯，你是否中招了，大家应该尽早规避这些坏习惯，成为一名优秀的程序员。