50 | 技术分歧，如何决策？

Nov 26, 2018

50 | 技术分歧，如何决策？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

50 | 技术分歧，如何决策？

2018-11-26 胡峰来自北京

《程序员进阶攻略》

课程介绍



讲述：刘飞

时长09:47大小4.48M



作为一名程序员或技术人，总会碰到这样的场景：在一些技术评审会上，和其他程序员就技术方案产生分歧与争论。如果你是一名架构师或技术 Leader，站在技术决策者的立场和角度，该如何去解决分歧，做出决策呢？
这背后，有什么通用的方法和原则吗？
绝对曾几何时，我以为技术是客观的，有绝对正确与否的标准判断。
在学校我刚开始学习编程技术时，捧着一本数据库教材，它在述说着经典的关系数据库表设计原则：第一、第二、第三范式。后来，我参加工作，那时的企业应用软件系统几乎都是以数据库为核心构建的，严格遵守范式定义的表结构。所以，当时觉得所有不符合范式设计的应用肯定都是错的，直到后来进入大规模的分布式领域，碰到了反范式设计。
也还是在学校做课程设计时，一起学习的同学总跟我讨论设计模式。一边写代码，一边研究这个代码到底符不符合某种模式，似乎没有套进某种模式中的代码就像没有拿到准生证的婴儿，带有某种天生的错误。直到后来，我碰到了反模式设计。
刚工作不久，同事和我讨论当用户删除自己的数据时，我们到底应不应该删掉它？我那时觉得理所应当写个 Delete 的 SQL 语句把它删掉。因为当时是这么想的：既然用户都不要他的数据了，我们还把它保留下来做什么呢？不是浪费资源嘛，而且服务器存储资源还算挺贵的。
但今天的互联网大数据时代，用户主动或非主动提交的任何数据，你都别想再将它真正地删除了。这个时代，受益于摩尔定律，存储设备容量不断增加，而价格不断降低，所有关于用户的数据总是可能有用的，都先存下来再说。
做技术这么些年下来，关于技术方案的判断，曾经以为的绝对标准，今天再看都是相对的。
相对的确是的，适合的技术决策总是在相对的条件下做出的。
曾经，读到一篇英文文章，其标题翻译过来就是《简化：把代码移到数据库函数中》。我一看到这个标题就觉得这是一个错误的技术决策思路，为什么呢？因为曾经我花了好长时间做了一个项目，就是把埋在数据库存储过程中的代码迁移到 Java 应用里；而且，现在不依赖数据库的代码逻辑不正大行其道吗？
作者是在正话反说，还是在哗众取宠？我很是好奇。所以，我就把这篇文章仔细读了一遍，读完以后我发现作者说得似乎有些道理，他的说法我大概概括为如下。
作者说，如今绝大部分的 Web 应用包括两部分：
一个核心数据库，负责存储数据；
以及围绕数据库的负责所有业务智能与逻辑的代码，体现为具体编程语言的类或函数。
现在几乎所有的 Web 系统都是如此设计的，所以这像是真理，业界最佳实践，事实工业标准，对吧？但作者描述了他自己的经历，是下面这样的。
他从 1997 年开始做了一个电子商务网站，用了 PostgreSQL 作为数据库，第一版网站用 Perl 写的。1998 年换成了 PHP，2004 年又用 Rails 重写了一遍。但到 2009 年又换回了 PHP，2012 年把客户端逻辑拆出去用 JavaScript 重写，实现了前后端分离。
这么些年下来，代码重构过很多次，但数据库一直是 PostgreSQL。可是大量和数据存取有关的逻辑也随着代码语言的变迁而反复重写了很多遍。因而，作者感叹如果把这些与数据存取有关的逻辑放在数据库里，那么相关的代码将不复存在，他也不需要反复重写了。
这里有个疑问，作者没事老换语言，到底是在折腾啥？他虽然没有在文中明说，但作为程序员的我还是能设身处地感受到其中的缘由。作者本身是学音乐出身，目标是建网站卖音乐唱片，自学编程只是手段。作为一个过来人，我相信他早期的代码写得肯定不咋地，又在各种流行 Web 技术趋势的引诱下，充满好奇心地尝试各种当时时髦的技术，不断重构改进自己的代码。
在这个过程中发现，有一些和业务关系不太大的数据存取逻辑，被反复重写了很多遍，所以才产生出了这样的思路：假如把这部分代码移到数据库中。其实对这个思路的挑战，也是显而易见的：
如何进行调试、回滚？
如何做单元测试？
如何进行水平扩展？
上述“挑战”在一般情况下都成立，但对于作者来说却不是很重要。因为作者思路成立的前提是：第一，他维护的是一个小网站，数据库没有成为瓶颈；第二，这个网站的开发维护人员只有作者一个人，而不是一个团队。
是的，围绕这个网站，作者创办了一家公司，雇佣了 85 名员工，并成为了公司的 CEO 也是唯一的程序员。因此，这就是一个在作者所处特定环境下的技术决策，虽看上去明显不太对，但在作者的相对限定条件下，这个决策实际省了他个人的负担（虽然扩展有明显的极限，网站也不会发展太大）。
仔细看作者这个案例，可以发现其技术决策方案也是符合 “康威定律” 的。“康威定律”是这么说的：
任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。
换句话说，就是系统设计的通信结构和设计系统的团队组织的沟通结构是一致的。案例中，作者的系统只有他一个人负责设计与实现，只需要和不同阶段的自己产生沟通，在他的系统和场景下，变化最小、稳定度最高的是数据存储和结构，所以他选择把尽可能多的代码逻辑绑定在系统中更稳定的部分，从而降低变化带来的代价。
而康威定律告诉我们系统架构的设计符合组织沟通结构时取得的收益最大。这是一个经过时间检验和验证过的规律与方法，体现的就是一个相对的选择标准，那在这背后，有没有隐藏着关于技术决策更通用的判断原则呢？
原则康威定律，是和组织的团队、分工、能力与定位有关的，其本质是最大化团队的核心能力，最小化沟通成本。
在足够大的组织中，沟通成本已经是一个足够大的成本，有时可能远超采用了某类不够优化的技术方案的成本。每一次人事组织架构变动的背后，都意味着需要相应的技术架构调整去适应和匹配这种变化，才能将沟通成本降下来。而技术方案决策的核心，围绕的正是关于方案的实施成本与效率。
曾经很多次的项目技术评审会上，后端的同学和前端的同学经常就一些技术方案产生争论。而争论的问题无所谓谁对谁错，因为同样的问题既可以后端解决，也可以前端解决，无论哪条路都可以走到目的地。那么还争论什么呢？无非是各自基于局部利益的出发点，让自己这方更省事罢了。
这些问题的解决方案处在技术分工的临界地带就容易产生这样的争论，而技术的临界区，有时就是一些无法用技术本身的优劣对错来做判断的区域。这时，最佳的选择只能是将前后端整体全盘考虑，以成本和效率为核心来度量，应该由哪方来负责这个临界区。
而成本与效率背后的考量又包括如下因素：
团队：这是人的因素，关于团队的水平，掌握的技术能力和积累的经验；
环境：能利用的环境支持，公司内部的平台服务或外部的开源软件与社区；
技术：技术本身的因素，该项技术当前的成熟度，潜在的发展趋势；
约束：其他非技术约束，比如管理权限的干涉、限定死的产品发布日期等。
不同的人，同样的技术方案，成本效率不同；不同的环境，同样的技术方案，成本效率也不同；不同的技术，同样的环境和人，成本效率也不同；不同的约束，同样的团队和环境，会得到不同的技术方案，成本效率自然不同。
在技术的理想世界中，技术决策的纯粹部分，其决策原则都和成本效率有关；而其他非纯粹的部分，其实都是 “政治” 决策，没有所谓通用的原则，只和博弈与利益有关。
最后，简单总结下：技术没有绝对的标准，适合的技术决策，总是在受限的约束条件下，围绕成本与效率做出的选择权衡。对于一些纯粹的技术理想主义者，追求技术的完美与合理性，初心本不错，但也许现实需要更多的行动柔性。
关于技术方案分歧，你是否遇到过类似的争论呢？又是采用的是怎样的决策方式？欢迎留言分享和大家一起讨论。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 4

提建议

49 | 技术干货那么多，如何选？

51 | 技术债务，有意或无意的选择？

 写留言

精选留言(12)

公号-技术夜未眠
2018-11-27
技术决策无关乎是非对错，但是存在合适与否。技术决策的确是成本，效率，质量，政治综合博弈的综合结果。所以在实践中会对上述进行优先级排序。在决策考虑的因素方面，优先级是由以下几个方面所决定：不同的组织环境(传统与扁平化)，所开发的不同的软件系统(业务系统，用户产品，中间件等)，约束性条件(团队的人力与技术储备，开发与运维环境条件，进度等)。形式上一般会是一主两备(第三选择)，先民主后集中，在讨论各种中大家充分表达意见，但是最后还是需要技术团队的老大拍板，避免议而不决；原则上采用遵循简单，合适，不断演进的思路；最终决定了大家就统一行动。技术决策很重要，会花费一定的时间去做讨论与取舍。这个时间是值得的，越是越早发现问题，其后期的成本消耗就越少，磨刀不费砍材功，应该就是这个道理。
展开
作者回复: 理解了博弈，就没那么多纠结了😄
8
hua168
2018-11-26
大神能分享一下你的自学方法吗？为了提高视频学习的速度，我是不是不截图直接一次去看过，然后就按着记忆去练习写代码？不截图的话又感觉忘的很快，学习完一章之后，我简单做个笔记会好一点？还是直接看书来得更快一点？我的学习方法效率太低，花大量时间得到的是入门级的技能。
作者回复: 只能照着视频写代码是不够的，或者你搭配个入门级书籍，要消化教程样例代码，举一反三
2
hua168
2018-11-26
大神，我想请教一下一个关于自学的问题，我自学习惯一般是这样的: 1.去下载过购买视频，利用业余时间或周末学习，学习时边看视频边截图，周一到周五上班有时间就敲代码 2.再找下有什么相关的书，简单看下这样造成了: 1.看视频花时间太长，1小时视频得花3小时才搞完，截图，打字 2. 视频比较简单，讲得不深入，所以找书看下，外看下spring官网哪些更新。 3.发现了，学完了没经验，而已水平也是视频教入门的程度疑问: 我总觉得好像自己不是这样的，怎么提高学习效率，深入这，找经验？
展开
作者回复: 视频学习的局限就在这，估计大部分视频教程都是入门用的。还需要自己把技术用在实践中去磨练，编程是实践的技术和艺术。想一个真实的场景和真的有个问题，再用技术实践去解决
2
Ripper
2019-06-24
中国特色社会主义道路😃
1
汪玉斌
2019-04-04
就算有好的，新的解决方案，实施的过程不能贯彻好，最后也很坑。解决方案的评估需要和团队的情况结合！不只是技术上的事，还有成本和团队效率。
作者回复: 嗯，需要多维全面的考察并平衡
2
亚林
2018-12-23
旁边的波波老师也提到了康威定律
作者回复: 想成为架构师的程序员都需要知道这个定律😄
1
third
2018-12-15
决策的本质是总成本最小，总收益最大。但是个体和群体的收益和成本可能正相反。康威定律。所有群体在设计一套方案时，所提交的系统方案在结构上都与该组织的沟通结构保持一致。成本与效率背后的考量团队：人环境：能利用的环境支持技术：技术的成熟度和发展趋势约束：
展开
1
钱
2018-11-28
我们会先讨论，如果能定下来就定，如果还存在分歧就找相关方及架构师，让架构来定，到这基本能定，还有些方案都行的情况就有自己来定了，leader只关心结果。能搞定就行，不管你怎么弄的！
作者回复: 😂Leader也太high了
1
麦德漂
2021-06-08
就像两人合作砌一堵墙，中间的交界处总要有人多做一些
Sch0ng
2021-03-01
分歧的产生来自双方或者多方利益不一致。参与竞争合作的个体，都是趋利避害的。 PK的时候重点要找利于己方的公理，可以很发散的找，大到这是OKR目标，小到这是最佳实践。反正没有统一答案，也没有法律条文规定，言之成理即可。
海盗船长
2020-10-21
各自列出自己所选技术的优劣点，进行充分友好的沟通，万维刚在一篇文章中讲过：两个理性的人，最终会达成一致。
艾尔欧唯伊
2018-12-02
理论上模式，范式。。。实际上都要权衡。。

