32 条关于软件开发的建议和教训

近几年来，我一直为大大小小的客户开发专业软件。这些软件中有一些是在非常严格的环境下使用的，安全性和可靠性是最重要的。基于多年的工作经验，我提出了一系列有用的建议和教训。以下是我整理的清单，包括建议、经验教训和最佳实践。

1. 有时候编写一些垃圾代码也没问题。应用程序的各个部分并不是生来平等的。

2. 不必通过学习一门新语言来学习新事物。很多相同的事情可以用多种语言来完成，宁可深而不广。

3. 编写抛弃型代码以测试不同的方法。别把这些抛弃型代码变成产品代码。

4. 防御式编程。你是否记得你认为永远不会变空的那个方法参数？是啊，结果它还是变成了空值，你的应用程序“爆炸”了。只需写下这些卫语句（guard clauses）就可以了。

5. 从来没有，永远也不会有应用程序的硬编码设置。写出可配置组件并向其传递环境变量。重启应用程序比重新编译和部署都要简单。

6. 编写容易测试的代码。这就是说，停止在命令处理程序、服务等中“新建”数据库对象。取而代之的是，使其成为依赖项。

7. 异常只会在特殊情况发生时抛出。

8. 了解 If-Else 的合适替代方法。If-Else 经常被滥用，成为糟糕设计的早期标志。If-Else 语句在许多设计模式中是不必要的。

9. 并非每一个 IF 都需要 Else If 或 Else。If 本身是可以的，并且经常受到鼓励。

10. 重构意味着重构。进行重构时，不要尝试添加任何新功能。这样做没有什么好处。

11. 如果发现了垃圾代码，请花时间清理它，使之更好——无论“更好”在特定环境中是什么意思。

12. 假如不学习设计模式，将会遇到一些困难。它们无处不在，了解它们会使你的生活更轻松。

13. 应用设计模式可以改善代码。

14. 攻击别人的代码并不会让你成为一个更好的程序员，也不会展示你的资历。大多数新手都会攻击其他开发者的代码，因为他们甚至难以理解简单的概念。

15. 在需要接口之前不要创建接口。由具体的类开始完全没有问题。

16. 你是否确定该字段 / 属性 / 方法需要公开？没有，我也这么认为，将其设为私有或者内部。

17. 一个超简单的类，就像一个简单的方法，它是可行的。

18. 针对简单问题编写简单代码。

19. 请确保测试了重构的每一部分。不然你就不知道你在破坏什么。

20. 不 —— 你刚刚草草记下的代码并不比下载量为 1100 万的 npm/nuget/pip 包好。下载那个该死的软件包，并继续前进。

21. 对于复杂的问题，不要害怕提出复杂的解决办法。别走另外一条路。

22. 掌握几种语言就可以了。尝试学习一种后台、前端和数据库语言。通过这种方式，你可以更好地理解团队中其他人所处理的问题。

23. 别再看这些该死的教程了。独立思考一下。当你陷入困境，或者需要快速学习一些东西的时候，偶尔有一些教程是很好的。只是要退出教程的“灵薄狱”。

24. 其他大部分的开发者也会编写垃圾代码。别为此而丧失信心。他们这么做一定有原因。

25. 观看开发者会议的讲座，并关注思想领袖。有很多很好的经验可以借鉴，而且很容易得到启发。

26. 在成为更好的开发者的过程中，我们都会遇到瓶颈。向有成就的开发者寻求建议。不要害怕给一个随机的开发者发送消息。

27. 以 GUID/UUID 作为实体 ID，这使得处理起来更加简单。但是，请注意你的取舍。

28. 遵守 SOLID 原则。它们易于理解，并且可以改进代码质量。诸如“开发 / 封闭原则无关紧要”之类的声明会反过来咬住你。

29. 当选项数目有限时，使用枚举代替字符串作为参数。

30. 在模块中安排代码（项目以 .NET 术语表示）。别把所有的东西都放在一个模块里。很快就会失去控制。

31. 你将要解决的业务问题，或者将要开发的业务应用，都是必须牢记的。对于企业来说，代码只是实现目标的一种手段。

32. 将软件开发视为一种手艺。编写出有目的、漂亮的代码。主动去提高自己的技能。

肯定会有开发者对我的一些建议提出质疑，你总能找到不同的观点、方法和想法。

多思考是有益的。对你认为对你有意义的事情要保持批判的态度。

作者介绍：

Nicklas Millard，是一家发展最快的银行的软件开发工程师，负责为关键任务构建金融服务基础设施。曾担任 Big4 的高级技术顾问，为商业客户和政府部门开发软件。

原文链接:

https://medium.com/swlh/32-opinionated-advice-and-lessons-learned-in-software-development-cc1939847f0a