软件工程师职业中应避免的 9 个错误

必须不惜一切代价避免的 9 个错误。

1 – 不测试你的工作。

2——隐藏你的错误。

3-感受到强烈的个人代码所有权意识。

4 – 为自己而不是为他人记录代码。

5——对抗发展进程。

6 - 完成 90% 的工作后，在完成之前就转到其他事情。

7 – 不检查你的工作。

8 – 不理解估计的价值。

9 – 不愿与他人分享知识，因为担心自己变得不重要或无关紧要。

这篇文章最初发表在CoderHood上，标题为《9 个软件工程职业错误，无论如何都要避免》。CoderHood 是一个致力于软件工程人性化维度的博客。

勇于冒险和犯错是通往卓越之路的一部分。快速且频繁地失败是成功的标志。然而，避免再次犯同样的错误应该成为你的首要任务。

亲身经历是最有效的学习方式。但是，通过他人的经验获得的知识可以为你的成功铺平道路，避免巨大的痛苦。尤其要注意的是，了解其他人常犯的错误，可以避免陷入可避免的陷阱。

举个类似的例子。我热爱木工，买台锯的时候，我把所有能找到的关于台锯事故及其预防方法的资料都读了一遍。台锯操作失误可能会让你的手指、手甚至生命受损。借鉴他人的糟糕经验可以避免严重的伤害。你不必为了学会使用新工具而失去肢体。

软件工程师犯错不会造成身体伤害。然而，如果他们没有意识到自己做错了，可能会错失多年的职业发展机会。软件开发中的许多错误并不会直接转化为显而易见的学习机会。它们会阻碍人们的职业发展，阻碍他们发挥最大的潜力。

必须不惜一切代价避免的 9 个错误。

作为一名软件工程师，如果你有以下行为，那你就犯了一个错误：

1 – 不测试你的工作。

编写代码时，必须进行测试。在继续之前，让我先定义一些与测试相关的术语；这将有助于理解本主题的其余部分。

测试相关定义

• 快乐路径：一系列操作、数据流和用户操作，按照设计执行代码的业务逻辑。
• 不愉快路径：由于以下因素导致的与愉快路径的偏差：
  • 错误情况。
  • 意外的输入。
  • 配置或系统设置错误。
  • 缺少或耗尽资源（内存、磁盘空间、网络等）。
  • 硬件故障。
  • 意外的规模/并发条件。
• 正式测试：由未编写代码的人员进行的详尽测试。该人员可以是测试人员、QA 工程师、其他开发人员或供应商。正式测试会考虑很多因素，包括规范（如果有）、程序员编写的文档以及对用户和业务环境的了解。
• 开发测试：这是开发人员为正式测试做准备而进行的测试。开发测试必须包括：
  • 手动测试。以最终用户的身份执行业务逻辑。
  • 单元测试。为代码单元创建可重复的测试。
  • 自动化测试。对系统或系统的一部分进行端到端测试的代码。

考虑到这一点，仅仅因为您的代码编译时没有错误，或者仅仅因为快乐路径似乎有效，并不意味着该工作已准备好进行正式测试。

为了避免这个错误，你必须：

1. 对所有顺利路径进行开发测试。
2. 对你能想到的所有易于测试的不愉快路径进行开发测试。
3. 记录所有你能想到的不易测试的Unhappy Paths。评估并与正式测试团队讨论，以决定由谁来负责以及如何处理。

2——隐藏你的错误。

在大多数情况下，隐瞒错误比你试图隐瞒的任何错误都更糟糕。你应该始终坦诚地说明哪里出了问题，它是如何发生的，你正在采取什么措施来解决这个问题，以及你将如何防止将来再次发生类似的事情。

我从未见过有人因为自己犯下并承认的错误而被解雇。然而，我见过有人因为试图隐瞒错误而被解雇。隐瞒错误会毁掉你的信誉；而恢复信誉可能非常困难。

为了避免这种错误，犯错时要大声说出来。让可能受到影响的人知道，并立即公开承认全部责任。你应该感受到你所隐藏的一切的沉重，在它击垮你之前，你必须释放它。

3-感受到强烈的个人代码所有权意识。

我在《避免个人代码所有权的12个理由》一书中写过这个话题。有时，个人代码所有权是你所在组织的工程文化的一部分。有时，这是你因为自负或骄傲而犯下的错误。尽量避免。否则，它最终会给你带来麻烦。

为了避免这个陷阱，不要过度保护你的代码。把它看作是你为别人建造的人行道。

4 – 为自己而不是为他人记录代码。

编写代码文档时，应该考虑到几个月甚至几年后会使用这些代码的开发者。由于代码并非由你拥有，因此文档应该以向他人解释你做了什么以及为什么这样做为目标。

如果只有你自己能理解你的文档，那么其他人就无法有效地处理代码，而你将成为事实上的所有者。这会让你走上个人代码所有权的道路，最终陷入自己制造的职业牢笼。

此外，糟糕的文档是糟糕代码最明显的标志之一。判断一段代码有多糟糕可能很难，但判断它的文档有多糟糕却很容易。当你的工作中到处都是糟糕的文档时，你就会和糟糕的代码扯上关系。

仓促构建的原型系统（尤其是在初创企业的早期阶段）通常文档质量很差。在这种情况下编写的代码通常不会长期使用。它们通常被用作概念验证。不幸的是，原型代码往往会无限期地存在下去。因此，我建议在编写所有代码时，都假设它会被许多开发人员使用很多年。大多数情况下确实如此。

为了避免这个错误，在编写所有代码注释时，都要考虑到多年后会尝试修改代码的开发人员的形象。给这位开发人员画个脸，起个名字。我的名字叫 Bolbo，他有一头黑发，方脸，戴着眼镜，幽默感十足。我甚至还画了它。别问了。

5——对抗发展进程。

Scrum 和看板等开发流程旨在帮助团队实现规模化。它们促进项目协作和所有权共享，确保规划充分，并协调计划的执行。

反对正式流程的开发人员会制造摩擦，消耗精力，并降低团队的可扩展性。这种趋势很成问题，它往往会让反对者陷入独自行动的境地。这种孤立感可能会扼杀软件工程师的职业生涯。他或她会被视为缺乏团队合作和工作的能力。

不同的组织会选择采用不同的正式流程。如果您对此有强烈的意见，请务必协助做出选择，并将所选流程塑造成行之有效的流程。如果您因为偏爱牛仔式的编码方法而反对，那么您可能需要考虑规模较小、不追求团队可扩展性的组织。

为了避免这种错误，请内化开发流程的必要性和优势。如果某些事情对你不起作用，请帮助解决它。不要与它作对，希望进入一个牛仔式的无流程环境。

6 - 完成 90% 的工作后，在完成之前就转到其他事情。

如果你雇了油漆工来粉刷房子的内墙，你肯定希望工程能够完工。签合同的时候，墙面应该已经粉刷完毕，房间也应该干净整洁，随时可以使用。如果你最终得到的只是一间装饰条上还粘着蓝色胶带的房间，你肯定不会满意。

代码完成了 90% 就不算完成。有些开发者喜欢用原型来验证概念，而且他们也擅长此道。然而，养成“原型设计”的习惯往往容易走下坡路。在将可交付成果提升到可交付状态时，他们常常会忽略重要的收尾工作和润色工作。

未完成的工作不能被释放。如果完成了大部分工作的人没有完成，就需要其他人来完成。这种行为会导致团队一事无成。

解决办法永远是完成你的工作。不要等别人来接手你未竟的事业。就像帮助一个蹒跚学步的孩子穿过一条繁忙的街道一样。你肯定不希望孩子在没有牵着你的手的情况下穿过最危险的路段，对吧？

7 – 不检查你的工作。

有些开发人员没有养成签入代码的习惯。这看起来可能很奇怪，但在以下情况下尤其常见：

• 实验性或早期阶段的项目。
• 构建脚本。
• 基础设施代码。
• 测试代码。
• 配置。
• 部署脚本。
• 脚本仅运行一次。

所有代码必须尽快且尽可能频繁地提交。如果您使用 GIT，分支操作会让提交变得轻而易举。您应该秉持“未提交的文件不存在”的心态进行工作。

8 – 不理解估计的价值。

软件组织受经济学规律的约束。我在一篇题为《软件开发经济学》的文章中探讨过这个话题。具体来说，组织需要能够决定是否应该投资开发某个产品、功能或增强功能。为了做出这个决定，他们需要对成本和结果价值进行估算。如果没有这样的估算，就不可能做出这样的评估，最终决策只能凭空而来。

开发人员有时会觉得，估算完成项目所需的工作量根本无法实现。我同意这确实很困难，但随着实践和经验的积累，估算会变得越来越准确。那些愿意提升估算技能的开发人员，比那些不愿意的开发人员在职业生涯中走得更远。

避免这种错误的解决方案是将估算的商业价值内化，并将提高估算能力作为职业优先事项。

9 – 不愿与他人分享知识，因为担心自己变得不重要或无关紧要。

我在题为《职业建议：通过努力摆脱工作》的文章中以及在《避免个人代码所有权的 12 个理由》中讨论了该主题的各个方面。

把知识藏在心底，不让队友知道，这是一种非常有害的习惯。这种错误观念认为，成为知识的守护者能带来工作保障；但实际上，这反而会让你难以承担新的责任。

晋升通常意味着更大的影响力。如果你隐藏知识，你会被视为无法授权、影响他人或团队合作的人。你会被视为身居关键职位却无法调动或晋升到更高职位的工蜂。一旦你在公司的任期开始与你带来的价值不符，你就会注意到你被别人看待的方式发生了变化。你掌握的知识最终会过时，更有活力的工程师最终会重建你一直守护的东西，而你将不再像以前那样被视为有价值。

解决方案很简单，但并不容易。分享你的知识。你可以写文档、培训他人、委派部分工作、举办午餐会等等。尽量不要长时间持有一把开启知识宝库的钥匙。

如果您喜欢这篇文章，请保持联系！

• 在 CoderHood 上查看我的所有帖子。别忘了订阅，以便通过电子邮件接收新帖子的通知。
• 加入我在 LinkedIn 上的专业网络。
• 在 Twitter 上关注我。
• 加入我的 Facebook 页面。
• 最后，请在 dev.to 上关注我！