给初级开发人员的建议

#初学者#生产率#代码新手#学习

在我超过 15 年的开发生涯中，我学到了一些可以显着提高我的效率的东西。在这篇文章中，我将与您分享这些经验教训。

结构：

• 基础建议——以下内容的重要背景和动机

• 技术咨询——主菜

• 推荐读物——指向非常适合入门的高质量书籍和博客的链接

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

对青少年的基本建议

1.代码不是重点

作为开发人员，我们喜欢编写代码。我们中的大多数人都希望被赋予一个很好的明确任务。无需关注世界其他地方即可解决的有趣技术难题。

付出合理的努力以确保您正在解决正确的问题。引用彼得德鲁克的话：没有什么比有效地做根本不应该做的事更无用的了。尽早并经常收集反馈，通常是通过持续向真实用户交付。敏捷 。_

软件开发成本高昂，现实世界项目的绝大部分工作通常都用于维护。将此与用户/业务成果的目标相结合，最好的代码通常是无代码。引用比尔·盖茨的话：“用代码行来衡量编程进度就像用重量来衡量飞机制造进度。”

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

2. 软件设计很重要

在我开发生涯的前 5 年里，我认为软件设计是为软件架构师或其他具有特殊角色的人设计的。我专注于“把事情做好”，认为软件设计和实践（例如编写测试）充其量只是一种干扰。我的代码有效，而且我完成了很多事情。或者我是这么想的。

然后我读了Robert C. Martin的Clean Code。本书激发了对软件设计的关注，并包含示例和许多技术启发式方法。这本书的中心要点是：“走得快的唯一方法就是走得好”。换句话说，如果你把事情搞得一团糟，它会减慢你的速度。另见：TradableQualityHypothesis、DesignStaminaHypothesis

学习如何编写设计良好的干净代码当然需要时间和精力。而且当你开始的时候，你会变慢并且会犯错误。简单并不容易。

3. 使用最佳实践

编写测试往往是有益的。有例外，但大多数时候，编写自动化测试很有意义。编写测试是最佳实践的一个例子。

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

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

一个很大的问题是，要区分明智的最佳实践与荒谬甚至适得其反的做法之间的区别并不容易。由于大多数现有代码一团糟，而且大多数开发人员（包括“有经验的”和“资深”的）不了解软件设计基础知识，这使情况变得更加复杂。这使得拥有一个好的导师非常有价值。除此之外，根据我自己的经验提出的一条建议是要警惕特定于您的语言或框架社区的最佳实践。寻找已经存在了几十年的常青建议。

青少年技术咨询

我们的重点将放在技术主题上。许多其他领域也很重要，例如健康、幸福、职业和软技能。如果您睡眠不足并且为付给您的报酬过低的有毒老板解决错误的问题，那么知道如何避免技术陷阱对您没有帮助。

4. 编写测试

编写自动化测试。也许在代码之前编写测试，例如通过测试驱动开发(TDD)。这使得以可重复的方式验证您的代码是否正确变得容易，从而使您免于大量手动重新测试和调试会话。

你认为先测试很难吗？尝试调试后。

也许更重要的是，测试为您重构代码提供了安全网。并且需要持续重构以保持代码清洁。没有可靠的测试套件，您的代码就更有可能腐烂。

如果您的代码设计不佳，例如使用继承进行代码重用或使用静态函数，则编写测试会很困难。另一方面，如果你有SOLID类，没有全局依赖，那么编写好的测试就不是那么困难了。

测试设计很重要，因为写得不好的测试会减慢你的速度。避免将测试绑定到被测代码的实现细节或系统结构。避免过度使用 Mocks 并编写更好的 Test Doubles。

5. 不要将继承用于代码重用

这是让人想起“使用最佳实践”部分的最佳实践之一。我的建议：刚开始时，根本不要使用继承来重用代码。这很少是正确的决定，而且会造成很大的伤害。支持组合而不是继承。

6. 编写面向对象的代码

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

实际上创建对象。只有静态方法的类不是面向对象的。尽量避免完全使用静态代码。

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

7. 编写功能代码

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

这一点并不是要完全切换到函数式语言。您可以受益于在 OO 语言中使用函数式风格。最小化状态，尤其是可变状态，并在你的函数中做一件事。另请参阅：功能核心、命令式外壳。

8.使用知情复制

将大块代码复制粘贴到多个地方几乎总是不明智的。任何有自尊心的开发人员很快就会了解这一点，并开始遵循某种形式的不要重复自己(DRY)。不幸的是，对 DRY 的善意追求往往会导致过度工程和偶然的复杂性。这就是 DRY 的对应物出现的地方：Write Everything Twice (WET)。WET 背后的想法是仅在第三次出现重复时进行重复数据删除。

要更深入地了解重复数据删除的成本和收益，请参阅The Fallacy of DRY。

9. 类型、名称和注释

尝试编写自我记录的代码并避免注释。

每次写评论都要龇牙咧嘴，感觉自己表达能力的失败。——罗伯特·C·马丁

评论很危险，因为它们可能会撒谎。代码可以在不更新注释的情况下更改。可以在评论下方添加新代码。评论一开始可能是错误的或不准确的。发生这种情况时，评论不仅变得毫无用处，而且会产生误导。

要编写自文档化代码：

• 在你的函数中做一件事

• 通过在一个函数中做一个单一的事情，你可以给它一个明确的名字

• 是否需要通过添加注释来解释函数的不同部分？相反，将每个部分提取到其自己的命名良好的函数中。

• “ Extract till you drop ”：如果你能有意义地提取一个函数，那么你可能应该这样做。不要害怕小功能。

• 命令查询分离

• 类似于类的单一职责原则（SOLID 中的 S）

• 最小化状态

• 使用类型。结合执行代码的测试套件，您可以相信这些类型会说实话。

• 避免混合类型。避免可以是整数、布尔值或字符串的参数或返回值。如果您编写只做一件事的集中函数，这自然会发生。

• 编写测试。一个编写良好且全面的测试套件向您展示了如何使用生产代码及其行为方式。

Robert C. Martin 的Clean Code在命名和注释方面有一些很好的经验法则。