高效的开发编码原则

高效的开发编码原则
1. Rule Of Three 原则
这是一条代码重构的经验法则，用于决定何时将复制的代码段替换为新的代码 /
过程 / 方法。

它的含义是，第一次用到某个功能时，你写一个特定的解决方法；第二次又用到的
时候，你拷贝上一次的代码；第三次出现的时候，你要着手「抽象化」，写出通用
的解决方法。

该原则的主要思想是使代码 / 过程 / 方法更加通用，从而保证在其他地方可以重
复使用。

2. 应用程序结构与编码方式保持一致
应用程序结构与编码方式保持一致有助于提高其可读性和可维护性。

尝试制定编码标准，这有助于保持编码一致性。

编码标准应该与变量的命名规则一
样少。

另一大问题是应用程序的结构，开发人员进行更改或添加新内容的地方应该
很明显。

3. 减少程序嵌套
if 里面嵌套 if 会使得程序很混乱，代码很难读。

在编写代码时可能无法绕开这
些问题，但你需要经常查看代码结构。

else if 同样如此，因此需要尽量避免嵌套。

一种有效的解决方法是卫语句：卫语句把复杂的条件表达式拆分成多个条件表达
式。

不使用卫语句的编码方式：
if (account != null){ if (order != null) { if (order.term == Term.Annually) { // term annually } else if (order.term == Term.Monthly) { // term monthly } else { throw new
InvalidEnumArgumentException(nameof(term)); } } else
{ throw new ArgumentNullException(nameof(subscription)); }}
使用卫语句的编码方式：
if (account == null){ throw new
ArgumentNullException(nameof(account));}if (order == null){ throw new ArgumentNullException(nameof(order));}if (order.term ==
Term.Annually){ // term annually (return here)}if (order.term ==
Term.Monthly){ // term monthly (return here)}throw new InvalidEnumArgumentException(nameof(order.term));
4. 了解全局很重要
了解全局有助处理较小的细节。

一旦了解了全局，你就不会花很长的时间在小细节
上。

5. 程序中的命名
在编程中进行命名是最困难的事情之一，包括为一个类、一个方法命名，甚至是为变量命名。

优秀的开发人员会花时间考虑相关的命名方式，这样会增加程序的可读性。

6. 减少技术负债
技术负债指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。

这种技术上的选择就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。

软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。

对于技术负债问题，提高预估时间有助于解决这类问题。

尽自己最大的努力写好代码，否则你将不断地进行代码完善。

7. 提高预估时间
你会看到，高级开发人员总是给任务预留更多的时间，因为他们知道完成任务所需的时间总是高于预期，而且在评估阶段增加一个缓冲时间可以真正帮助你把事情做好。

这确实有助于解决技术负债问题。

如果你低估了任务完成时间，你就可能会因为时间不够而写出仅仅可以运行的代码，简洁性、可维护性就顾不上了。

8. 文档和代码注释
文档和代码注释有助于保存上下文和共享知识。

你会听到有经验的人一直在说，我们是否可以记录这个过程，或者代码审查失败，因为对接口之类的内容没有任何注释。

9. 删除不需要的代码
许多缺乏自信的开发人员会注释掉大量的代码块，而不是选择删除。

但是代码版本控制是有目的的！优秀的开发人员会删除应用程序中不好的代码。

10. 花时间进行代码评审
优秀的开发人员会花更多的时间在代码评审上，代码评审的重要性包括：
•更早地发现错误；
•提高开发人员的技能，并让团队的其他成员参与到良好的实践中；
•共享知识；
•一致的设计和实现。

最好的代码评审过程是：
对于一个风险较小的任务，1 名开发人员评审就可以；中型 / 大型更改或者是有风险的更改，应由 3 名开发人员进行评审，其中须有一位是高级开发人员；风险极高的更改或者是正在开发的应用程序的新部分，应该安排一次会议，3 名开发人员中至少有一位是首席开发人员，他们一起完成每条线并提出观点。

11. 编写好的测试
你会注意到经验丰富、能力更强的开发人员花更多的时间编写好的测试。

拥有好的测试可以帮助你更有信心地扩展应用程序，并减少错误。

12. 花时间设计程序
在真正投入写代码之前，开发者会经过一番思考并将代码分解成小块。

这有助于他们更好地将所有内容组合在一起并创建更清晰的代码。

13. 关注基础原理，而不是语法
更多地关注基础原理，而不是语法，有助于开发者更快地发现问题，也能更好地理解问题并在搜索引擎上搜索解决方案。

14. 让搜索引擎成为你最好的朋友
高级开发者都是用搜索引擎来解决问题的专家。

从上一条也可以看出，他们关注基础原理而不是语法，因此知道要搜索的关键词。

如果你一直专注于语法，这将很难做到。

15. 首先确保程序能运行，然后再完善
你经常会看到一些相对较弱的开发人员，他们一开始花费大量的时间让程序看起来漂亮，但之后发现，程序不能运行。

优秀的开发人员会在更早的阶段找到愉快的工作方式。

在他们把事情做好之前，尽早发现问题。

这可以帮助项目进行得更加顺利。

16. 风险管理和问题解决
高级开发人员可以定义风险，能够通过应用设计模式提炼出复杂的问题，并且能够根据以往的经验独立解决不同的问题。

17. 多提问
高级开发人员什么都想知道。

他们不介意问问题，包括技术问题和业务问题，尽管这些问题听起来非常简单。

理解业务需求有助于开发者编写更好的代码！他们不害怕问问题，因为他们对自己的能力有信心。

18. 尽可能将逻辑排除在数据库之外
这一点可以归结为你正在构建的应用程序的类型，并且仅当它不会影响性能时才适用。

高级开发人员知道将数据库查询保留为简单的 C R UD操作。

C R UD 是指在做计算处理时的增加 (C re at e)、检索(Re t rie v e)、更新(Updat e) 和删除(D ele t e)。

接下来，业务逻辑层应将 C R UD操作整合在一起。

这有助于开发人员了解在哪里寻找业务逻辑。

如果你在数据库查询和代码中有逻辑，这会很快变得混乱！
19. 保持代码简洁
保持代码简洁是最好的做法。

即使这意味着要编写更多行代码。

下面是相对较弱的开发人员编写的单行代码：
•return dir.Keys.Any(k => k >= limit) ? dir.First(x => x.Key >= limit).Value : dir[dir.Keys.Max()];
这样的代码虽然可以运行，但可读性很低。