任何一个组织都无法全部拥有这些新技术。因此作为大连无人值守停车场计费软件开发从业者，需要不断地保持对技术社区的关注。闭门造车只能加速架构的腐化——特别是自己的这些发明在开源社区早已有成熟方案的时候。在那些貌似光鲜的产品背后，实际上有着无数的失败的案例和成功的经验在支撑。

      我们曾经有一个大连无人值守停车场计费软件开发项目。在意识到需求可能转向类似于key-value的文档数据库之后，团队大胆地尝试采用SQLServer 2008 的XML 能力，在SQL Server 内部实现了类似于No-SQL 的数据库。这是一个新的发明，创造者初期很兴奋，觉得终于有机会做不同的事情了。然而随着项目的进行，越来越多的需求出现了：Migration的支持、监控、管理工具的支持、文档、性能等。随着项目的进展，最终发现这些能力与时下流行的 MongoDB 是如此的相似——MongoDB已经解决了大多数的问题。这个时候，代码库已经有相当的规模了——而这部分代码，让许多团队成员费解；在一年之后，大约只有两个人能够了解其实现过程。如果在早期采用MongoDB，团队本来有机会摒弃大部分相关的工作。

      致远服软认为：http://www.soft8.com.cn/高傲的开发者往往对新技术不够耐心，或者说对新技术的能力或局限缺乏足够耐心去了解。每一个大连无人值守停车场计费软件开发项目都有其针对的问题域，对于问题域之外，新技术往往没有成熟到能够应对的地步。开发者需要不断地阅读、思考、参与，来验证自己的问题域是否与其匹配。浅尝辄止不是好的态度，也阻碍了新技术在团队内的推广。

      新技术的选型往往发生在项目/产品特定的时期，如开始阶段，某个特定的痛点时期。日常阶段，开发者仍然需要保持对代码库的关注。下一条，重构到物理隔离的组件则是对不断增大的代码库的另一种解决方案。

      显而易见的趋势是，对于同一个产品而言，需求总是不断增多的。去年有 100 个功能，今年可能就有200个；去年有10万行代码，今年也许就有20万行；去年2G内存的机器能够正常开发，今年似乎得加倍才行；去年有15个开发人员，今年可能就到30个了；去年构建一次最多15–20分钟，今年就得1个小时了，还得整个分布式的。

      有人会注意到股票大盘分析软件开发代码的设计问题，孜孜不倦地进行着重构；有人会注意到构建变慢的问题，不懈地改进着构建时间。然而很少有人注意到代码库的变大才是问题的根源。很多常规的策略往往是针对组织的，例如将代码库按照功能模块划分（例如ABC功能之类）或者按层次划分（例如持久层、表现层），但这些拆分之后的项目依然存在于开发人员的工作空间中。无论项目如何组织，开发者都需要打开所有的项目才能完成编译和运行过程。我曾经见到一个团队需要在Visual Studio 中打开120 个项目；我自己也经历过需要在Eclipse 中打开72 个项目才能完成编译的情况。