revise

Author: ying.liu

developer-working-guide.md

@@ -1,24 +1,20 @@
 # 程序员工作指南
 
-用软件创造未来的程序员，勤劳快乐，责任重大。环顾四周，多数软件团队的研发能力相对计算机的巨大潜力和广泛的业务需求有巨大鸿沟，开发效率和软件的质量令人忧伤。稍感安慰的是半个多世纪的编程历史积累了一些最佳实践（best practices)。遵守基于这些最佳实践的规则能大大改善程序员的工作效率。
-
-持续的、高质效的软件开发能力是现代企业的核心竞争力，可以带来企业业务和个人生活质量的指数提高。JUST DO IT! 何乐不为？
+持续的、高质效的软件开发能力是现代企业的核心竞争力。用软件创造未来的程序员责任重大，任劳任怨。可是环顾四周，多数软件团队的研发能力相对计算机的巨大潜力和广泛的业务需求有巨大鸿沟，开发效率低，软件的质量令人忧伤。稍感安慰的是半个多世纪的编程历史积累了一些最佳实践（best practices)。遵守基于这些最佳实践的规则能大大改善程序员的工作效率。
 
 ## 1 前提
 
 程序员的工作规则是基于如下的前提：
 
 1. 真实和持久的幸福源于和一群优秀的同事接受挑战、创造和分享非凡价值。
 
-1. 程序员是务实的（pragmatic)成年人，肩负责任，值得信任。
+1. 程序员是务实的（pragmatic)成年人，值得信任。
 
 1. 规则是用来打破的，但需要足够的事实理由。
 
-1. 所有规则都是明确可执行的。
-
-1. 软件就是业务，软件开发是不间断的连续过程，直到企业/程序员/用户的生命尽头。
+1. 软件就是业务，软件开发是不间断的连续过程，直到企业/程序员/用户的生命尽头。在心智和身体上都需要有长远准备。
 
-1. 每一行语句都会有 10 次以上的修改，可维护性仅次于正确性。
+1. 每一行语句都会有 10 次以上的修改，可维护性是根本。
 
 1. 有自动测试的软件功能才算完成。
 
@@ -28,9 +24,7 @@
 
 1. 小就是美。便于理解和重用。
 
-1. 程序员拥有工作需要的所有资源，尤其是项目相关信息。
-
-1. 技术的目的是为了业务。程序员必须是相关业务领域的专家。
+1. 程序员拥有工作需要的所有资源，尤其是全局信息。
 
 ## 2 基本规则
 
@@ -46,61 +40,61 @@
 
 体魄健康，头脑才灵。
 
-### 2.4 一次完成一个任务。
+### 2.4 程序员是业务专家
 
-避免上下文切换带来高效率。一个完成的任务好过三个未完成的任务。过程高效而且结果可用。
+技术的目的是为了业务。熟悉业务和市场趋势才能创造最大价值。
+
+### 2.5 一次完成一个任务。
+
+一个完成的任务好过三个未完成的任务。避免了上下文切换，过程高效而且结果可用。
 
 ## 3 团队规则
 
-### 3.1 非常认真的审核设计文档与代码。
+### 3.1 分享团队管理职责
+
+团队的沟通、进度更新、不重犯错的方法、业务的改善等等，都是每个人的责任。大家分享团队管理职责，轮流主持各种会议。团队的每个问题都是我的问题。
+
+### 3.2 认真的审核。
 
-审核是高效的质量保证。同时也是学习和沟通的好机会。
+设计文档与代码的审核是高效的质量保证。同时也是学习和沟通的好机会。
 
-### 3.2 程序员参与产品设计并计划开发进度。
+### 3.3 程序员参与产品设计并计划开发进度。
 
 程序员是业务专家和实现者。值得信赖和激发最大潜力。
 
-### 3.3 持续编写相关技术文档。
+### 3.4 持续编写相关技术文档。
 
 开发过程中随时编写相关技术文档，包括软件设计文档，技术选型，最佳实践，常见问题等。这样便于维护和分享。
 
-### 3.4 所有 bug 都在代码库管理。
-
-相关的讨论和解决方案都有历史记录。
-
 ### 3.5 提倡异步通信。
 
-程序员被打断一次平均需要 20 分钟才能恢复高效工作状态。尽量采用短信、邮件、代码库事件等异步通信方式沟通或约定面对面交流时间。
-
-### 3.6 分享团队管理职责
-
-团队的沟通、进度更新、不重犯错的方法、业务的改善等等，都是每个人的责任。大家分享团队管理职责，轮流主持各种会议。团队的每个问题都是我的问题。
+程序员被打断一次平均需要 20 分钟才能恢复高效工作状态。尽量采用短信、邮件、Bug 库、代码库事件等异步通信方式沟通或约定面对面交流时间。
 
 ## 4 编码规则
 
 ### 4.1 自动化的测试是开发编码的一部分。
 
 没有自动测试的代码不算完成。自动化的测试为十次以上的重构带来至关重要的质量保证。
 
-### 4.2 大的功能需要先设计再编码。
+### 4.2 持续重构。
 
-对于稍微复杂的、费时超过一个工作日的功能，先写设计文档。这样通常更快而且质量更好。
+看到需要改进的代码就立刻重构，目的是保持代码结构的清晰。大概编码的 20% 时间是用于重构的。反之，如果不良代码持续累积，系统变大之后发生质变，很可能无法正常工作或难以修改。同样的修复，后期维护成本是前期的数倍，而且影响更大更难控制。
 
-### 4.3 重复一次以后再抽象。
+### 4.3 每个函数不要超过 10 条语句。
 
-不要一开始就预想各种使用场景来做抽象，低效而且误导。重复一次以后再抽象会更高效。
+便于理解和重用。不超过 10 的规则也适用于一个目录不超过 10 个文件或其他类似可拆分的场合。
 
-### 4.4 持续重构。
+### 4.4 大的功能需要先设计再编码。
 
-看到需要改进的代码就立刻重构，目的是保持代码结构的清晰。大概编码的 20% 时间是用于重构的。反之，如果不良代码持续累积，系统变大之后发生质变，很可能无法正常工作或难以修改。同样的修复，后期维护成本是前期的数倍，而且影响更大更难控制。
+对于稍微复杂的、费时超过一个工作日的功能，先写设计文档。这样通常更快而且质量更好。
 
-### 4.5 每个函数不要超过 10 条语句。
+### 4.5 一个函数的所有语句都在单一抽象层(Single Level Abstraction)。
 
-便于理解和重用。不超过 10 的规则也适用于一个目录不超过 10 个文件或其他类似可拆分的场合。
+保持程序的结构清晰，而且也容易理解。
 
-### 4.6 一个函数的所有语句都在单一抽象层(Single Level Abstraction)。
+### 4.6 重复一次以后再抽象。
 
-保持程序的结构清晰，而且也容易理解。
+不要一开始就预想各种使用场景来做抽象，低效而且误导。重复一次以后再抽象会更高效。
 
 ### 4.7 软件文档和注释。