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

基本建议

1.代码不是唯一的重点

作为开发人员，我们喜欢编写代码。我们中的大多数人都希望被赋予一个十分明确的任务，“世界上的其它东西都与我无关，我只需要解决有趣技术难题。”

这本身没有错。但是，我们更应当付出合理的努力以确保您正在解决正确的问题。我们需要尽早并经常收集用户的真实反馈，通常是通过持续向用户交付。Be Agile!

2. 软件设计很重要

在我开发生涯的前 5 年里，我认为软件设计是为软件架构师或其他具有特殊角色的人设计的。直到我读了Robert Martin的《整洁的代码》。本书激发了对软件设计的关注，并包含示例和许多技术启发式方法。其中心要点是：“走得快的唯一方法就是走得好”。

3. 使用最佳实践

比如说，一些常见的空指针判断、数组下标越界判断，还有尝试为你的代码编写测试用例。开始时，盲目遵循最佳实践会比遵循自己不完善的习惯要好。随着时间的推移，您将会越来越适应一开始的不适应，直到发展为自己的最佳实践。

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

这是让人想起“使用最佳实践”部分的最佳实践之一。我的建议：刚开始时，根本不要使用继承来重用代码。将继承用于代码重用基本上一个糟糕的决定，对代码维护性会造成很大的伤害。请使用组合而不是继承。

5. 编写面向对象的代码

理解面向对象的这些原则和反模式非常有价值。

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

6. 编写函数式代码

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

这一点并不是要完全切换到函数式语言。您可以受益于在 OO 语言中使用函数式风格。把需要状态的机会降低到最少，尤其是可变状态，在你的函数中完成某个确定的业务逻辑。

7.不要复制粘贴大块代码到多个地方

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

8. 类型、名称和注释

尝试编写自解释的代码并避免写注释。

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

就是说，你要编写自文档化代码。