无论短期还是长期项目，它们都包含相似的启动和实施周期：
三个时期工作内容如下：
- 技术准备期： 开始与架构实施相关的工作，如搭建脚手架、测试环境、部署等
- 业务回补期： 填补第一个时期造成的业务进度落后问题，以技术实践业务来证明技术的价值
- 成长优化期：持续对项目的技术和业务进行优化、以实现开发及业务人员诉求
在项目的不同时期，考虑因素不一样，会出现一定程度的偏差，关注这些偏差的，则是技术负责人，为此将分析这三个时期的四个层级架构间的关系
1.技术负责人与架构关系
技术负责人是项目架构实施的的保证，是施工队的队长，队长的日常需要做的事情有：
- 适当平衡业进度和技术的方案
- 解决重要、复杂的技术问题
- 帮助团队的其他成员成长
- 从全局考虑整个额项目的技术和业务问题
项目的技术负责人不管是从一开始就负责架构的设计，还是后面接手该项目的架构负责人，都需要对架构进行优化负责，保证项目正常实施。 我们设计软件架构时，考虑的不仅是架构技术方案，还要包括以下内容：
- 技术方案的设计
- 技术方案的落地
- 保证技术方案的实施
- 确保技术方案的上线
- 关注技术方案的后续维护
2.技术准备期： 探索技术架构
这个阶段是技术第一，业务第二，在这个阶段我们应该关注：
- 架构设计：即设计系统的架构
- 概念设计：验证先前设计的架构是否可行
- 迭代0：搭建系统的基础设施
这三个阶段都是强技术性的，需要花费大量时间
架构设计
详见第一章
架构原型证明
架构设计之后，从设计证明它的可行性，将设计的前端技术和架构思想进行组合，如果不能正常结合，则需要考虑另外方式。
迭代0：搭建完整工具
完成概念验证之后，就开始迭代0，以完成项目配套的技术工作 当我们开始一个项目的时候，进入的迭代版本都为1,那在项目开始之前进行准备工作，使用的概念证明则称为迭代0，我们需要做的基本事项是：
- 创建应用脚手架
- 创建项目代码库
- 搭建持续集成、持续交付
- 进行各环境账号准备、开发人员权限等配置
- 配置配套的工具，如代码审查、自动化原生应用的上传
- 更颗粒度的技术选型
- 一些迭代0 的项目规范、技术培训
- 一些代码的检测配置。如eslint
这个阶段结束的标识是：项目成员能正常的进行项目开发，并且没有大的区别
体现规范和原则
项目中肯定会有经验不丰富的员工，可以将代码进行整理，形成一个参考，让新成员或经验不丰富的同学进行照猫画虎的编写业务代码
3.业务回补期，应对第一次deadline
当团队能正常的开发业务逻辑的时候，可能存在一定的进度落后问题，于是在优先级上就会变成业务第一，技术第二 在上一个阶段，花费了大量时间在概念上，所以需要再这个阶段进行弥偿还，在项目开发中，也会面临人员技术能力不足，或者开发人员人数规模扩大，管理混乱的问题。当这些问题解决后，关注点就会放在业务上。
3.1追补业务
虽然技术是实现业务的方式，但是业务无法存活不下去，那技术就无法证明其价值 如果因为概念验证导致一定的进度落后，那么在合适的时候，我们还会临时的后置部分技术需求，用于按时完成业务，比如在必要的时候，单元测试、UI测试都可以适当减少
3.2实践测试策略
在编写业务代码过程中，还要不断面临测试上的压力， 一般情况下，测试人员是在项目进行开发一段时间后才开始介入测试，前后端的联调可能还没有完全准备好，无法进行完整的测试，另一方面，可能测试的业务内容比较少，部分功能无法完整的串联起来，只有在项目上线前，进行一个相关的、完整的回归测试
对于一个前后端分离的项目，平时开发中已经做了大量的联调，基本能符合上线，只是我们设计架构时可能会尚未考虑的情况如：
- 没有进行集成第三方测试，无法验证业务的完整性
- 没有准备好一个稳定的测试环境，提供给测试人员进行测试
- 没有较为真实的数据，验证一些极端的条件
- .......
3.3 上线准备
购买、申请好一些列相关事宜后，如：服务器，相应资源，审批流程等等 准备好相关的Node线上调试环境，有计划的使用Docker,以及相关的devOps技能
3.4 提升团队能力
初级程序员需要对他进行： 结对，文档，练习，培训等方式，在日常开发中需要对他进行：代码规范，代码原则培训。进行代码重构时需要对他进行： 代码检查以及质量验收，并在开发环境中进行项目测试，没问题后才能上线。
技术分享会一般时间为30~60分钟，需要结合实践示列
一些面向新人的知识传递方式：
- navigator-driver（领航员-驾驶员） ： navigator关注如何实现功能，driver负责实现，并且由navigator告诉如何实现代码
- ping-pong模式：常见的TDD模式，由A编写某个功能，B实现测试，随后调反过来，由B实现某个功能，B负责测试
- 键鼠模式：编程时，一方控制编程，一方控制键盘，这种能帮新人快熟知道快捷键
最常见的还是第一种
3.4 偿还技术债务
在项目准备期，我们在构建技术基础的时候花费大量时间，在业务回补期，我们支持业务花费了大量时间，在两个时期我们都采取有了一些妥协的方法，目的是为了按期交付，所以会出现代码质量、测试覆盖率、依赖等问题，这些问题不是一两天造成的，需要制定一个长期的时间进行优化和修复，代码中充满了各种code small ，那么需要对代码进行codeview的方式不断提高团队成员水平
