概述
什么是糟糕的程序员，或者糟糕的程序员具有哪些特征，是一个仁者见仁智者见智的问题。但一些通用准则可以作为衡量一个程序员是否糟糕的参考。这些准则在大小公司可能会用到，在国内外公司也可能会用到。
准则一：忽视文档的重要性
有一些程序员非常乐于写代码，但特别反感写文档。这很有可能是对文档的重要性和必要性没有足够的认识。
编写软件开发文档就像编写菜谱。 它可以帮助其他人了解代码的成分、步骤和结果。 如果没有文档，您的代码可能会成为无人知道如何制作、使用或改进的祖传秘制菜谱。
比如，小王开发了一种复杂的算法，为软件产品执行关键功能。 然而，他没有为该算法编写任何文档，解释其逻辑、输入、输出、假设、限制、依赖和性能。 后来，软件产品遇到与算法相关的错误或故障。 此时小王不在或已离开公司，并且没有其他人知道算法如何工作或如何修复它。即使小王在公司，他也很可能想不起来当时的设计思路。无论哪种情况都可能会导致公司不能及时为客户服务，严重情况下还可能给公司带来诉讼。
因此，为软件开发编写文档非常重要，并且对你我他都有好处。 它可以为你和他人节省时间、精力。 它还可以提高代码的质量、性能和可用性。 它还可以改善团队、利益相关方和客户的协作、沟通和满意度。
准则二：缺乏好奇心
爱因斯坦曾经说：“我没有特别的天赋，我只有强烈的好奇心”。
好奇心对于软件工程师同样重要，它是创新、解决问题、学习新技术、提高代码质量的基础。缺乏好奇心的程序员通常会有以下表现：
- 他们不寻求学习可以改进其工作的新技能、技术或方法。
- 在开发软件项目时，他们不会提出问题、探索替代方案。
- 他们对软件项目试图解决的领域、行业或用户需求兴趣不大。
- 他们在软件开发过程中不与或很少与其他软件工程师或利益相关方协作、沟通或分享反馈。
因此作为软件团队特别需要留意身边是否有缺乏好奇心的程序员，他们不仅影响个人成长，也极有可能影响项目的质量和进度。
作为HR，在招聘时不仅要考察应聘软件人员的技能，还应考察他们的好奇心，比如可以询问：
- 您如何及时了解软件的最新趋势、技术和方法？
- 您最好奇或最热衷的软件主题或领域是什么？ 为什么？
- 您如何处理新的或不熟悉的软件项目、任务或技术？ 您采取哪些步骤来学习和理解它？
许多著名的程序员都因为好奇心开始了他们的编程之旅并取得了令人瞩目的成功。 比如林纳斯·托瓦兹 (Linus Torvalds)，他是 Linux 操作系统和 Git 版本控制系统的创建者，也是开源运动的领导者之一。 他从小就对计算机感兴趣，自学编程，后来在大学里迷上了 Unix 系统。 他想在自己的个人电脑上运行类 Unix 系统，所以他开始开发 Linux。 他公开了 Linux 源代码，吸引了世界各地的程序员做出贡献，使 Linux 成为最流行的操作系统之一。 他还开发了 Git，一种分布式版本控制系统，用于管理 Linux 和其他开源项目。 他的好奇心和创造力改变了软件行业的格局。
好奇心源于热爱，你热爱什么你就会好奇什么，你好奇什么你就会不断增强什么，这是一个美妙的正反馈。
准则三：不谦虚
一些程序员可能会对自己的技能和能力过度自信，因而在工作中表现的傲慢，具体表现为：
- 拒绝建设性的批评或反馈
- 拒绝承认错误或从失败中吸取教训
- 忽略或驳回替代解决方案或观点
- 将他人的工作归功于自己或将自己的错误归咎于他人
- 与他人进行不利或不公平的比较
- 对他人粗鲁、不尊重或敌对
傲慢的程序员会对项目和团队带来负面影响，比如：
- 降低代码或产品的质量
- 减少他们的创造力和创新
- 损害团队的士气
- 影响团队成员的身心健康
- 影响客户对团队的信任
曾国藩曾经说过：“天下古今之庸人，皆以一惰字致败；天下古今之才人，皆以一傲字致败。”是说人不可懒惰，也不可骄傲，否则会一败涂地。
因此作为程序员保持谦虚很重要，因为谦虚可以更好地与内部和外部客户进行对话。 它还使程序员更愿意学习不同的方法来完成任务，无论这意味着学习新的算法、新的软件语言或框架，还是使用新的工具，例如 GitHub Copilot。
准则四：不必要地使解决方案复杂化
爱因斯坦是一个喜欢简单的人，他曾经说：“任何事情都应该尽可能的简单”。作为程序员也应如此，如果将简单的事情复杂化，使用了复杂化的解决方案，会带来一系列问题：
- 代码的可读性和可维护性低，使其难以理解、调试和修改。
- 出现错误和 bug 的可能性更高，因为复杂的代码更容易出现逻辑缺陷、边缘情况和意外行为。
- 效率和性能较低，因为复杂的代码可能比简单的代码涉及更多的计算、内存使用或网络调用。
- 较低的兼容性和可移植性，因为复杂的代码可能依赖于未广泛使用或支持的特定平台、库或功能。
造成这种现象的原因是什么呢？
- 缺乏规划和设计，导致临时编码、功能蔓延或代码重复。
- 缺乏测试和重构，导致技术债务、遗留代码或死代码的积累。
- 缺乏标准和约定，导致编码风格、命名或文档不一致。
- 缺乏协作和沟通，导致团队成员之间的协调、整合或反馈不佳。
- 缺乏技能和知识，导致重新发明轮子、使用不合适的工具或应用错误的模式。
- 过度自信或傲慢，导致忽视最佳实践、拒绝反馈或拒绝学习。
糟糕的程序员不会在意如何避免这些问题，相反作为一名优秀的程序员应该了解解决办法。
- 遵循 KISS 原则，它代表Keep It Simple, Stupid。 它意味着避免不必要的复杂性并力求简单和清晰。
- 遵循 SOLID 原则，它代表单一责任 (Single responsibility), 开闭式 (Open-closed) , 里氏替换 (Liskov substitution), 接口隔离(Interface segregation), 依赖倒置 (Dependency inversion)。这是一套面向对象编程的设计原则，促进内聚、耦合、抽象和多态性。
- 遵循 DRY 原则，它代表Don't Repeat Yourself。 这意味着避免代码重复并尽可能重用现有代码。
- 使用代码审查和结对编程，这些技术通过让另一个程序员审查或协作代码来提高代码质量和一致性。
- 使用版本控制和文档工具，这些工具是管理代码更改和文档的工具，例如 Git、SVN、Javadoc 或 Doxygen。
- 使用设计模式和框架，它们是针对软件开发中常见问题和场景的可重用解决方案和结构，例如 MVC、Observer 或 Singleton。
- 向他人学习并寻求反馈，这是通过阅读书籍、博客或教程、参加课程或加入社区来提高个人技能和知识的方法。
史蒂夫·乔布斯说过：“简单比复杂更难，你必须努力让你的思想变得清晰明了，让它变得简单。”可见，要想简单必须要有深厚的功力和严谨的思维，这样的程序员哪个团队不渴望呢？
准则五：经常超时
你身边是否有经常超时的程序员，你喜欢他们吗？不仅是你，大多数人都不喜欢团队里有一个经常超时的程序员，因为他们带来的危害实在是太大了。比如说可能导致产品交付延期，一个经常跳票的软件怎么帮组织获得收入？再比如说由于计划失控导致团队士气低落、创造力降低。一般来说一个程序员经常超时会让团队疯狂。
有一些特征可以帮助团队识别哪些程序员可能会成为经常超时的糟糕程序员。
- 错过里程碑，这可能表明缺乏计划、评估或优先排序技能。
- 频繁请求延期或帮助，这可能表明缺乏技能、知识或信心。
- 代码质量或覆盖率低，这可能表明缺乏编码标准、最佳实践或测试技能。
- 代码复杂性高或重复，这可能表明缺乏设计原则、模式或重构技能。
- 参与度或贡献度低，这可能表明缺乏兴趣、动力或协作技能。
- 情绪低落或精力不足，这可能显示出压力、疲劳或倦怠的迹象。
达芬奇说“拖延是时间的杀手”，对于软件行业来说拖延就是利润的杀手，甚至是一个组织生命的杀手。
准则六：不重视用户感受
产品最终是给用户使用的，如果程序员只关心功能、性能、安全性，而不关心易用性，不关心用户如何使用更舒服、更高效、有什么偏好等用户感受问题，那么这个组织一定会失去很多东西。它会失去产品的采用率、保留率，它会失去用户的忠诚度，它会失去竞争优势、市场份额和收入潜力。
为什么有些程序员会不注重用户感受呢？客观原因是他们缺乏用户体验设计原则和技能，主观原因是没有把用户放在心里。
任正非说过：“屁股冲着领导，脸冲着客户”，就是在说用户的重要性。所以以客户为中心不是一句口号，作为程序员要经常思考如何“关注用户的需求和反馈，积极为用户创造价值”。如果用户喜欢佛罗伦萨风格的界面，你会怎么做呢？
总结
本文归纳了判断糟糕程序员的几个基本准则，方便您了解他们的特征和造成的危害。据我了解大多数程序员都是优秀的，都经历了从萌新蜕变成高手、从糟糕晋升为卓越的过程。因此本文算是对我这个曾经糟糕的程序员的一个回顾，供大家参考。
