心法利器[25] | 如何做技术设计
【心法利器】
本栏目主要和大家一起讨论近期自己学习的心得和体会，与大家一起成长。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。
往期回顾
老大给了任务后，你是否曾经设计的时候很懵不知道从何下手，是否试过一顿操作效果完全不听话地差或者是性能压力而不能上线？技术设计是每一位技术人都需要考虑的关键问题，一个好的技术设计能让短期开发更加高效的同时，长期维护成本也大大降低，做技术的时间不短了，来谈谈自己对技术设计思路的看法。
技术设计的主要步骤
要做一项技术设计，是需要一套严谨完整的技术方法论的，一套严谨的方法论能让自己思考不容易遗漏，技术方案可靠性也会更强。大概的流程如下：
理解需求。即确认本期的目标和主要任务内容，后续的技术设计必须围绕这几个重要任务展开。 理解现状。方案设计讲究因地制宜，那我们必须足够理解所谓的“地”是什么样的。 方案调研。艺术的设计需要灵感，技术的设计需要储备，为了找到最合适的方案，我们需要积累足够多的知识和技术，才能够设计出更好的方案。 开始设计。结合上面搜集的所有信息，开始进行技术设计。 上下游沟通确认，准备评审。一线的技术人员多半不是单兵作战，而是一个分工明确的战斗部队，因此做好所负责模块的技术方案后，需要和自己相关的上下游以及需求方确认，保证技术的可行性和可靠性。
下面我来详细聊一下每个步骤的细节，也当做自己的checklist，后续的技术设计可以按照这个流程去做。
理解需求
技术设计之前往往会有需求方提出自己的需求，但是我们作为技术实现的一方，需要和需求方问题沟通很多事情，包括但不限于：
需求是否合理，是否存在技术不可行的地方，如他要天上的星星。 需求是否明确，尤其是算法技术，分类、相似之类的东西边界要明确，否则很多东西做出来还要扯皮。 需求是否存在交叉和矛盾，在比较大的项目里，尤其是算法项目，很可能存在大量冲突、交叉的问题，这些问题的划分是什么样的，需要核对。
需求是整个项目的指挥棒，指导整个项目的落地实施，因此这是一个不能马虎的过程。
理解现状
现状这个东西同样很模糊，我列举一下我们需要了解的现状有哪些：
是否已有baseline。如果有那应该是一个算法优化迭代项目，如果没有则要认为是一个初创项目，这个初创项目是需要一些时间来维护一些基础性工作的。 如果是一个优化项目或者是一个迭代项目，要找到内部的核心问题，甚至要确定有些问题到底是不是真的问题（很多时候我们假想的问题其实并不存在或者不是主要矛盾），这个需要对数据和需求有足够多的理解，例如要优化效果那准召本身是否是达标的，数据有无什么特色，有没有很明确、高频的问题需要解决，是否迫切在本期处理等。。 工程框架和上下游。但凡是一个完整的项目，我们都只是其中的一部分，为了和上下游更好的沟通，我们需要和他们对好接口，即输入输出要保持一致。 外部的一些确认项，一些工作是否有依赖这个依赖是否能保证，给到研发的时间长短等，这些都是影响技术设计的关键因素。
现状同样是影响技术涉及的一个关键点，一些被忽略的点甚至最终会导致技术方案再执行过程中期的不可行从而导致项目失败，所以同样不能马虎。
方案调研
这个其实是一个积累的活，平时积累的越多，项目进行过程中的技术调研要花的时间就越少。
所谓方案调研，就是看看其他人有没有做过，大都用的什么方法，方法有什么优缺点，有这些思路引导那我们就能根据我们的现状来设计自己的方法，说白了就是找找有没有能抄的作业，有的话最好，没有的话尽可能找个接近的改改也行。
思路上，整体应该分为两块，科研界和工业界。
先说科研，科研可以说是技术的前沿和边界，应用端本不应该冒险使用太过前沿而有风险的东西，但是科研产出的论文的一些思路和观点，仍然是值得思考的，论文的思考一方面体现在对一些常见问题的发现，另一方面在于对这些问题尝试解决的思路，前者能让我们知道我们面临的问题可能面临的一些难点，后者能给出一些面临难点的解决方案建议。
工业界才是我们抄作业的核心来源，工业界的信息查询能让我们了解业界的普遍做法是什么，哪些方式比较有稳定性，哪些问题比较常见，又有什么方式可以解决处理，所以这块是我们调研的重点。那么来源有哪些，这个其实和找论文类似，我们可以从百度里面找，另外比较常见的搜索引擎里我们应该也能尝试去找，例如知乎、简书、CSDN、微信公众号等等，当然还有github上也有包含代码的讲解，另外还有一些企业的技术网站等，这些都是可以去找的。
开始设计
经过前面那么多的铺垫，明确了需求，了解了现状，也知道相似问题下的一些比较可靠的解决方案，我们终于可以开始进行技术设计了，这里有几个关注点还是需要记得：
时刻记住需求和现状，所有的技术设计不能脱离上面的两个关键点。 追求高端如果不是需求之一，那就不要追求高端，相反我们应该想怎么用最简单的方式解决最复杂的问题。 解决高频问题，看什么问题经常出现，哪些就需要被解决，不要纠结一两个偶现的问题。 关注性能，单个query的运行速度（主要看平均和峰值）。 评估效果的时候，要分2种情况分析，一个是高频的，高频的效果越完美越好，哪怕是规则白名单都可以，高频问题简单处理，一方面长尾效应明显的场景其实要处理的数据量不会太大，另一方面高频的用规则处理能大大提升性能。另一个是平均的，平均一般是设置一个达标线。 时刻对清楚接口，上下游的输入输出要确认清楚，本期的技术设计是否需要增加新的输入，这个输入是否能给，是否要增加新的输出，这个输出下游是否知道以及怎么用，另外还有数据量、数据类型等也要确认清楚，尤其是protobuffer类型的。 排期的时候多留余地，尤其是算法比较重、还是比较初期的算法项目，这些优化需要覆盖的东西太多了，很难保证一次就能有比较好的效果。
技术评审
一般来说，技术方案制订完了就要开始技术评审，其实说得轻松点就是让需求方、你的上下游、你的老大一起来看你的技术方案是否合理，只有大家都认为合理了你的方案才能实施，看着其实很有压力但其实对个人来说是很有好处的，我自己其实也挺积极做这个事，原因如下：
对于项目本身，更多人评审视察，其实也能保证你自己在项目中的执行更加可靠。 依赖项全都聊清楚后，上下游沟通会更加通畅。 在评审过程中大家的建议对个人的提升是很大的。
所以积极拉上相关人员开会吧~
小结
技术方案做了不少了，自己总结一下有助于形成完整的方法论，分享也希望把自己的思考让大家提提意见，觉得有用也可以一起学习学习。