收录于话题
#程序员
33个内容
这里是Z哥的个人公众号
每周五11：45 按时送达
当然了，也会时不时加个餐～
我的第「194」篇原创敬上
工作年限短的程序员热衷于设计“高大上”的技术方案，而工作年限长的则对技术方案好像不太感冒，上手就撸代码。然后呢，年限短的程序员们想的技术方案又不好意思拿出来讲，而年限长的程序员们又不屑于设计技术方案，久而久之，大家好像就不太care技术方案了，都是拿到任务上手直接撸代码。之所以工作时间越长，越不care技术方案，在我看来的主要原因是，大家都觉得就算做了技术方案，也没啥新奇的，认为其中的思路和用到的技术框架大家都知道，没啥意思，不是浪费时间么。到如此地步，Z哥觉得可能是大家没有掌握设计技术方案的合理思路导致。所以今天我来分享一些我的看法。想要让方案让人有一种眼前一亮的感觉，或者说有一些意料之外的信息收获，关键在于你是否能挖掘到其他人没考虑到的盲区，并且将如何解决这个盲区问题的思路给讲出来（重点：思路比具体的方案更重要）。而想要挖掘盲区，只能往细节里去抠，因为在大方向上，大部分人的认知都是差不多的。有过一定开发年限的小伙伴们可能有过这样的经历：因为前期设计考虑不周，导致在开发过程中过遇到某个业务细节无法很好的处理，进一步导致要么选择更加复杂的“曲线救国”方案，要么推翻重头好好设计。假如，我们在前期的技术方案设计时就能预见到这点，这可不就是让人眼前一亮的方案么。根据我的经验，不要着急撸代码，基于以下这4个步骤去做技术方案的设计，想要挖掘到这些细节其实不难。需求分析
方案设计
方案落地规划
方案总结
乍一看这些步骤没啥特别的，下面我来展开说说，或许会让你有新的发现。需求分析分为两个方面，业务和技术。前者是必做的，而后者往往在中小型公司里被大家给忽略。这些忽略的地方往往是亮点所在。怎么考虑技术层面的需求分析？其实脑子里只要记住一句话：如何保障系统无时无刻稳定地运行？安全性问题：被劫持、被逆向、被抓包等；
兼容性问题：在不同设备上运行可能存在的兼容性风险；
性能问题：内存泄漏、卡顿、高CPU占用等可能导致整机流畅度和功耗等问题；
合规问题：技术上可能存在的法律风险，比如使用第三方开源库等。
第一步的需求分析，主要目的是确定目标（需要解决的问题，解决到什么程度）。第二步的方案设计其实就是拆解目标，并且转化为具体技术实现方案的过程。而这其中，如何拆解目标比如何选择技术实现方案更重要。因为前者考虑的是how和why，而后者只是在what中做选择题。这一步要做的事情最多，耗时也最多，首先是方案设计和技术选型。我建议你拆解目标的时候多画图，不管是业务流程图还是技术架构图，甚至是UML建模图，这些都有助于充分发挥你的抽象能力。而这个能力恰恰是目标拆解的关键所在。通过这些图，能够清晰地知道整个项目涉及到哪些技术领域（如，WEB、大数据处理），以及这些技术领域由哪些技术点组成，并且它们之间是如何配合运作的。在开始阶段只需要画出项目的主流程和核心流程就可以了，其它子流程可以在大框架确定下来之后再画。这里有一个要点需要注意：在选择每一个具体使用的技术框架的时候，如果没有特殊情况，我建议优先考虑复用公司里现有的资源，其次才是考虑引入开源资源或者商务合作的资源，最后才是自研。毕竟「低成本」和「快速」是每一个组织都在不断追求的目标。如果确实需要自研，那么要走预研流程，在有预研成果作为对项目的一定把握后才能进入工程化。如果是引入新技术，需要做技术方案选型，技术方案选型要基于项目的各维度关注点来选出最合适而非最厉害的方案。在方案选型中呈现的信息必须是经过实际验证得出的，毕竟商业资源的信息透明度不如开源资源，还是有不少存在夸大嫌疑的。这点就不展开说了，但是非常有必要单独列出来。的确有很多人通过过度设计来体现自己方案的亮点，但是现实价值可能是负的。在如今的大环境中，很多公司给的前期设计时间可能很少，甚至完全不给。但是只要我们能证明这么做的价值，我们也是有办法去争取更多的前期设计时间的。比如，下下策是你给自己工作估时的时候就把设计的时间考虑进去，不要只给一个理想情况下单纯coding的时间。毕竟，coding快不一定等于质量好，把时间拉长到项目上线后来看，理性的领导应该能看到你这么做的价值。但是如果你花时间设计了，质量和没设计的没差，这就另当别论了……（人与人之间的信任一旦崩坏就很难重新建立了）很多人可能会基于之前最熟悉什么技术或者近期对什么技术感兴趣来设计方案，这个是非常不可取的。虽然说最终可能也能满足需求，但是毕竟“强扭的瓜不甜”。有些人的方案设计得很高大上，但是落地的时候问题百出，这里的原因就在于没有很好的考虑具体该如何落地。毕竟不同的环境背景、人员水平，都对落地起到了很大的影响。里程碑的划分。划分的颗粒度尽量小一些，以小步快跑的方式及时交付，这样遇到问题能快速调整，降低风险。使得整个落地的过程平滑、可控。（像我这种偏理想化的人，会对里程碑的时间节点预留20%～50%的弹性空间，以免被自己的乐观给坑了～）
验收指标的确定。整个系统设计后是否符合预期，是需要有一些指标来度量的。否则没有人知道你设计的技术方案到底咋样。不小心在别人眼中沦为ppt架构师。
很多人在做完第二步之后就结束了，但这也是他们的技术方案让其他人觉得没啥感觉的原因所在。因为缺少了总结，你就缺少了提炼，缺少了对亮点的突出，其他人自然会觉得你设计的技术方案没啥新意了。这个场景中存在的主要问题有哪些？
这个技术方案能解决其中的哪些问题，以及解决到什么程度？
实施过程中存在哪些风险？有何预案？
整个项目的投入情况如何？
其中第2、3点往往是亮点所在的地方。第4点则可以体现你考虑的全面。如果来听你讲述技术方案的人里有非技术人员，那么你还得考虑如何将总结做的更加地通俗易懂。思路其实很朴实，但往往很多人的方案轻视了第3、4点。需求分析
方案设计
方案落地规划
方案总结
防止过度设计
争取尽可能多的设计时间
避免以技术先入为主来设计
希望每一位小伙伴都能设计出让你眼前一亮，有收获的技术方案。
推荐阅读：
原创不易，如果你觉得这篇文章还不错，就「点赞」或者「在看」一下吧，鼓励我的创作 ：）
也可以分享我的公众号名片给有需要的朋友们。
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「阅读原文」