add list number

Author: ying.liu

developer-working-guide.md

@@ -4,11 +4,11 @@
 
 持续的、高质效的软件开发能力是现代企业的核心竞争力，可以带来企业业务和个人生活质量的指数提高。JUST DO IT! 何乐不为？
 
-## 前提
+## 1 前提
 
 程序员的工作规则是基于如下的前提：
 
-1. 真实和持久的幸福源于和一群优秀的同事接受挑战、创造非凡价值。
+1. 真实和持久的幸福源于和一群优秀的同事接受挑战、创造和分享非凡价值。
 
 1. 程序员是务实的（pragmatic)成年人，肩负责任，值得信任。
 
@@ -24,84 +24,88 @@
 
 1. Bug 不可避免，但是很丢人，严重的错误是灾难性的。
 
-1. 沟通合作比想象的困难和必要，需要系统的训练和机制。
+1. 沟通合作比想象的困难和必要，需要明确要求和保证机制。
 
 1. 小就是美。便于理解和重用。
 
 1. 程序员拥有工作需要的所有资源，尤其是项目相关信息。
 
 1. 技术的目的是为了业务。程序员必须是相关业务领域的专家。
 
-## 工作规则
+## 2 基本规则
 
-### 0. 对每个错误需要回答怎么不再犯
+### 2.1 对每个错误需要回答怎么不再犯
 
 不再犯同样的错误是最有效的工作方法。
 
-### 1. 每周 40 小时工作，20 小时学习。
+### 2.2 每周 40 小时工作，20 小时学习。
 
 清醒的头脑和不断学习是持续高效的基本保证。偶尔的冲刺可以用 20 小时的学习时间来工作，但是不应该成为常态。不鼓励熬夜，禁止每周工作超过 60 个小时。
 
-### 2. 每周锻炼 4 次，每次 1 个小时以上。
+### 2.3 每周锻炼 4 次，每次 1 个小时以上。
 
 体魄健康，头脑才灵。
 
-### 3. 自动化的测试是开发编码的一部分。
+### 2.4 一次完成一个任务。
 
-没有自动测试的代码不算完成。自动化的测试为十次以上的重构带来至关重要的质量保证。
-
-### 4. 大的功能需要先设计再编码。
+避免上下文切换带来高效率。一个完成的任务好过三个未完成的任务。过程高效而且结果可用。
 
-对于稍微复杂的、费时超过一个工作日的功能，先写设计文档。这样通常更快而且质量更好。
+## 3 团队规则
 
-### 5. 非常认真的审核设计文档与代码。
+### 3.1 非常认真的审核设计文档与代码。
 
 审核是高效的质量保证。同时也是学习和沟通的好机会。
 
-### 6. 重复一次以后再抽象。
+### 3.2 程序员参与产品设计并计划开发进度。
 
-不要一开始就预想各种使用场景来做抽象，低效而且误导。重复一次以后再抽象会更高效。
+程序员是业务专家和实现者。值得信赖和激发最大潜力。
 
-### 7. 随时重构。
+### 3.3 持续编写相关技术文档。
 
-看到需要改进的代码就立刻重构，目的是保持代码结构的清晰。大概编码的 20%时间是用于重构的。
+开发过程中随时编写相关技术文档，包括软件设计文档，技术选型，最佳实践，常见问题等。这样便于维护和分享。
 
-### 8. 每个函数不要超过 10 条语句。
+### 3.4 所有 bug 都在代码库管理。
 
-便于理解和重用。
+相关的讨论和解决方案都有历史记录。
 
-### 9. 一个函数的所有语句都在单一抽象层(Single Level Abstraction)。
+### 3.5 提倡异步通信。
 
-保持程序的结构清晰，而且也容易理解。
+程序员被打断一次平均需要 20 分钟才能恢复高效工作状态。尽量采用短信、邮件、代码库事件等异步通信方式沟通或约定面对面交流时间。
 
-### 10. 程序员参与产品设计并计划开发进度。
+### 3.6 分享团队管理职责
 
-程序员是业务专家和实现者。值得信赖和激发最大潜力。
+团队的沟通、进度更新、不重犯错的方法、业务的改善等等，都是每个人的责任。大家分享团队管理职责，轮流主持各种会议。团队的每个问题都是我的问题。
 
-### 11. 编写相关技术文档。
+## 4 编码规则
 
-技术文档包括软件设计文档，技术选型，最佳实践，常见问题等。这样便于维护和分享。
+### 4.1 自动化的测试是开发编码的一部分。
 
-### 12. 软件文档和注释。
+没有自动测试的代码不算完成。自动化的测试为十次以上的重构带来至关重要的质量保证。
 
-每个共用函数和模块都应该有相应 API 文档。源代码有适当的注释。
+### 4.2 大的功能需要先设计再编码。
 
-### 13. 软件运行日志（Log）是程序的一部份。
+对于稍微复杂的、费时超过一个工作日的功能，先写设计文档。这样通常更快而且质量更好。
 
-日志对运维和错误调试至关重要。其层级（Level）和相关信息需要仔细规划。
+### 4.3 重复一次以后再抽象。
 
-### 14. 所有 bug 都在代码库管理。
+不要一开始就预想各种使用场景来做抽象，低效而且误导。重复一次以后再抽象会更高效。
 
-相关的讨论和解决方案都有历史记录。
+### 4.4 持续重构。
 
-### 15. 一次完成一个任务。
+看到需要改进的代码就立刻重构，目的是保持代码结构的清晰。大概编码的 20%时间是用于重构的。
 
-避免上下文切换带来高效率。完成一个好过三个完成半个。
+### 4.5 每个函数不要超过 10 条语句。
 
-### 16. 提倡异步通信。
+便于理解和重用。
 
-程序员被打断一次平均需要 20 分钟才能恢复高效工作状态。尽量采用短信、邮件、代码库事件等异步通信方式沟通或约定面对面交流时间。
+### 4.6 一个函数的所有语句都在单一抽象层(Single Level Abstraction)。
 
-### 17. 分享团队管理职责
+保持程序的结构清晰，而且也容易理解。
 
-团队的沟通、进度更新、不重犯错的方法、业务的改善等等，都是每个人的责任。大家分享团队管理职责，轮流主持各种会议。团队的每个问题都是我的问题。
+### 4.7 软件文档和注释。
+
+每个共用函数和模块都应该有相应 API 文档。源代码有适当的注释。
+
+### 4.8 软件运行日志（Log）是程序的一部份。
+
+日志对运维和错误调试至关重要。其层级（Level）和相关信息需要仔细规划。