软件行业存在很多类比，常常类比开发系统就是建造大楼，那么软件开发者就相当于建筑工程师啊，但是工程师群体常常嘲笑软件开发工程师，你们的专业训练哪有我们严格？时不时服务就有问题了（尽管不得不承认牛逼网站能够做到好几个9的可用率）。对建筑工程师来说这都是重大事故啊，基本是零容忍的，你们软件设计也能称之为设计？我们一栋楼那是承担人们生命安全的东西，在地震区得考虑防震，在飓风区至少得经过很多轮测试，你们写几段代码，就能叫工程师了？
诚然，建筑行业和软件行业不能完全拿来对比，我外公以前是从事建筑行业的，修建一个公园的亭子，都需要仔细画若干张图纸，等一切资源到齐才能撸起袖子干。软件开发，启动成本多低，一段脚手架生成代码敲几个字母，所谓“原型”就出来了，前前后后可能还没有一个小时。其次，建筑行业的设计者和实施者，那是分的相当开，我们哪见过建筑设计师拿着铲子和水泥，一片片垒砖的。并且，软件行业提出了很多独特的开发模式: “极限编程”，这在建筑工程师那里简直不可想象，毕竟建造这件事情不是轻易能够迭代的。软件开发者很可能就说：不就几个功能嘛，时间这么紧，两下搞定，要毛设计~~
然而，最近深度介入一个生命期已经接近两年的代码项目，深刻意识到 拿捏“设计” 的意义。很多所谓码农，可能跳槽频率较高，刚生出来一个项目，还没来得及看看这个项目怎么在复杂的商业环境下演变就离职了，没有机会尝试演进化的设计。
不得不承认，项目初期每个人都很难拿捏需求，工程师可能会想我这种设计模式绝对能满足你们未来100个需求点，但是，商人头脑里的东西那是捉摸不定啊（此时cue下特朗普），他能给你搞1000个需求，所以前期设计那肯定是得摸着石头过河。有些时候，我们常常容易“过度”设计：“很可能未来还会有这种需求，那我就搞个“类”，把所有共享变量放在一起，机智如我！”，然而，未来压根就没有这种需求，大部分时间我们YY的都是错的。因此，“奥卡姆”剃刀中讲的，大道至简，用最简单并且能够让人一目了然知道你在干什么。
难道这样说，我们就放弃“设计”，来一个需求就干一个需求。经典的软件设计课程会告诉我们，能在前期解决的一个问题留在项目后期，那成本翻了可能有100倍，我们说演进化设计，是要这个系统生长，但是要健康生长，如果一个代码库生长出各种错综复杂的逻辑，而且引入如此多“黑魔法”，那维护成本相当高。这就相当于生长成一个“怪物”，想要驯服，太难了。
Martin Fowler 《重构》这本书其实给出了一条明路，保证测试足够的情况下，我们可以驯服这个怪物，修剪掉重复代码，保持“简单”的设计哲学，这种定期的代码审查，逻辑重构，保证软件在演化过程中按照规矩成长。经典的设计模式就可以在这时候发挥作用，毕竟是前人在种种尝试中摸索出来的pattern，前期如果为了设计模式而设计模式，很可能就过度设计了。但是在重构基础上，再引入设计模式，那就是控制了代码复杂度。
演进式设计也不完全是“摸着石头过河”，毕竟很多人都走过这样的路，如果不是一个特别有技术壁垒的项目，其实都可以通过网上找到相应的经验。要做一个实时聊天系统，那么多大公司分享出来的原型，先跑一两个，快速学习其中可能遇到的挑战，再进行相应的规划部署，这就是一种有效设计。
所以对于“搞软件的配叫工程师？”，我希望是。最后开一个脑洞：目睹一个项目两年的演进可能对于任何一个人来说都比较难，毕竟我们的生命很有限，所以很多情况下我们只会考虑近期利益。倘若我们要一段程序自己玩，时不时更改一些变量，用大量测试作为外部环境，我想有可能自动就进化和演变出一段“好”程序。不过，很可能我们人类估计都看不懂这段代码了。
