技术评审，你拿什么来吐槽？

原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。

如今，给你一个机会，来吐槽别人的方案或者代码，该从何开始？

是否是以为有千言万语想要迸发，弄到最后只想起个代码命名问题？若是你是java，你会想到《粑粑开发规范》，可那仍是代码层面的。包括把sonar给上了，也是发现一些浅显的问题。

如今的开发人员参差不齐，为了将风险尽可能消灭在萌芽中，须要一些手段。其中一种手段就是技术评审，用群众雪亮的眼睛，来回头是岸。

一、技术评审分类

技术评审会挤占产品开发的时间，但会提升产品的质量、软件的性能、拥有良好的扩展性、易于重构，长远来看是泽被后人的事情。

若是对单体的研发能力并不能彻底掌握，那必定要坚持技术的评审，可让你免去不少无聊低级的故障和缺陷。

但鉴于目前大部分开会抓不住重点的现状，偏题是常见的。要正确面对技术评审，不要开出火药味，也不要走过场，这是两个极端。

对于技术研发，我大致将研发技术评审分为三类。鉴于篇幅问题，点到为止。

根据通常软件的开发过程。大致可分为：方案评审、设计评审、代码评审。不少时候，咱们仅仅关注代码评审，对一些结构问题发现的晚，形成了代码质量很高但总体质量不好的后果。

二、方案评审

2.一、方案背景

一、阐明方案要解决的问题、危害。

也就是简单的立项缘由。假如问题不成立，则设计无心义。

二、尽可能一个方案解决一个主要问题。

最后把同一周期的问题串联，看是否总体最优。所谓先分后总，不可只照顾本身那一块。

2.二、可落地

一、方案要可以落地，过渡，不能偏离实际，构建一个乌托邦。

要根据公司可协调的资源进行设计。好比，一个不想花大价钱买服务器的公司，并不适合把日志打印的太详细，保存的时间过长。

二、代价要尽可能小，可以分步骤进行，可阶段性验收。

对于周期稍长的功能，要有里程碑，以便对外同步和进度追踪时，可以有章可循。

2.三、是否引入新组件

一、可否利用先有资源完成需求。

理想很丰满，现实很骨感。好的方案并不必定是业界最优方案。引入一个新组件的成本是很是大的，哪怕它很稳定。

二、新组件的调研和维护。

若是确实须要引入一些组件，要有基本的调研，以及对之后组件维护的考量。

2.四、良好的扩展性

一、方案要有前瞻性，避免短时间内重构。

这个通常看到2-3年就ok了，但要避免短视，不到半年推翻重来的那种。

二、要有良好的扩展性。

扩展性必然会增长模块的个数和对外接口的数量，要和上面的“可落地”相配合，不能顾此失彼。通常说来，提供可以扩展的接口能力，即表示有不错的扩展性。

2.五、涉及的组和人

一、研发资源的投入。

对参与人员的能力有较好的把控，不定差距太大的目标，这就要求对任务的拆解要详细，可以掌握对难点问题的处理。

二、多部门沟通协调。

若是功能涉及到公司的多个部门，对其余部门的能力和工期考量也要计算在内，主要人员全程参与是必要的。

三、设计评审要点

3.一、提供设计图

一、须要留下可以被看懂的文档设计图。

设计通常会随着问题的深刻而产生细微的变化，但总体的思路是不会变的。设计图能够减小一次次沟通的成本，避免重复性的讨论。

二、可以体现设计者的简单意图。

设计图要简洁，突出主要功能。次要功能能够辅以附加图解释，不可喧宾夺主，忽略了主要业务的评审。

三、遵循已有规范和架构。

任何公司都会有本身的规范和架构，水土不服的设计，注定了将来的坎坷。要在充分了解公司现状的前提下，进行设计的修正。

四、是否考虑遗留接口处置。

许多开发人员喜欢开发新功能，对待遗留代码如同臭狗屎。设计阶段就须要考虑这些因素，对于遗留接口的适配、扩展、下线问题，表明了将来bug的数量。

五、是否考虑历史数据处置。

设计方案若是须要修正历史数据，这个过程就危险的多。你的任意一个字段的删减、变动，均可能引发很是严重的后果。大致的设计原则是只加不减进行过渡 。

六、是否考虑新旧方案并行、回退。

不少时候，你的新设计须要和旧的功能并行，这种时候，要考虑旧方案的下线影响和周期；若是你的设计是为了替换旧功能，就要考虑在发生严重问题时的回退，这一般可以保命。

3.二、下降复杂性

一、对复杂性进行评估。

通常状况下，复杂性体如今如下方面：1）调用链过长 2）程序策略复杂没法落地 3）跨库、跨存储 4）使用了缓存 6）使用了异步。

以上每个点，大多数状况下都是能够进行优化的，也是疑难bug的发生地。邀请几个对业务熟悉的人，以及对分布式应用问题敏感的开发人员参与，能够及早的规避问题。好比，提到缓存，就能想到数据同步、穿透、雪崩、容量等问题，就叫作技术敏感。

针对设计内用到的每一个组件，均可以进行“技术敏感”型评审。

二、裁剪没必要要组件。

组件如无特殊必要，不要引入，优先借助公司现有设施完成。不能管生无论养。

3.三、验证方式

一、单元测试设计。

你的设计，可否方便的进行单元测试。若是不能进行单元测试，该如何验证一些逻辑的正确性。

二、接口测试设计。

你的设计，收否将全部的功能揉在了一块，牵一发而动全身，没法进行接口测试。存在此问题的设计有不少，好比使用未知的json（字符串）进行数据传输、一次性传输多个冗余、干扰性数据等。

3.四、高可用（服务）

一、服务分级。

你的设计，以及功能，所处的地位。是否须要更多资源，来保证更高的SLA级别。是否须要弹性部署或者预留资源？是否有不可预料的请求尖峰？

二、上下游影响提醒。

你正在设计的功能，对上下游的影响。对上游，是否能够作到承诺的服务级别（通常SLA会比上游服务的略高）。对下游，就要考虑是突发流量的发源地：通常来源于定时任务、或者多线程。

3.五、高可靠（数据）

一、数据一致性。

发生极端状况（好比某些重要组件死亡）后，数据是否会发生不一致。通常的服务降级，都会引发数据的一致性问题。这部分能够没有自动化的修复方案，但要对修复的难易程度进行初步评审，若是难度过大，要经过记录冗余信息的方式进行解决。

二、模拟演练。

在上线以前，对可能的节点进行模拟演练。可物理演练，也可纸上谈兵。

3.六、资源

一、肯定各部门资源。

设计阶段肯定详尽的部门协调资源，肯定整个流程中的短板部门，进行资源倾斜。

二、排期。

按照里程碑对功能进行拆解、排期，此部门要可以达到估计大致工做量的程度。

3.七、风险

一、是否有技术难点？

技术开发一样存在28原则。几个技术难点，可能会占据你80%的时间。这些问题一般会阻塞到最后才会被解决，你须要找到一个Mock的方式，默认已经打通了这些通道。

二、是否有业务风险？

相关功能是否违反了相关法律法规？是否收集了不应收集的东西？是否某些敏感信息没有作脱敏处理？若是这些都不是你来确认，那就默默的闭嘴。

三、安全。

某些安全问题要提早预知到，好比恶意注册、限流、封禁等。若是资源有限，这些一般是优先级比较低的。在成长为大象以前，可以盯上你的都是蚂蚁。

四、代码评审要点

4.一、自动化代码审查结果

一、哪一个级别必须处理。

使用sonar初步扫描，可以发现不少问题。这避免了引经据典（特指开发规范）的状况。自动化的东西总比记在脑子里的东西更加可信。

4.二、double评审

一、审主要处理逻辑。

二、审异常处置。

三、审性能。

四、审提示信息。

五、审注释。

以上，是一个优秀的开发者都须要掌握的内容。处理逻辑的正确性，是功能经过验收的基本，可是出问题的一般是一些比较隐蔽的地方。

一些异常会暴露敏感信息，或者走向了不可预料的分支。一些错误提示会显得不友好，给使用者形成不少困扰。一些注释信息会偏移实际，尤为是在开发人员不稳定的状况下。

此步骤的评审，360度无死角。

End

许多公司，是没有过剩的能力进行技术评审的，开发人员也如公交车通常上下，这也是时间越久积毒越深的缘故。

不要为了评审而评审，评审是为了解决问题的，不是为了形式。假如你每次都把会开出流水帐通常的感受，全部人都连连点头（瞌睡），那不是流程有问题，是你在官僚的路上中毒已深。

做者简介： 小姐姐味道 (xjjdog)，一个不容许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不同的味道。个人我的微信xjjdog0，欢迎添加好友，​进一步交流。​