规范化是死的，人是活的，希望他们定的规范化，千万别被诚然。
接下去从以内五个阶段展开逐个回收。
1 市场需求评审委员
作为控制技术相关人员的确都参与过市场需求评审委员会，不知道是不是碰到这样的情况？
商品副经理按照 PRD 文件格式读一遍，与会相关人员置之不理。商品副经理刚讲了一个市场需求点，与会相关人员就产生了惨烈的探讨，都在证明他们是对的。与会相关人员对市场需求的目标不明晰，对市场需求点展开收敛观念探讨，最终偏移方向。碰到以内难题，的确是在参与市场需求评审委员之前未做充分准备，那么难题来了，须要迪阿尔库甚么？
评审委员前
千万别听商品老师说，该市场需求是大老板介入的、十分重要、十分即时等等的，就问商品四个难题：
解决了甚么难题？提升了甚么指标？有甚么品牌价值？这四个难题弄清楚了，再展开评审委员。
商品副经理发出 蓝本 和 PRD 草稿后，合作开发者要有 1-2 天天数（具体天数根据项目大小TNUMBERA0512Ci），熟识文件格式，有任何疑点可以意见反馈给合作开发副经理，由合作开发副经理统一搜集再意见反馈给商品副经理，商品副经理逐个展开释疑。
熟识完文件格式后，合作开发者和合作开发副经理须要一起确认：
控制技术THF1（后端/后端架构、笔记开发工具、消息开发工具、资料库…）控制技术构架（模块与模块之间怎样相互配合，怎样布署）控制技术症结预见（明晰存有的控制技术症结，并确认软件系统）操控性困局预见（明晰可能存有操控性困局的地方性，并确认应付措施）上中下游系统可视化（明晰在业务流程中的别的位置，签订合同USB文件格式提供天数、USB初步设计天数）模块分割（任务分拆和重新分配）控制技术方案确认后，须要输出控制技术结构设计文件格式，包括：总体结构设计、概述结构设计、详细结构设计、USB结构设计 等。
评审委员中
合作开发者必须参与，有市场需求不明晰的地方性当即明确提出，同时合作开发者也须要思索商品市场需求是否合理，可适度明确提出他们的商品意见。
一般评审委员至少有两次（草稿和穿鞘）。
评审委员后
评审委员后，如有需更新控制技术文件格式的请及时展开更新。
合作开发副经理首先须要考虑团队现有的资源及项目的优先级，然后根据控制技术结构设计文件格式展开评估排期。
排期模板如下：
2 控制技术评审委员
评审委员前
合作开发者一定要重视控制技术结构设计！
合作开发者一定要重视控制技术结构设计！
合作开发者一定要重视控制技术结构设计！
重要事情说三遍！
控制技术评审委员主要评审委员甚么？
系统关系图、模块关系图、业务流程图的结构设计，画图工具根据他们爱好即可。USB结构设计，须要考虑USB的 兼容性、扩展性、参数命名遵守 参数命名规范化 等。资料库结构设计，须要遵守 资料库结构设计规范化，并记录 数据表变更文件格式。详细结构设计，须要考虑公共类、公共方法、方法定义 遵守 项目架构目录规范化。评审委员中
合作开发者和合作开发副经理必须参与，涉及到总体结构设计和概述结构设计时，须要邀请 构架师 参与，涉及到资料库调整时，须要邀请 DBA 参与。
一般评审委员至少有两次（草稿和穿鞘）。
评审委员后
评审委员后，如有需更新排期文件格式的请及时展开更新。
排期确认后
按部就班，按计划行事。
3 市场需求合作开发
编码
合作开发者编码过程中，须要遵守团队的 编码规范化，同时严格按照结构设计文件格式中的控制技术方案执行，除了保证代码逻辑的正确性外，还须要考虑代码封装性、可维护性、可扩展性，当编码阶段发现控制技术方案须要调整时，须要及时通知合作开发副经理，经过同意后才能实施，涉及到引入新架构和新控制技术，也须要提前通知合作开发副经理。
代码审查
合作开发者须要控制代码提交的频次和粒度，每次代码提交之后 24 小时内，须要主动联系代码审查人完成检查，合作开发副经理负责检查是否执行到位。
代码审查主要审查甚么？
规范化性检查（是否符合代码规范化、提交备注规范化等）健壮性检查（是否陷入死循环、资源未释放等）安全性检查（是否存有SQL注入、XSS、SSRF、CSRF、越权、文件上传等）操控性检查（是否存有未加缓存频繁连接DB，是否须要连接池）初步设计
合作开发者积极主动地推动初步设计工作，如果碰到阻碍及时通知控制技术副经理展开协调。
自测
初步设计完毕后，合作开发者须要同时完成自测，并将标准化的 自测报告 发给测试团队。
对于有操控性要求的项目，须要合作开发者展开操控性测试，并出具标准化的 操控性测试报告。
提测
自测完毕后，通过邮件方式展开提测申请，使用标准化的 申请提测邮件模板。
合作开发者根据公司运维提供的发布方式，展开布署到测试环境。
4 介入测试
测试用例评审委员
合作开发者必须参与，避免出现测试与合作开发对市场需求理解不一致的情况。
Bug 修复
合作开发者及时关注 Bug 列表，快速修复迭代发布，如果测试进度存有延期风险，须要及时通知合作开发副经理。
5 介入上线
合作开发者首先确认 Bug 全部关闭，同时商品相关人员在测试环境验收通过，然后须要主动推动相关团队理清上线依赖和上线顺序，同时确认回滚预案，最后根据公司运维提供的发布方式，展开布署到线上环境。
线上环境布署完成后，通过邮件方式展开通知商品相关人员和测试相关人员，使用标准化的 上线完毕邮件模板，同时积极推动测试相关人员和商品相关人员完成线上验证，线上出现难题后第一天数通知合作开发副经理。
6 线上难题复盘
市场需求在测试环境和正式环境，均未测试出 Bug，上线一段时候后出现 Bug，这种难题用甚么制度约束？
出现难题后合作开发者及时修复，修复完了就完事了。仅仅做到这些还远远不够。
建议使用如下模板展开复盘。
小结
大家可以数一数上面使用到了多少规范化，这时有朋友会说了，这规范化也太多了吧，这和工厂工人有甚么区别，我们程序员是有创造性的，我们喜欢前沿性、挑战性的工作，我们放荡不羁爱自由…
针对这个难题，首先我不否认合作开发者是有创造性的，但并不是所有的程序员都有创造性，在现实工作场景中大部分程序员不是做创造性工作的，也没必要做创造性工作，所以必须按照规范化业务流程执行。
团队管理和团队之间合作，必须要有规范化，并严格执行。
就到这吧，以内供参考。
以内内容希望帮助到大家，更多PHP大厂PDF面试文件格式，PHP进阶构架视频资料，PHP精彩好文可以关注公众号：PHP开源社区，或者访问：
精华PHP控制技术文合集——高并发场景篇
