技术方案评审学习笔记

问题

作为初级工程师，技术方案评审是都会经历的过程之一吧。

工作了快一年，前期并没有做具体的业务，技术评审工作做的不多，等到完全切入业务之后才发现自己的设计在评审时不断的被挑战，压力很大。

解决这个问题目前看来只有多了解开源项目以及其他已有的类似项目的架构设计，但是短期之内要提升这个是比较困难的，而且目前参加了几次评审之后发现自己的方式并不是很正确。

后期自己思考了一下，首先还是改善技术评审的准备过程和具体的表达吧。

在这里记下几个评审过程中被大家提出的自己觉得目前比较靠谱的方法，如果理解有错，日后再慢慢修正。

解决

自己认为目前亟需注意的时评审过程中背景的代入，提出技术选型的原则，以及一些选型做法。

背景

评审过程中没有项目的背景，对于评审的人员来说，完全不能了解具体的业务形态，最后直接会进入到技术细节之中，这个是没有意义的。

问题在于，自己直接上来说具体的实现细节，听众听着很枯燥乏味，并不能评估设计中选用方案是否合理，个人觉得这是大忌，原本技术评审就是为了确定是否当前方案在当前应用场景下是最好的方案，如果这点做不到，技术评审没有意义了。

讲述背景的时候，需要把整个项目的整个模块讲述清楚，对模块间的数据交换形式进行说明（比如文件
还是API还是Cache），刨除具体的实现细节，主要讲述数据流和模块的划分，以及采用这一方式的应用场景相关信息。

选型原则

2.1 需要有至少两个方案

一个方案的评审不能叫做技术方案评审，A方案与B方案的对比才能更完备，甚至是A/B/C多个方案。方案多是为了从不同维度考虑问题，比如方案A注重性能，方案B注重开发难度，集中团队的思维力量来帮助自己这个初学者定下最好的选择。

2.2 舍弃本我的想法

对于初级工程师来说，方案的选择必须要有具体应用场景下案例的支撑。

初级工程师主要的设计方向还是套用具体方案到现有项目为主，同时对业务的应用场景要做一定的修改，这是由初级工程师的经验不足引起的问题，需要接受自己认识上的不足，同时借鉴前人的经验。

踩坑虽然要踩，但是错误的设计的坑自己觉得并不是值得去踩的。

2.3 容量决定设计

虽然需要考虑业务的发展壮大之后的压力，但是具体业务的实现过程中应该避免过度设计的问题。过度设计在业务量不能够做到足够大的情况下完全就是浪费人力。

根据产品经理提出的业务容量来确定自己的设计程度，但是设计一定要保证在产品经理定出的容量范围内做到高度可靠，可以做到超出1个请求就降级，但是设计上绝对不能在容量范围内不稳定。

2.4 方案的实现要有有根据

子模块使用的方案需要有根据，不能为了使用技术而使用技术。

同时要对选用方案的优势要清楚，需要具体到数值上，不能用感性的认识代替具体数字，数字有说服力，而感觉没有。

2.5 注意CAP原理

CAP三者注意取舍。

选型做法

3.1 准备数据

用数据佐证方案的可行性，比如性能提升比率，最大容量等等需要提前准备好。

了解线上资源的性能，比如DB的QPS，以及缓存的容量，或者网络带宽等等，估算出缓存命中率、数据大小等具体信息，将整个流程中的数据流动量估计好，支撑自己设计的合理性。

3.2 描述问题和解决方案

在陈述方案时，可以考虑通过问题-解决方案这样的描述方式进行，让评审同学了解如此设计的意义，同时判定是否合理。

3.3 选型对比

对比的技术方案要有侧重性以及使用场景，两个或者多个技术方案应该是为了解决项目不同方向上的问题为存在的，不是一个对比优劣的过程。

3.4 集中大家的智慧

接受大家汹涌的挑战吧~

可能很快自己就会觉得上面的做法不对，但是目前自己打算先这么一试吧。

以上。