开发流程
目前团队的开发模式还是基于传统的瀑布开发模式，整体开发流程涉及需求评审、测试用例评审、技术架构评审、开发与测试、验收与上线，这里主要基于 TL 的角度从需求管理、技术架构评审、代码评审、发布计划评审几个关键重点环节进行探讨，欢迎拍砖。
需求管理
美国专门从事跟踪 IT 项目成功或失败的权威机构 Standish Group 的 CHAOS Reports 报导了该公司的一项研究，该公司对多个项目作调查后发现，百分之七十四的项目是失败的，既这些项目不能按时按预算完成。其中提到最多的导致项目失败的原因就是”变更用户需求”。另外从历年的 Standish Group 报告分析看，导致项目失败的最重要原因与需求有关。Standish Group 的 CHAOS 报告进一步证实了与成功项目最密切的因素是良好的需求管理，也就是项目的范围管理，特别是管理好项目
的变更。
产品因需求而生，在产品的整个生命周期中，产品经理会收到来自各个方面的需求，但是每一个需求的必要性、重要性和实现成本都需要经过深思熟虑的分析和计划，避免盲目的决定需求或者变更需求，这样很容易导致工作混乱，技术 TL 如果不能正确的对需求进行把控，会导致整个项目偏离正确的轨道。
需求管理的第一步就是要梳理不同来源的需求，主要包括从产品定位出发、外部用户反馈、竞争对手情况、市场变化以及内部运营人员、客服人员、开发人员的反馈。首先技术 TL 对产品有足够认知和把控，简单来说就是我的产品是为了满足哪些人的哪些需求而做，产品需求一定要根植于客户的需求、根植于客户的环境。每款产品必定有其核心价值，能够为客户创造更多的价值，基于此考虑往往能得到一些核心需求，摒除价值不大的需求。
需求管理中最重要的就是对发散性需求的管理，往往因此也会导致产品在执行过程中不断的变更或增加需求。由于人的思维是发散性的，所以往往在产品构思的过程中会出现各种新鲜好玩的想法，这些想法可能来自领导或者产品经理自己，但是这些想法往往都是和产品核心方向不相关的，但是由于这些想法能够在当时带来诱惑，因此这些不相关的需求会严重干扰了技术团队的精力，打乱或者延误产品原本的计划。
同样技术研发同学也需要建立对产品的深度思考，不要把自己定位成产品需求的实现者，同样需要对需求负责。
很多时候需求的变更或增加是因为我们面临太多选择和想要的太多，没有适当的控制自己的欲望，并以自己的喜好来决定需求，这些因素很容易导致产品没有明确的方向、团队成员疲于奔命，但是却没有实际的成果。所以技术 TL 一定要能够评估出重新审视产品和筛选需求的优先级，识别每一个需求的必要性、重要性和实现成本。
通过深思熟虑给团队明确方向并专注，聚焦资源的支配，确保团队的精力都聚焦在产品的核心需求上。
技术架构评审
互联网时代，大家提倡敏捷迭代，总嫌传统方式太重，流程复杂，影响效率，什么都希望短平快，在扁平化的组织中，经常是需求火速分发到一线研发，然后就靠个人折腾去了，其实技术架构评审这同样是一个非常重要的环节。架构评审或技术方案评审的价值在于集众人的力量大家一起来分析看看方案里是否有坑，方案上线后是否会遇到不可逾越的重大技术问题，提前尽可能把一些事情先考虑到提出质疑其实对项目的健康发展有很大的好处。
基于架构评审，我们的目标核心是要满足以下几点：
- 设计把关，确保方案合格，各方面都考虑到了，避免缺陷和遗漏，不求方案多牛，至少不犯错。
- 保证架构设计合理和基本一致，符合整体原则。
- 维持对系统架构的全局认知，避免黑盒效应。
- 通过评审发掘创新亮点，推广最佳实践。
架构设计既要保证架构设计的合理性和可扩展性，又要避免过度设计。架构设计不仅仅是考虑功能实现，还有很多非功能需求，以及持续运维所需要的工作，需要工程实践经验，进行平衡和取舍。
架构评审需要以下几点：
技术选型：为什么选用 A 组件不选用 B、C 组件，A 是开源的，开源协议是啥？基于什么语言开发的，出了问题我们自身是否能够维护？性能方面有没有压测过？这些所有问题作为技术选型我们都需要考虑清楚，才能做最终决定。高性能：产品对应的 TPS、QPS 和 RT 是多少？设计上会做到的 TPS、QPS 和 RT 是多少？而实际上我们整体随着数据量的增大系统性能会不会出现明显问题？随着业务量、数据量的上升，我们的系统的性能如何去进一步提高？系统哪个环节会是最大的瓶颈？是否有抗突发性能压力的能力，大概可以满足多少的 TPS 和 QPS，怎么去做来实现高性能，这些问题都需要我们去思考。高可用：是否有单点的组件，非单点的组件如何做故障转移？是否考虑过多活的方案？是否有数据丢失的可能性？数据丢失如何恢复？出现系统宕机情况，对业务会造成哪些影响？有无其他补救方案？这些问题需要想清楚，有相应的解决方案。可扩展性：A 和 B 的业务策略相差无几，后面会不会继续衍生出 C 的业务策略，随着业务的发展哪些环节可以做扩展，如何做扩展？架构设计上需要考虑到业务的可扩展性。可伸缩性：每个环节的服务是不是无状态的？是否都是可以快速横向扩展的？
扩容需要怎么做手动还是自动？扩展后是否可以提高响应速度？这所有的问题都需要我们去思考清楚，并有对应的解决方案。弹性处理：消息重复消费、接口重复调用对应的服务是否保证幂等？是否考虑了服务降级？哪些业务支持降级？支持自动降级还是手工降级？是否考虑了服务的超时熔断、异常熔断、限流熔断？触发熔断后对客户的影响？服务是否做了隔离，单一服务故障是否影响全局？这些问题统统需要我们想清楚对应的解决方案，才会进一步保证架构设计的合理性。兼容性：上下游依赖是否梳理过，影响范围多大？怎么进行新老系统替换？新老系统能否来回切换？数据存储是否兼容老的数据处理？如果对你的上下游系统有影响，是否通知到上下游业务方？上下游依赖方进行升级的方案成本如何最小化？这些问题需要有完美的解决方案，稍有不慎会导致故障。安全性：是否彻底避免 SQL 注入和 XSS ？是否有数据泄露的可能性？是否做了风控策略？接口服务是否有防刷保护机制？数据、功能权限是否做了控制？小二后台系统是否做了日志审计？数据传输是否加密验签？应用代码中是否有明文的 AK/SK、密码？这些安全细节问题需要我们统统考虑清楚，安全问题任何时候都不能轻视。可测性：测试环境和线上的差异多大？是否可以在线上做压测？线上压测怎么隔离测试数据？是否有测试白名单功能？是否支持部署多套隔离的测试环境？测试黑盒白盒工作量的比例是怎么样的？新的方案是否非常方便测试，在一定程度也需要考量。可运维性：系统是否有初始化或预热的环节？数据是否指数级别递增？业务数据是否需要定期归档处理？随着时间的推移如果压力保持不变的话系统需要怎么来巡检和维护？业务运维方面的设计也需要充分考虑到。监控与报警：对外部依赖的接口是否添加了监控与报警？应用层面系统内部是否有暴露了一些指标作监控和报警？系统层面使用的中间件和存储是否有监控报警？只有充分考虑到各个环节的监控、报警，任何问题会第一时间通知到研发，阻止故障进一步扩散。
其实不同阶段的项目有不同的目标，我们不会在项目起步的时候做 99.99% 的可用性支持百万 QPS 的架构，高效完成项目的业务目标也是架构考虑的因素之一。
而且随着项目的发展，随着公司中间件和容器的标准化，很多架构的工作被标准化替代，业务代码需要考虑架构方面伸缩性运维性等等的需求越来越少，慢慢的这些工作都能由架构和运维团队来接。一开始的时候我们可以花一点时间来考虑这些问题，但是不是所有的问题都需要有最终的方案。
代码评审
代码质量包括功能性代码质量和非功能性代码质量，功能质量大多通过测试能够去发现问题，非功能性代码质量用户不能直接体验到这种质量的好坏，代码质量不好，最直接的“受害者”是开发者或组织自身，因为代码质量好坏直接决定了软件的可维护性成本的高低。代码质量应该更多的应该从可测性，可读性，可理解性，容变性等代码可维护性维度去衡量，其中 CodeReview 是保证代码质量非常重要的一个环节，建立良好的 CodeReview 规范与习惯，对于一个技术团队是一件非常重要核心的事情，没有 CodeReview 的团队没有未来。
每次项目开发自测完成后，通常会组织该小组开发人员集体进行代码 review，代码 review 一般 review 代码质量以及规范方面的问题，另外需要关注的是每一行代码变更是否与本次需求相关，如果存在搭车发布或者代码重构优化，需要自行保证测试通过，否则不予发布。
CodeReview 我会重点关注如下事情：
- 确认代码功能：代码实现的功能满足产品需求，逻辑的严谨和合理性是最基本的要求。同时需要考虑适当的扩展性，在代码的可扩展性和过度设计做出权衡，不编写无用逻辑和一些与代码功能无关的附加代码。
在真正需要某些功能的时候才去实现它，而不是你预见到它将会有用。 —— RonJeffries
-
编码规范：以集团开发规约、静态代码规约为前提，是否遵守了编码规范，遵循了最佳实践。除了形式上的要求外，更重要的是命名规范。目标是提高代码的可读性，降低代码可维护性成本。
-
潜在的 BUG：可能在最坏情况下出现问题的代码，包括常见的线程安全、业务逻辑准确性、系统边界范围、参数校验，以及存在安全漏洞 ( 业务鉴权、灰产可利用漏洞 ) 的代码。
-
文档和注释：过少（缺少必要信息）、过多（没有信息量）、过时的文档或注释，总之文档和注释要与时俱进，与最新代码保持同步。其实很多时候个人觉得良好的变量、函数命名是最好的注释，好的代码胜过注释。
-
重复代码：当一个项目在不断开发迭代、功能累加的过程中，重复代码的出现几乎是不可避免的，通常可以通过 PMD 工具进行检测。类型体系之外的重复代码处理通常可以封装到对应的 Util 类或者 Helper 类中，类体系之内的重复代码通常可以通过继承、模板模式等方法来解决。
-
复杂度：代码结构太复杂（如圈复杂度高），难以理解、测试和维护。
-
监控与报警：基于产品的需求逻辑，需要有些指标来证明业务是正常 work的，如果发生异常需要有监控、报警指标通知研发人员处理，review 业务需求对应的监控与报警指标也是 Code Review 的重点事项。
-
测试覆盖率：编写单元测试，特别是针对复杂代码的测试覆盖是否足够。
实际上维护单元测试的成本不比开发成本低，这点团队目前做的的不到位。针对以上每次代码 review 所涉及到的经典案例会统一输出到文档里，大家可以共同学习避免编写出同样的 Ugly Code。
发布计划评审
涉及到 10 人日以上的项目，必须有明确的发布计划，并组织项目成员统一参加项目发布计划 review，发布计划主要包含如下几点：
1） 明确是否有外部依赖接口，如有请同步协调好业务方；
2） 发布前配置确认包括配置文件、数据库配置、中间件配置等各种配置，尤其各种环境下的差异化配置项；
3） 二方库发布顺序，是否有依赖；
4） 应用发布顺序；
5） 数据库是否有数据变更和订正，以及表结构调整；
6） 回滚计划，必须要有回滚计划，发布出现问题要有紧急回滚策略；
7） 生产环境回归测试重点 Case；
补充
如何成为优秀的技术经理？你要做到这三点（ 三 ）技术规划与管理