写还是不写:框架
今天，我和一些朋友开始讨论框架。
我们中的一些人坚信，在99.9%的情况下，编写一个新的框架是个坏主意。我们认为，可能存在的数百万框架中的一些应该适合我们的问题，如果不是，一些黑客、API或配置应该就足够了。如果不是，我们认为对某些框架的贡献，建议特性或类似的东西应该是最好的解决方案。0.1%是当任何框架都不适合我们的情况时。
但是，我们中的一些人说，最好是有一个“内部公司框架”(例如)，因为解决问题的速度更快，可以100%地与应用程序相匹配，因为“学习”因素(当你提高构建框架的技能时)等等。
我认为，像没有明天这样的编码框架是不正确的。我见过许多小团队建立自己的框架，只是为了传播这样的话：“我们建立了自己的框架，我们统治，兄弟”。一般来说，这个框架是垃圾的，没有任何文档，只适用于他们自己的应用程序。
意见是意见，开发人员是神职人员，无意发动任何形式的火焰战争，我问：
你对此有什么看法？在构建框架时，您会考虑哪些参数？你觉得这一切怎么样？
回答 5
Software Engineering用户
发布于 2012-11-08 21:34:06
我和GrandmasterB的光谱相反。对我来说，这是一个买与造的问题。
在我看来，我的时间和努力可以用成本来表示。那么，问题是，何时有足够的投资回报来建立一个框架？(如果我为客户工作，我会从客户的角度思考这些问题。)
以下是我问自己的问题：
- 框架是否已经存在？
- 如果我构建了这个框架，这是我想要知道的吗？换句话说，这个框架对我来说是一个区别吗？
很多时候，我发现第二个问题的答案是否定的。我现在在一家医疗公司工作。他们不想成为最优秀的调度引擎的开发者。我应该外包这个框架的制定和维护。
然而，如果我们说的是一个定价引擎，那是公司的生计，所以我一定要把精力集中在制造一台超级引擎上。
Software Engineering用户
发布于 2012-11-08 19:35:48
我的一般规则是，如果它是一个产品，或产品的一个重要部分，让它自己在可能的地方。如果它不是核心功能，或者是支持业务(只是内部使用的东西)，那么就疯狂地使用框架。
我制作的许多应用程序都是长期投资--可能是10+年--它们是卖给客户的产品(因此是我的责任)。因此，能够“快速”使用第三方框架对我来说并不像每年开发十几个应用程序的人那样重要。因此，我一般不反对跳进麻烦事，自己做自己的东西。在产品的生命周期内，额外的几个星期得到一个定制的框架/组件并不重要。但这可能意味着，自从它专门为应用程序设计以来，它的头痛和砖墙就会少得多。
Software Engineering用户
发布于 2012-11-08 20:08:13
在我看来，框架是一个库的集合。一旦您有了一堆API，并确保它们具有一致的API，并且在一起玩得很好，那么您就可以将它们捆绑起来，并将其称为框架。但是，无论您是否使用F单词，您都应该确保公司的所有库都有一致的API。
框架往往会被写成“意外”，当一个人看到他们所有的东西，说‘嗯，这一堆东西可能对其他人有用’。除非你是一家提供源代码的公司，或者你被明确要求编写一个框架。在编程中，为了做事情而做事情总是一个坏主意。
无论你做什么，确保你没有重新发明车轮，特别是作为一个正方形。
https://softwareengineering.stackexchange.com/questions/175163
复制相似问题
腾讯云开发者
