revise working guide

Author: ying.liu

developer-working-guide.md

@@ -6,100 +6,102 @@
 
 程序员的工作规则是基于如下的前提：
 
-1. 真实和持久的幸福源于和一群优秀的同事接受挑战、创造和分享非凡价值。
+1. 真实和持久的幸福源于和一群优秀的同事达成共识、接受挑战、创造和分享非凡价值。
 
-1. 程序员是务实的（pragmatic)成年人，值得信任。
+1. 软件就是业务，软件开发是不间断的持续过程，直到企业/程序员/用户的生命尽头。在心智和身体上都需要有长远准备。
 
-1. 规则是用来打破的，但需要足够的事实理由。
-
-1. 软件就是业务，软件开发是不间断的连续过程，直到企业/程序员/用户的生命尽头。在心智和身体上都需要有长远准备。
+1. 每个程序员都是业务的驱动者，拥有推动业务需要的所有知情权、资源和权利。
 
 1. 每一行语句都会有 10 次以上的修改，可维护性是根本。
 
-1. 有自动测试的软件功能才算完成。
-
 1. Bug 不可避免，但是很丢人，严重的错误是灾难性的。
 
-1. 沟通合作比想象的困难和必要，需要明确要求和保证机制。
-
-1. 小就是美。便于理解和重用。
+1. 沟通合作、达成共识比想象的困难和必要，需要学习和建立机制。
 
-1. 程序员拥有工作需要的所有资源，尤其是全局信息。
+1. 小就是美，便于理解和重用。
 
 ## 2 基本规则
 
 ### 2.1 对每个错误需要回答怎么不再犯
 
 不再犯同样的错误是最有效的工作方法。
 
-### 2.2 每周 40 小时工作，20 小时学习。
+### 2.2 每周 40 小时工作，20 小时学习
 
 清醒的头脑和不断学习是持续高效的基本保证。偶尔的冲刺可以用 20 小时的学习时间来工作，但是不应该成为常态。不鼓励熬夜，禁止每周工作超过 60 个小时。
 
-### 2.3 每周锻炼 4 次，每次 1 个小时以上。
+### 2.3 每周锻炼 4 次，每次 1 个小时以上
 
 体魄健康，头脑才灵。
 
-### 2.4 程序员是业务专家
+### 2.4 达成共识
 
-技术的目的是为了业务。熟悉业务和市场趋势才能创造最大价值。
+在业务和技术领域的决策、设计、代码等都有审查（review）。事关重要的都要达成共识 -- 经过大家充分讨论和理解优劣点。
 
-### 2.5 一次完成一个任务。
+### 2.5 程序员是业务专家
 
-一个完成的任务好过三个未完成的任务。避免了上下文切换，过程高效而且结果可用。
+技术的目的是为了业务。熟悉业务和市场趋势才能创造最大价值。
 
 ## 3 团队规则
 
-### 3.1 分享团队管理职责
+### 3.1 赋能个人
+
+每个人都可以看到做事所需要的业务和技术信息、代码、资源。可以参与所有层级的决策。必要时第一线可以调动全公司资源来达成目标。
+
+### 3.2 达成共识
+
+决策是集体智慧的结果。相关人员都有发言权并充分参与讨论，每个人都清晰理解决策的过程、利弊考量和结果。
+
+### 3.3 分享团队管理职责
 
 团队的沟通、进度更新、不重犯错的方法、业务的改善等等，都是每个人的责任。大家分享团队管理职责，轮流主持各种会议。团队的每个问题都是我的问题。
 
-### 3.2 认真的审核。
+### 3.4 认真的审核
 
 设计文档与代码的审核是高效的质量保证。同时也是学习和沟通的好机会。
 
-### 3.3 程序员参与产品设计并计划开发进度。
+### 3.5 程序员参与产品设计并计划开发进度
 
 程序员是业务专家和实现者。值得信赖和激发最大潜力。
 
-### 3.4 持续编写相关技术文档。
+### 3.5 持续编写相关技术文档
 
 开发过程中随时编写相关技术文档，包括软件设计文档，技术选型，最佳实践，常见问题等。这样便于维护和分享。
 
-### 3.5 提倡异步通信。
+### 3.6 提倡异步通信
 
 程序员被打断一次平均需要 20 分钟才能恢复高效工作状态。尽量采用短信、邮件、Bug 库、代码库事件等异步通信方式沟通或约定面对面交流时间。
 
 ## 4 编码规则
 
-### 4.1 自动化的测试是开发编码的一部分。
+### 4.1 自动化的测试是开发编码的一部分
 
 没有自动测试的代码不算完成。自动化的测试为十次以上的重构带来至关重要的质量保证。
 
-### 4.2 持续重构。
+### 4.2 持续重构
 
 看到需要改进的代码就立刻重构，目的是保持代码结构的清晰。大概编码的 20% 时间是用于重构的。反之，如果不良代码持续累积，系统变大之后发生质变，很可能无法正常工作或难以修改。同样的修复，后期维护成本是前期的数倍，而且影响更大更难控制。
 
-### 4.3 每个函数不要超过 10 条语句。
+### 4.3 每个函数不要超过 10 条语句
 
 便于理解和重用。不超过 10 的规则也适用于一个目录不超过 10 个文件或其他类似可拆分的场合。
 
-### 4.4 大的功能需要先设计再编码。
+### 4.4 大的功能需要先设计再编码
 
 对于稍微复杂的、费时超过一个工作日的功能，先写设计文档。这样通常更快而且质量更好。
 
-### 4.5 一个函数的所有语句都在单一抽象层(Single Level Abstraction)。
+### 4.5 一个函数的所有语句都在单一抽象层(Single Level Abstraction)
 
 保持程序的结构清晰，而且也容易理解。
 
-### 4.6 重复一次以后再抽象。
+### 4.6 重复一次以后再抽象
 
 不要一开始就预想各种使用场景来做抽象，低效而且误导。重复一次以后再抽象会更高效。
 
-### 4.7 软件文档和注释。
+### 4.7 软件文档和注释
 
 每个共用函数和模块都应该有相应 API 文档。源代码有适当的注释。
 
-### 4.8 软件运行日志（Log）是程序的一部份。
+### 4.8 软件运行日志（Log）是程序的一部份
 
 日志对运维和错误调试至关重要。其层级（Level）和相关信息需要仔细规划。