现代应用程序很少从零开始构建。它们大多会整合市面上已存在的工具——组件、库、框架——主要有这么几个好的理由：
- 应用程序的规模、复杂性和复杂程度都在增长，但开发它们的时间反而越来越短。所以让开发人员专注于写更多业务领域代码，少搞基础设施，可以更好地利用他们的时间和智慧。
- 相比于一揽子开发，广泛地采用组件和框架能使bug更少。
- 有很多免费且高质量的软件可以从网上获取，这就意味着更低的开发成本和更高的可能性找到那些符合自己兴趣和专长的开发人员。
- 软件的生产和维护属于劳动密集型工作，所以选择购买可能要比自己开发划算得多。
无论如何，为你的应用程序选择一款趁手的工具还是相当棘手的事情，需要深思熟虑。事实上当做出选择时，需要牢记这么几件事：
- 不同的工具可以依赖不同的情景假设——比如周围基础设施、控制模型、数据模型、通信协议等。这些都可能导致程序和工具间的架构错配。错配又会进一步让你想要破解和变通，结果写了很多完全没必要却很复杂的代码。
- 不同的工具有不同的生命周期，当工具增加新的功能、改变设计、甚至是bug修复导致和其他工具不兼容，此时要升级它们其中之一，可能会变成一个极困难且耗时的任务。工具越多，问题也会变得越多！
- 一些工具需要相当多的配置。通常通过一个或多个XML文件，这些文件会很快失控。最终这个程序看上去就像全部由XML加上几行奇怪的其他语言的代码写成的。这个配置的复杂度将大幅提升程序的维护和扩展难度。
- 当代码严重依赖供应商产品到一定程度受的限于他们，可能会被供应商锁定：可维护性、性能、迭代能力、价格等。
- 如果你打算使用免费软件，你最好搞清楚它不是真的免费。你可能需要购买商业技术支持，这可并不便宜啊。
- 许可证条款很重要，即便是自由软件也一样。举个例子，一些公司是禁止使用任何GNU许可证发布的软件的，因为它的病毒性质——即，用它开发的软件，必须连源码一起发布。
我个人关于缓解以上问题的策略是，刚开始仅采用绝对必要的工具。通常最开始应该把重点放在为了移除那些需要从最底层的开发任务(和问题)，例如，采用中间件取代原始套接字的方式开发分布式程序。然后按需增加。我更倾向于通过接口和分层的方式把外部工具和业务领域对象分离开来，所以当我要解决某些痛点时，可以选择改变工具。这种方法有个好处，我通常可以得到一个更小的应用程序，且对外部工具的使用也比原先少。
