最近，我在读《架构之美》，书中的内容让我感触良多。其中一篇是关于“混乱大都市”和“设计之城”的对比，双城记的故事让我很有共鸣。

混乱大都市

“混乱大都市”是一座复杂的、没有良好架构的软件。它是由一系列独立的原型拼凑起来的，这些原型本应该被抛弃，但是没有。可以说“大都市”是偶然形成的，毫无规划的。随着时间的推移，其中散发出了腐臭的味道，对其的维护变成了一种不可能完成的任务。受到各种压力，大家总是选择阻力最小的方式，而不是最合理的方式来添加新的需求。这种恶性循环使得情况每况愈下，最后放弃这座“城市”似乎只是一个时间问题而已。没人愿意再在其中添加一行代码了，在其中工作成为一种痛苦，而不是快乐。

设计之城

“设计之城”与“大都市”截然相反，开始有明确的需求，良好的基础架构。参与者相处融洽，即使有紧急的修改也会被视作技术债务，最后会被修改处理。添加的内容会被放置到正确的模块，即使这样会增加一些工作量。此外，“设计之城”并不是架构不会发生变化，其架构也发生了许多变化，但是变化都是有规划的，而不是随意为之的。在其中工作让人感到轻松愉快，添加新的功能也变得简单容易。团队的氛围也是积极向上的，大家对“设计之城”也更加有信心。

双城记

我相信书中的描述，并且也亲身经历过类似的情况。下面是我的双城记。

我在一个同“混乱大都市”的项目中工作，经常需要面对不断的需求，功能的变动，没有规划，临时拼凑，团队中成员水平参差不齐。我加入的时候代码已经在走向死亡，但是大家还是很努力，最后奇迹般的完成了需求。从表面来我们建造了一座摩天大楼，但其实大楼摇摇欲坠。

之后我见到了一座“设计之城”，很可惜我来的太晚了，建造他的人们早已不在了。我阅读了其中的代码，游历了整座城市。这是一种什么感觉呢？说起来就好像是找到了失落的亚特兰蒂斯一样，其中的建筑风格让我钦佩，我为大师们的创造的奇迹赞叹，学习着，临摹着。这是我的幸运也是不幸，幸运的是我可以看见完整的，建好城市；不幸的是我没能看见他的建造过程。

随后，我离开了神圣的“设计之城”。带着从中学习到的知识、技能，我开始构筑自己的“设计之城”了。起初，城市渐渐成型，设计完善、井井有条。看似完美，但是功能、需求接踵而至。最开始，我的“设计之城”完美的应对了这一切。但是随后我发现，再好的设计也无法应对人们的欲望，需求的变化渐渐的超出了最初的设计，城市渐渐难以应对变化。我竭尽全力维护我的城市，避免其崩塌。最后，我的城市因为无法应对新需求的变化而被渐渐遗弃。这是我的第一座城市，当它迎来终结是我悲痛不已。

之后，我又陆续设计建造了几座城市。为了适应需求的变化，我尝试了各种方法。其中一些有作用，一些毫无用处。随着城市的规模越来越大，有更多的人加入进来，大家一起开始建造城市。所有的这些城市，包括我最近设计的。他们最终都透露出来一种要变的混乱的感觉和倾向，并没有书中提到的长久保持秩序的情况。虽然，根据熵增定律，无序的增加是自然规律。但是我觉得这并不是“设计之城”变质的关键之所在。

我觉得我之所以没有建成书中所说的“设计之城”是因为在下面几个方面没有做好：

  • 过早进行优化 - 出于对代码的洁癖，总是有意无意的过早优化。
  • 试图猜测需求 - 需求还没有确定就企图猜测，企图一开始就制作出完美的设计。
  • 架构没有变化 - 只关注了软件的演进，没有注意到架构本身也在变化。
  • 建造着都是人 - 没错，人。是人就有变化，人的能力是变化的。

综上所述，在读完“混乱大都市”和“设计之城”后的感悟是，好的架构不是一成不变的。架构本身就是一种妥协，架构在要适应需求的同时也要适应团队。伴随着团队的成长，架构一起成长。生命才是美丽的，而我们往往看见的只是生命的一瞬间，却误以为静止的那一瞬才是最美的。呵呵！:)