技术决策的相对性

我想，作为一名程序员或技术人，总会碰到这样的场景 —— 在一些技术评审会上，和其他技术人产生关于技术决策的争论。大家争论的出发点是什么？而解决争论的原则又是什么？

绝对

曾几何时，我以为技术是客观的、有绝对正确与否的标准判断。

曾经，我刚开始学习编程技术时，捧着一本经典的数据库教材，它在述说着经典的关系数据库表设计原则：第一、第二、第三范式。后来，我参加工作，那时的企业应用软件系统几乎都围绕数据库核心构建，严格遵守范式定义的表结构。所以，当时觉得所有不符合范式设计的应用肯定都是错的，直到后来进入大规模的分布式领域，碰到了反范式设计。

在更早的时候，还在学校，一起学习的同学总跟我讨论设计模式。一边写代码，一边研究这个代码到底符不符合某种模式，似乎没有套进某种模式中的代码就像没有拿到准生证的婴儿，似乎带有某种天生的错误。直到后来，我碰到了反模式设计。

刚工作不久，同事和我讨论当用户删除自己的数据时，我们到底应不应该删掉它。我觉得理所应当写个 Delete 的 SQL 语句把它删掉。既然用户都不要他的数据了，我们还把它保留下来做什么呢，不是浪费资源嘛（那时服务器存储资源还算挺贵的）。但今天的互联网，用户主动或非主动提交的任何数据，你都别想再将它真正的删除了。在这个大数据时代，所有关于用户的数据总是可能有用的，先存下来再说。

关于技术决策的判断标准，曾经以为的绝对，今天再看都是相对的。

相对

是的，适合的技术决策总是在相对的条件下做出的。

最近，读到一篇英文文章，标题翻译过来是《简化：把代码移到数据库函数中》。我一看到这个题目就觉得这是一个错误的技术决策思路，为什么呢？因为曾经我花了好长时间做了一个项目，就是把埋在数据库存储过程中的代码迁移到 Java 应用里。而且，现在不依赖数据库的代码逻辑不正大行其道么？

我很好奇作者是在正话反说，还是在哗众取宠？所以，我就把这篇文章仔细读了一遍，读完以后我发现作者说得似乎好有道理，他的说法我大概简述下。

作者说，如今绝大部分的 Web 应用包括两部分：

• 一个核心数据库，负责存储数据
• 以及围绕数据库的负责所有业务智能与逻辑的代码，体现为具体编程语言的类或函数

现在几乎所有的 Web 系统都是如此设计的，所以这像是真理，业界最佳实践，事实工业标准，对吧？但作者描述了他自己的经历，是这样的。

他从 1997 年开始做了一个电子商务网站，用了 PostgreSQL 作为数据库，第一版网站用 Perl 写的。1998 年换成了 PHP，2004 年又用 Rails 重写了一遍。但到 2009 又换回了 PHP，2012 年把客户端逻辑拆出去用 JavaScript 重写了，实现了前后端分离。

这么些年下来，代码重构过很多次，但数据库一直是 PostgreSQL。而大量和数据存取有关的逻辑也随着代码语言的变迁而反复重写了很多遍。因而，作者感叹如果把这些与数据存取有关的逻辑放在数据库里，那么相关的代码将不复存在，他也不需要反复重写。

这里有个疑问，作者没事老在换语言折腾啥？作者虽然没有在文中明说，但作为程序员的我还是能设身处地的感受到其中的缘由。作者本身是学音乐出身，目标是建网站卖音乐唱片，自学编程只是手段。作为一个过来人，我相信他早期的代码写得肯定不咋地，又在各种流行 Web 技术趋势的引诱下，充满好奇心地尝试各种当时时髦的技术，不断重构改进自己的代码。在这个过程中发现，有一些和业务关系不太大的数据存取逻辑，被反复重写了很多遍，所以才产生出了这样的思路。

假如把这部分代码移到数据库中，对这个思路的挑战，也是显而易见的：

• 如何进行调试、回滚？
• 如何做单元测试？
• 如何进行水平扩展？

上述理由在正常情况下都成立，但对于作者来说却不是很重要。因为作者思路成立的前提是，第一，他维护的是一个小网站，数据库没有成为瓶颈。第二，这个网站的开发只有作者一个人，而不是一个团队。

是的，围绕这个网站作者创办了一家公司，雇佣了 85 名员工，成为了公司的 CEO 也是唯一的程序员。因此，这就是一个相对限定条件下的技术决策，看上去明显得不对，但在作者的限定条件下，它省了他个人的事，但扩展有明显的极限，网站也不会发展太大。

这就是一个相对技术决策的案例，明显非主流，但它能适应作者面临的现实，这背后会有通用的选择判断标准吗？

原则

既然技术没有客观与绝对的标准，那么技术争论的出发点以及解决争论的原则该是什么？

在近期的一次项目技术评审会上，后端的同学和前端的同学又就一些技术决策产生了争论。而争论的问题无所谓对错与否，因为同样的问题既可以后端解决，也可以前端解决。那么争论什么呢？无非是各自基于局部利益的出发点，让自己这方更省事。

某些问题的解决方案处在技术的临界地带就容易产生这样的争论。而技术的临界区，有时就是一些无法用技术本身的合理性来做判断的区域。那么解决的办法和基于的原则是什么？我得到的答案是，在这个具体案例中就是把前后端整体考虑，以成本和效率为核心来度量，应该由哪方来负责这个临界区。而考虑成本与效率的因素又包括：

• 团队：人的因素，不同团队的水平、掌握的技术、积累的经验不同
• 环境：能直接利用的环境支持、公司内部的平台甚至外部的开源软件
• 约束：管理权力的干涉、预定死的产品发布日期等等

不同的人，同样的技术方案，成本效率不同；不同环境，同样的技术方案，成本效率也不同；不同的约束，同样的技术方案，还不仅仅是成本效率的问题，可行性也是一个问题。

…

适合的技术决策，总是在受限的约束条件下，围绕成本与效率做出的权衡。而对于一些纯粹的技术理想主义者，追求技术的完美与合理性，初心本不错，但也许现实需要更多的行动柔性。

---

写点文字，画点画儿，记录成长瞬间。
微信公众号「瞬息之间」，既然遇见，不如一起成长。