> For the complete documentation index, see [llms.txt](https://braydie.gitbook.io/how-to-be-a-programmer/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://braydie.gitbook.io/how-to-be-a-programmer/zh-traditional/2-intermediate/judgment/04-how-to-make-a-buy-vs-build-decision.md).

# 如何做购买还是构建的决定

一个尝试用软件完成一些任务的企业级公司或工程必须不断做所谓的 *buy vs. build* 的决定。这个问题的不幸在两个方面：似乎忽视了不必*被购买*的开源软件和自由软件。更重要的是，这可能应该被称作*获取与集成 vs. 购买与集成*决定，因为集成的代价需要被考虑。这需要商业上，管理上，工程理解上的大量结合。

* 你的需要与它的设计意图有多接近？
* 对于你购买的软件，你想要怎样的可移植性？
* 评估集成的代价是什么？
* 集成的代价是什么？
* 购买会增加还是减少长期维护代价？
* 构建会把你放在一个你不想要的商业位置吗？

在你构建一些大到足够成为另一整个商品的基础的东西前请三思。这样的想法通常是乐观积极的将会对你的团队做出许多贡献的人提出来的。如果他们的想法很引人注目，你可能会想要改变你的商业计划，但不要在没有周全考虑前就投资一个比你自己的商业还大的解决方案。

在考虑了这些问题后，你可能应当准备两个工程计划草案，一个给购买，一个给构建。这会强迫你考虑集成代价。你也应当考虑两种措施的长期维护代价。为了评估集成代价，你必须在购买软件前对它做一个彻底的评估。如果你不能评估好它，你可以假设购买它会有一个不可预料的风险，你应该以此决定是否购买特定的产品。如果考虑后有几个购买决定，需要花一些精力去评估每个决定。

Next [如何专业地成长](/how-to-be-a-programmer/zh-traditional/2-intermediate/judgment/05-how-to-grow-professionally.md)