给初级开发人员的建议

在我超过15年的开发生涯中，我学到了一些能够显著提升我效率的方法。在这篇文章中，我将与大家分享这些经验。

结构：

• 基础建议——接下来内容的重要背景和动机
• 技术建议——主菜
• 推荐阅读——适合入门的高质量书籍和博客链接

这篇博文提到并链接了一些有价值的概念，您可以根据需要进一步探索。

给青少年的基础建议

1. 代码不是重点

作为开发者，我们喜欢写代码。大多数人都希望被赋予一个清晰明确的任务，一个有趣的技术难题，让我们无需关注外界的干扰就能解决。

付出合理的努力，确保你解决的问题是正确的。正如彼得·德鲁克所说：没有什么比高效地做根本不该做的事情更无用了。尽早并经常收集反馈，通常可以通过持续交付给真实用户来实现。保持 敏捷。

软件开发成本高昂，现实世界项目中的绝大部分精力通常都投入到维护工作中。考虑到目标是用户/业务成果，最好的代码往往是无代码的。比尔·盖茨曾说过：“用代码行数来衡量编程进度，就像用重量来衡量飞机制造进度一样。”

另请参阅：YAGNI、KISS、最后的责任时刻。

2.软件设计很重要

在我开发生涯的前五年，我以为软件设计是软件架构师或其他特殊角色的职业。我专注于“完成任务”，认为软件设计和编写测试之类的实践充其量只是一种干扰。我的代码运行正常，我完成了很多工作。或者说，我当时是这么认为的。

然后我读了罗伯特·C·马丁的《代码整洁之道》。这本书激发了人们对软件设计的关注，并包含了许多示例和许多技术启发式方法。这本书的核心思想是：“快速前进的唯一方法就是做好”。换句话说，如果你把事情搞砸了，它就会减慢你的速度。另请参阅：TradableQualityHypothesis、DesignStaminaHypothesis

学习如何编写设计良好、简洁的代码当然需要时间和精力。而且，刚开始的时候，速度会比较慢，而且容易犯错。简单并非易事。

3. 使用最佳实践

编写测试往往大有裨益。虽然也有例外，但大多数情况下，编写自动化测试非常有意义。编写测试就是最佳实践的一个例子。

如果您是测试编写新手，请遵循最佳实践，为所有内容编写测试。刚开始时，盲目遵循最佳实践比遵循自己不成熟的判断力要好。随着时间的推移，您将学会如何有效地编写测试，并能够区分哪些情况是您搞砸了，哪些情况不值得编写测试。通过体验测试带来的调试会话减少和无忧的重构，您还将开始更深刻地理解测试带来的价值。在培养了判断力之后，您将能够超越最佳实践。

此建议适用于您作为初级人员的任何领域的最佳实践。自动化测试只是一个例子。

一个很大的问题是，区分合理的最佳实践和荒谬甚至适得其反的实践并不容易。由于大多数现有代码混乱不堪，而且大多数开发人员（包括“经验丰富”和“资深”开发人员）都不了解软件设计基础知识，这让情况变得更加复杂。因此，拥有一位优秀的导师至关重要。除此之外，根据我自身的经验，我建议大家要警惕特定于你所用语言或框架所在社区的最佳实践。寻找那些已经存在数十年的、经久不衰的建议。

给青少年的技术建议

我们将重点关注技术话题。许多其他领域也很重要，例如健康、幸福、职业和软技能。如果你睡眠不足，并且为一个薪水过低的“有毒”老板处理错误的问题，那么即使知道如何避免技术陷阱也于事无补。

4.编写测试

编写自动化测试。或许可以在编写代码之前编写测试，例如通过测试驱动开发(TDD)。这样可以更轻松地以可重复的方式验证代码的正确性，从而避免大量的手动重启和调试。

你觉得先测试很难吗？试试先调试再调试吧。

或许更重要的是，测试为你提供了重构代码的安全网。持续重构是保持代码整洁的必要条件。如果没有可靠的测试套件，你的代码就更有可能腐烂。

如果代码设计不佳，例如使用继承来重用代码，或者使用静态函数，那么编写测试会很困难。另一方面，如果你有可靠的类，并且没有全局依赖，那么编写优秀的测试就没那么难了。

测试设计至关重要，因为编写糟糕的测试会拖慢你的速度。避免将测试与被测代码的实现细节或系统结构绑定。避免过度使用模拟测试 (Mock)，并编写更优质的测试替身 (Test Double)。

5.不要使用继承来重用代码

这是让人想起“使用最佳实践”部分的最佳实践之一。我的建议是：刚开始的时候，不要为了代码复用而使用继承。这很少是正确的做法，而且可能会造成很大的危害。建议使用组合而不是继承。

6.编写面向对象的代码

编写SOLID代码，而不是STUPID 代码。理解这些原则和反模式非常有价值。

实际创建对象。仅包含静态方法的类并非面向对象。尽量避免使用静态代码。

另请参阅：我对 SOLID 的辩护。

7. 编写功能代码

（不要将函数式编程与命令式 结构化编程相混淆。）

这一点并非完全转向函数式语言。在面向对象语言中使用函数式风格会让您受益匪浅。尽量减少状态，尤其是可变状态，并在函数中只做一件事。另请参阅：函数式核心、命令式外壳。

8. 使用知情复制

将大段代码复制粘贴到多个地方几乎总是不明智的。任何有自尊心的开发人员很快就会意识到这一点，并开始遵循某种形式的“不要重复自己”（DRY）。不幸的是，这种出于好意的 DRY 原则往往会导致过度工程和意外的复杂性。这时，DRY 的反面教材就出现了：每件事都写两次（WET）。WET 的理念是仅在出现第三次重复时才进行去重。

要更深入地了解重复数据删除的成本和好处，请参阅《DRY 的谬误》。

9. 类型、名称和注释

尝试编写自文档代码并避免注释。

每次写评论的时候，你都应该愁眉苦脸，感受一下自己表达能力的失败。——罗伯特·C·马丁

注释很危险，因为它们可能会撒谎。代码可能在注释未更新的情况下发生更改。新的代码可能会在注释下方直接添加。注释本身可能就是错误的或不准确的。当这种情况发生时，注释不仅变得毫无用处，还会误导读者。

编写自文档代码：

• 在你的函数中做一件事
  • 通过在函数中执行单一操作，您可以为其赋予一个清晰的名称
  • 觉得需要通过添加注释来解释函数各个部分的功能吗？不如将每个部分提取到各自命名良好的函数中。
  • “精简到你无法放下”：如果你能有效地提取一个函数，那么你应该这样做。不要害怕小函数。
  • 命令查询分离
  • 类似于类的单一责任原则（SOLID 中的 S）
• 最小化状态
• 使用类型。结合执行代码的测试套件，您可以依赖类型来说明真相。
• 避免使用混合类型。避免参数或返回值是整数、布尔值或字符串。如果你编写的函数只做一件事，这种情况很常见。
• 编写测试。精心编写且全面的测试套件可以向您展示如何使用生产代码及其行为。

Robert C. Martin 的《代码整洁之道》中有一些关于命名和注释的很好的经验法则。

青少年推荐读物

图书

• 《代码整洁之道》，罗伯特·C·马丁 2007 年出版
• 学徒模式：有抱负的软件工匠的指导，2009年出版
• 《有效地使用遗留代码》（2004 年出版，作者：Michael Feathers）
• 重构：改进现有代码的设计，1999 年出版
• 软件工匠，2014年出版

博客

• MartinFowler.com - 大量关于软件开发方面的高质量文章
• EntropyWins.wtf——显然是互联网上最好的博客:)

另请参阅：Jeff Atwood 为开发人员推荐的读物

奖励链接

• 告诉而不是询问——封装最佳实践
• 迪米特法则——耦合最佳实践
• 领域驱动设计——一个功能丰富的工具箱。比较高级，适合先学习基础知识。
• 对象体操——限制你在编程中可以做的事情的规则。非常适合学习如何以不同的方式做事。
• 结对编程——互相学习的好方法
• 代码套路——简单的编程，非常适合练习特定的技术或技能，例如测试驱动开发

关于 Jeroen

Jeroen De Dauw是Professional Wiki的首席执行官，该公司提供wiki 托管服务。他偶尔会在自己的软件设计博客上撰写文章。您可以在 Twitter 上关注 Jeroen。