文章50技术分歧如何决策.pdfVIP

2018/11/26 极客时间 | 程序员进阶攻略 也还是在学校做课程设计时，一起学习的同学总跟我讨论设计模式。一边写代码，一边研究这个 代码到底符不符合某种模式，似乎没有套进某种模式中的代码就像没有拿到准生证的婴儿，带有 某种天生的错误。直到后来，我碰到了反模式设计。 刚工作不久，同事和我讨论当用户删除自己的数据时，我们到底应不应该删掉它？我那时觉得理 所应当写个 Delete 的 SQL 语句把它删掉。因为当时是这么想的：既然用户都不要他的数据 了，我们还把它保留下来做什么呢？不是浪费资源嘛，而且服务器存储资源还算挺贵的。 但今天的互联网大数据时代，用户主动或非主动提交的任何数据，你都别想再将它真正地删除 了。这个时代，受益于摩尔定律，存储设备容量不断增加，而价格不断降低，所有关于用户的数 据总是可能有用的，都先存下来再说。 做技术这么些年下来，关于技术方案的判断，曾经以为的绝对标准，今天再看都是相对的。 相对 的确是的，适合的技术决策总是在相对的条件下做出的。 曾经，读到一篇英文文章，其标题翻译过来就是《简化：把代码移到数据库函数中》。我一看到 这个标题就觉得这是一个错误的技术决策思路，为什么呢？因为曾经我花了好长时间做了一个项 目，就是把埋在数据库存储过程中的代码迁移到 Java 应用里；而且，现在不依赖数据库的代码 逻辑不正大行其道吗？ 作者是在正话反说，还是在哗众取宠？我很是好奇。所以，我就把这篇文章仔细读了一遍，读完 一个核心数据库，负责存储数据； 以及围绕数据库的负责所有业务智能与逻辑的代码，体现为具体编程语言的类或函数。 现在几乎所有的 Web 系统都是如此设计的，所以这像是真理，业界最佳实践，事实工业标准， 对吧？但作者描述了他自己的经历，是下面这样的。 他从 1997 年开始做了一个电子商务网站，用了 PostgreSQL 作为数据库，第一版网站用 Perl 写的。1998 年换成了 PHP，2004 年又用 Rails 重写了一遍。但到 2009 年又换回了 PHP， 2012 年把客户端逻辑拆出去用 JavaScript 重写，实现了前后端分离。 这么些年下来，代码重构过很多次，但数据库一直是 PostgreSQL。可是大量和数据存取有关的 逻辑也随着代码语言的变迁而反复重写了很多遍。因而，作者感叹如果把这些与数据存取有关的 逻辑放在数据库里，那么相关的代码将不复存在，他也不需要反复重写了。 /column/article/69592 2/5 2018/11/26 极客时间 | 程序员进阶攻略 这里有个疑问，作者没事老换语言，到底是在折腾啥？他虽然没有在文中明说，但作为程序员的 我还是能设身处地感受到其中的缘由。作者本身是学音乐出身，目标是建网站卖音乐唱片，自学 编程只是手段。作为一个过来人，我相信他早期的代码写得肯定不咋地，又在各种流行 Web 技 术趋势的引诱下，充满好奇心地尝试各种当时时髦的技术，不断重构改进自己的代码。 在这个过程中发现，有一些和业务关系不太大的数据存取逻辑，被反复重写了很多遍，所以才产 生出了这样的思路：假如把这部分代码移到数据库中。其实对这个思路的挑战，也是显而易见 的： 如何进行调试、回滚？ 如何做单元测试？ 如何进行水平扩展？ 上述“挑战”在一般情况下都成立，但对于作者来说却不是很重要。因为作者思路成立的前提 是：第一，他维护的是一个小网站，数据库没有成为瓶颈；第二，这个网站的开发维护人员只有 作者一个人，而不是一个团队。 是的，围绕这个网站，作者创办了一家公司，雇佣了 85 名员工，并成为了公司的 CEO 也是唯 一的程序员。因此，这就是一个在作者所处特定环境下的技术决策，虽看上去明显不太对，但在 作者的相对限定条件下，这个决策实际省了他个人的负担（虽然扩展有明显的极限，网站也不会 发展太大）。 仔细看作者这个案例，可以发现其技术决策方案也是符合 “康威定律” 的。“康威定律”是这 么说的： 任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保 持一致。 换句