Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

谁是万恶之源?

  「过早优化是万恶之源」这句话好像是从上个世纪流传下来的。和其它名人名言一样,它只是一句话而已,具体要怎么理解就很难说了。看到网络上也有很多在试图「诠释」这句话文章,但基本都是千篇一律的无聊见解。就像是语文老师在教我们如何研读鲁迅老人家的文章一样。
  「优化」到底是什么鬼?这是个很泛的词。好多 C++ 编译器都提供一些称为「优化选项」的东西。优化是可选的,可以针对代码量优化,也可以针对程序性能优化,甚至可以针对逻辑、代码可读性之类的点做优化。所以说,把「优化」这件事情一巴掌拍死是不对的。
  「过早」同样是个很模糊的概念,什么时候才算过早?一个程序如果只会发布一次,以后再也不会有更新,那么发布前做一次全面的性能和体积的优化是最合适的。但是程序只发布一次是什么鬼?反正 21 世纪才接触电脑的我是不会懂了。如果程序在持续更新,任何一次面向机器的优化都可能给将来带来困扰。
  其实我根本不知道这句话想表达什么。我只想聊聊谁才是万恶之源!
  我觉得「万恶之源」不是「优化」,而是不恰当地抽取通用。我似乎说了一句更加空洞的话?那就结合一些具体例子来看吧?
  假如有个项目,其中有个页面有个复杂的表单,由于只有一个,所以大家应该什么也不考虑都能又快又好地做出来。但是这个版本上线后没过几天业务上又加了个需求,也是一个表单页,逻辑和 UI 和之前的几乎一样,只是一些文案和提交的地址不同。此时应该怎么做?于是做法有两种,一种是直接把代码复制一遍,改文案和提交地址;另一种是将表单抽取成一个可配置的模块,让两个页面通用这个模块。
  我们假设有 A、B 两个开发者都遇到了这个问题,采用了不同的做法来解决。接着,业务需求又有新的变更,要修改这两个表单的业务逻辑,而且是一次较大的逻辑改动。于是 A 开发者就手动去修改两个页面,浪费了很多时间。而 B 开发者只改了底层模块就同时把两个页面都搞定了。
  但是在另一个平行宇宙中,可能业务放提的需求不是同时修改两个页面的逻辑,而且修改其中一个的逻辑。A 开发者改完一个之后完全不影响另一个页面的逻辑就搞定了。而 B 开发者又得把原来的模块复制一份出来换成新的逻辑,然后再让两个页面使用不同的模块。
  其实根本就没有正确的做法,无论是复制代码还是抽取通用都可能在业务需求变更时遇到问题。也许正以为自己高明地选择了某个方案而窃喜的时候,另一个平行宇宙的自己正在为先前决策的错误买单的。
  如果真有一个固定的法则可以解决这个问题,那世界上就不会出现那么多烂程序了。开发人员不仅是是要写好代码,还应该了解自己的业务将来的大走向是什么样的。只有足够了解业务才能尽可能地做出正确的决策。这便是我所理解的「领域驱动开发」的皮毛。
  前面说的那句空洞的话如果更加准确的说起来应该是「非领域驱动的开发才是万恶之源」!
网名:
54.226.58.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^