做技术决策时候的基本指导思想

作者: 夫礼者 | 来源:发表于2023-07-14 18:04 被阅读0次

不仅仅应用于技术决策。

在这个行业里摸爬滚打这么些年，虽然一直也没有在大厂混过，但通过多年的阅读和实践，也是逐步形成了自己对于职业的一些理解。

过往这些理解一直存放在大脑里，时不时就得回忆一下以防纰漏或是遗忘，所以这里将它们倒出来，给大脑减轻些压力。

对于咱们这种传统软件研发的，很难出现什么一个问题只有一个解决方案，99.99%的场景都是需要在多个方案中选择一个，而这里所列举的指导思想就是来辅助这个过程。

可能出现多个方案都满足某条指导思想的情况，但逐一对照筛查之下，最终剩下的那个很可能就是最符合当下场景的选择。

如《构建之法》中用专门的章节所讲解的"用户体验"，多个方案不好抉择时，尝试站在被服务方的角度想一下，选择就不言自明了：

多个方案之间进行抉择时，优先选择相对简单的那个。

这句话很短，也没有啥生僻字，但在实际应用中却非常容易产生不同的理解，而这个争议点往往就来自于对"简单"的解释上。

这里我们对“简单”的理解：

这个"简单"是综合性指标，当下编码量少只占非常有限的影响引子。方案的理解难度曲线、对于长远的影响、对于当下基础设施和人员的要求等等才是重头戏。

简单的事情复杂化，这个很简单；复杂的事情简单化，这个很复杂。
先简单，再复杂。不要"设计"一个臆想里的亿级流量方案来应对现实中十万都不到的访问量。（十万访问量有十万访问量的设计思路，百万访问量有百万访问量的设计思路，千万访问量有千万访问量的设计思路。）
其实最终汇总下来其实就四个字：实事求是。你要基于现实情况来选择方案，不要臆断场景来选择你想要的那个方案。

最后以几个实际的例子来结束本小节。

对于消息队列的选型，不要一上来就是kafka，如果你的团队之前都没有接触过，然后系统里用户量就那么几百号人，基于mysql / redis完全能够满足你的要求了。（这例子可不是我编的哦，是一位阿里P9在出版的书籍里给出的明确建议）
上一小节里举例的聚合层，应该使用Nginx还是专门微服务技术栈api-gateway + Nacos / Consul？
打包时候的依赖项redis执行权限，是选择将该redis赋予权限后上传到版本库，还是在打包脚本里执行赋权操作？前者看着更简单，毕竟后者改完还得测试，但实际呢？

多个方案时，十有八九其中的一两个是藏有私心的，典型的比如想趁机熟悉下XX新技术，方便未来的职业发展。

所以方案拍板的决策者需要秉承一些基础的认知：

或者是由成员A转给成员B、或者是由团队A转给团队B、或者是由人工转给机器、或者是由现在转给未来。

所以对于多个方案抉择时，思考尽可能地全面非常重要，不要被眼前这点收益迷住了眼睛，债是一定会还的，到时候还得交上巨额的利息。

对于不少土八路上来的领导层，总会自相情愿地认为只要我的方案/决策出来了，那问题就算是解决了。这造成他们在进行方案/决策选择时，总是恨不得一步到位，直接根治问题。

txt成为exe所要消耗的成本，和形成txt的成本不是一个数量级。
txt成为exe的过程中，需要培训、需要反馈、需要检查、需要时间。你如何保证执行标准是满足你的要求的？你如何保证2个月之后执行步骤没有变形，没有被"优化"，没有"被取消"？
PDCA里的那个C，你的计划里为它准备了多少资源？

从古至今，人类的需求总是那么些，比如做成某件事时更加省力、更加有效率；整个流程/知识点更直观、更容易理解等等。

基于此，很容易得出如下推导：

所以，在发觉某个问题时，先找找前辈门在其上的努力，站在巨人的肩膀上继续前进。

以下这些在过往的文章都单独分析过，暂时也解读不出啥新意，所以一骨碌全放这里吧。

没有100%烂，毫无益处的方案。我们最终只选择了其中一个方案，并不意味着其他方案就一无是处，并不代表对于该方案提出者的否定。只能说当下并不适合其他方案的出场。
分清楚手段和目的。解决问题才是目的，其他都只是手段。不过正如辩证法所言，两者是可以相互转换的 —— 比如为了推行某项制度的目的过程中，你需要争取某个团体的支持；在局部看，争取他们的支持是目的，而在全局看，争取他们的支持则是手段。