开发流程与思考
DoD 验收标准列表
- DoD的每一个检查项都是可验收的
- 在开始着手于一件事上时，就需要确定好细节项
- 尽快消除不确定项，达成共识
精益创业
- 面向不确定性创建新事物
- 方式论：创建（build ）-测量（measure）-认知（learn），三者循环迭代
- 用最少的成本，干有价值的事
- 作为一个开发人员。在平时，产品提出的需求虽然可行，但在当下有限的人力，物力，时间的，及该需求的重要度低的情况下可延后处理。
- 开发人员遵循开发原则是 当需求来临时，你需要知道它为什么要做，有什么意义与好处（可通过用户故事体现），才能去做。而不应该逆来顺受，来什么，做什么。
开发方式
从未来考虑问题
- 进行一次沙盘模拟
- 从结果入手，如果需要开发一个产品。待入上线后的情况，从未来考虑，比如上线时需要什么配置，上线后系统崩溃怎么办，线上数据如何准备？
分解任务
- 不同层级的人，任务分解程度不同，比如作为一个刚了解开发的人，将任务，分为 获取链接，分析，上传三步。
- 当任务得到合理的分解，执行起来也就按部就班，有条不紊。
- 分解成各个微操之后，也会让任务执行得以拥抱变化。当被打断时候，能很容易开启下一个流程的开发。
- 做好微任务的安排
测试先行
- 测试 - 开发 - 重构 环环相扣
- 测试先行可以更好理清当前开发的需求，完成特定需要的功能
代码防腐
代码的不断交接，不断腐化
- 当需要维护一段代码时，每个人只是完成了当时一部分的工作，代码中的异味会越来越重
- 开发人员每当维护别人的代码时，总是觉得别人的代码很乱。给这段代码添加新功能时，不免产生 “代码都这样了，我不能乱改，我只能按照它原来的风格，就给它添加功能就好了” 的想法。
- 解决方法：设计原则，SOLID。
设计模式，设计原则？
- 在编程时，总想着去套用一系列设计模式，当有时却适得其反。
- 无法正确使用设计模式，或感觉其无用，往往是因为没有形成自己的知识体系。
- 设计模式只是战略上的建议，要想形成体系，灵活运用就得领悟设计原则。
- 在遵循SOLID原则的前提下，进行编码，在不经意间就能使用到设计模式，尽管你不知道模式的名称
- 比如，单一职责：
- Robert Martin的架构整洁之道中，描述单一职责为 “一个模块仅仅对一类
角色负责” - 有一个Employee类，有三个方法 ：
- calculatePay() 是财务部门关心的
- reportHours() 是人力资源部门关心的
- save() 是系统业务部门关心的
- 因为calculatePay与reportHours都有 正常工作时间的计算，为了避免重复将它抽为 regularHours方法
- 现 财务部门修改正常工作时间的方式，人力资源部不需要修改。你只看到了calculatePay调用了regularHours，所以修改了regularHours，然而却导致人力资源部查询的错误，从而导致公司受损
- 此处的regularHours 在为不同的
角色服务，所以一旦需求变化，它就是修改的重灾区 - 这个时候，就应该将上述三个方法分拆为三个面向不同
角色的类
- Robert Martin的架构整洁之道中，描述单一职责为 “一个模块仅仅对一类
- 小到开发中的每个方法，对象。大到对大型系统架构的微服务拆分，转型。 都需要 识别不同
actor，正确理清限界的上下文，划分能够独自演进的功能模块
维护他人代码时
当接手一项新工作，新环境时
1.业务
- 第一步先理解工作业务（做什么，解决了什么，流程是什么）
2.技术
- 了解技术栈
- 系统的业务架构是什么（有哪些模块，与哪些外部系统有交互）
- 外部接口方式，承接的协议是什么
- 内部各个模块如何划分，模块职责是什么，分层抽象的东西是什么
- 系统构建的脚本，代码的结构怎么样的
3.团队运作
- 外部：需求来源是那儿，产品和面向的用户是谁
- 内部：定期的和日常活动有什么，企业文化
