程序员的工作方法

开发流程与思考

DoD 验收标准列表

1. DoD的每一个检查项都是可验收的
2. 在开始着手于一件事上时，就需要确定好细节项
3. 尽快消除不确定项，达成共识

精益创业

1. 面向不确定性创建新事物
2. 方式论：创建（build ）-测量（measure）-认知（learn），三者循环迭代
3. 用最少的成本，干有价值的事
4. 作为一个开发人员。在平时，产品提出的需求虽然可行，但在当下有限的人力，物力，时间的，及该需求的重要度低的情况下可延后处理。
5. 开发人员遵循开发原则是 当需求来临时，你需要知道它为什么要做，有什么意义与好处（可通过用户故事体现），才能去做。而不应该逆来顺受，来什么，做什么。

开发方式

从未来考虑问题

1. 进行一次沙盘模拟
2. 从结果入手，如果需要开发一个产品。待入上线后的情况，从未来考虑，比如上线时需要什么配置，上线后系统崩溃怎么办，线上数据如何准备？

分解任务

1. 不同层级的人，任务分解程度不同，比如作为一个刚了解开发的人，将任务，分为 获取链接，分析，上传三步。
2. 当任务得到合理的分解，执行起来也就按部就班，有条不紊。
3. 分解成各个微操之后，也会让任务执行得以拥抱变化。当被打断时候，能很容易开启下一个流程的开发。
4. 做好微任务的安排

测试先行

1. 测试 - 开发 - 重构 环环相扣
2. 测试先行可以更好理清当前开发的需求，完成特定需要的功能

代码防腐

代码的不断交接，不断腐化

1. 当需要维护一段代码时，每个人只是完成了当时一部分的工作，代码中的异味会越来越重
2. 开发人员每当维护别人的代码时，总是觉得别人的代码很乱。给这段代码添加新功能时，不免产生 “代码都这样了，我不能乱改，我只能按照它原来的风格，就给它添加功能就好了” 的想法。
3. 解决方法：设计原则，SOLID。

设计模式，设计原则？

1. 在编程时，总想着去套用一系列设计模式，当有时却适得其反。
2. 无法正确使用设计模式，或感觉其无用，往往是因为没有形成自己的知识体系。
3. 设计模式只是战略上的建议，要想形成体系，灵活运用就得领悟设计原则。
4. 在遵循SOLID原则的前提下，进行编码，在不经意间就能使用到设计模式，尽管你不知道模式的名称
5. 比如，单一职责：
   1. Robert Martin的架构整洁之道中，描述单一职责为 “一个模块仅仅对一类 角色 负责”
   2. 有一个Employee类，有三个方法 ：
      1. calculatePay() 是财务部门关心的
      2. reportHours() 是人力资源部门关心的
      3. save() 是系统业务部门关心的
      4. 因为calculatePay与reportHours都有 正常工作时间的计算，为了避免重复将它抽为 regularHours方法
   3. 现 财务部门修改正常工作时间的方式，人力资源部不需要修改。你只看到了calculatePay调用了regularHours，所以修改了regularHours，然而却导致人力资源部查询的错误，从而导致公司受损
   4. 此处的regularHours 在为不同的 角色 服务，所以一旦需求变化，它就是修改的重灾区
   5. 这个时候，就应该将上述三个方法分拆为三个面向不同角色的类

• 小到开发中的每个方法，对象。大到对大型系统架构的微服务拆分，转型。 都需要 识别不同actor，正确理清限界的上下文，划分能够独自演进的功能模块

维护他人代码时

当接手一项新工作，新环境时

1.业务

1. 第一步先理解工作业务（做什么，解决了什么，流程是什么）

2.技术

2. 了解技术栈
3. 系统的业务架构是什么（有哪些模块，与哪些外部系统有交互）
4. 外部接口方式，承接的协议是什么
5. 内部各个模块如何划分，模块职责是什么，分层抽象的东西是什么
6. 系统构建的脚本，代码的结构怎么样的

3.团队运作

7. 外部：需求来源是那儿，产品和面向的用户是谁
8. 内部：定期的和日常活动有什么，企业文化

当接手一个你认为很烂的系统时

1. 创建测试防护网

2. 逐步拆分，逐步整改，逐步替换 - 小步快跑

3. 构建好独特的领域模型，利于划定不同角色，限定运作上下文

4. 在构建时，参考行业内对于系统构建比较成熟的理解。比如构建电商领域时，可供参考的领域模型非常成熟