本文主要是介绍[闲侃DRY] 自制框架 vs. 开源框架，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
接着上一篇的思路聊。既然我们可以把开发者社群看作一个整体，copy-paste别人的blog文章就是在违背DRY的精神，其实所谓"重造轮子"道理也是一样，既然别人都已经做了相同的事情，并且把它开源了，并且你看了它的代码以后，觉得做得不错，为什么还要自己费心去实现同样的功能呢？自己来实现能给你带来什么好处呢？
我可以列举一些我认为可能会让我们选择自己来做的理由:
- 我比其他人更了解我们自己的需求。
- 自己实现起来更容易，代码量更小，也更好用。
- 我是做技术的，能够DIY，就DIY，这样更能体现我的价值。
这些理由有它的道理，但是我们有必要仔细掂量掂量:
- 我比其他人更了解我们自己的需求。这是软件开发中很常见的一个误区，客户的需求难以把握，随着时间的推移，我们自己的技术层面的需求实际上也在不断变化，开源的框架往往经历了更多的考虑和验证，并且有一群热心的维护者帮你做bug-fix和升级，甚至我们自己就可以成为这群热心人中的一员。
- 自己实现起来更容易，代码量更小，也更好用。一开始确实是这样的，开源的框架为了满足不同的需要，往往需要比我们自己写代码要更加复杂和冗余，但是自制框架意味着我们自己定义的接口规范，这个接口规范能不能够在整个项目周期保持稳定暂且不谈，就算接口实现的再简单，项目中其他人也需要时间去理解和消化，然后记住一个定义好的调用方式，今后新加入的工程师也需要学习这个接口规范。开源框架则做得更好，一方面在这个项目中积累和学习到的知识，可以直接用在其他采用同一框架的项目中，另一方面新加入的人如果有过该开源框架的开发经验，上手时间可以缩短。
- 我是做技术的，能够DIY，就DIY，这样更能体现我的价值。我必须承认，我本人就亲身经历过这样的情况。在即将结束的这个项目中，我甚至自己DIY了一个简易的.NET报表引擎，为的是甩开Crystal Reports。一开始能够DIY报表引擎的想法让我兴奋得睡不着觉，最终前后花了3天很满意的完成了设计和开发，并交付报表开发人员重画报表。可是真正用了一段时间之后，基本的需求满足了，基本的可扩展性也具备，但是缺少可视化设计器、更灵活的公式、更丰富的报表元素，基本上就定型了，没有人有时间和精力再去维护它。
在很多开发团队，大家经常碰在一起讨论具体的技术和设计，这很有必要，有时也不可避免。但是也许Joel Spolsky说的对，软件设计很难，但是比设计软件更难的，是同整个team一起设计软件。做技术的，对于自己了解、掌握、做过、尝试过的东西，对于自己熟悉和信任的东西，多多少少有些偏袒，而对于新的、自己不了解、不熟悉的东西，则难免心存疑虑。这就难怪很多设计讨论会最终很难达成一致。这个时候，要么由技术上的最高权威直接拍板，定下来是什么就是什么，要么就分歧双方或多方各自陈述，然后由项目外部的实体进行独立仲裁。
我看好开源框架，尤其是那些经过考验广泛被采用的框架，因为相比自制框架，它们有着更大的优势。
这篇关于[闲侃DRY] 自制框架 vs. 开源框架的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
