框架选择的风险评估
我正计划开始一个新项目，并正在评估各种网络框架。我正在认真考虑其中一个，但我担心它的持久力。
选择 Web 框架时，在决定使用什么框架时我应该考虑什么？
以下是我在正在查看的框架中注意到的内容：
- 小社区。每天用户列表上只有几条消息
- 自 6 个多月前的上一个版本以来，“新闻”页面上没有新闻
- 过去 30 天内没有 svn 提交
- 良好的文档，但自上一个版本以来 wiki 没有更新
- 最近的版本仍然不在 Maven 存储库中
它不是官方认可的 Java EE 框架，但我看到有几个人在回答 Stack Overflow 上的各种问题时提到它是一个很好的解决方案。
我不会透露我正在考虑哪个框架，因为我不希望这陷入框架之战。我想知道在风险评估中我应该考虑项目的哪些其他方面。这应该适用于 Java EE Web 之外的其他领域，例如 ORM 等。
I'm planning on starting a new project, and am evaluating various web frameworks. There is one that I'm seriously considering, but I worry about its lasting power.
When choosing a web framework, what should I look for when deciding what to go with?
Here's what I have noticed with the framework I'm looking at:
- Small community. There are only a few messages on the users list each day
- No news on the "news" page since the previous release, over 6 months ago
- No svn commits in the last 30 days
- Good documentation, but wiki not updated since previous release
- Most recent release still not in a maven repository
It is not the officially sanctioned Java EE framework, but I've seen several people mention it as a good solution in answers to various questions on Stack Overflow.
I'm not going to say which framework I'm looking at, because I don't want this to get into a framework war. I want to know what other aspects of the project I should look at in my evaluation of risk. This should apply to other areas besides just Java EE web, like ORM, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想说，只要项目本身是可靠的并且你喜欢它，所谓的“死”项目并没有那么大的危险。问题是，如果库或框架已经可以完成您想要的一切，那么这没什么大不了的。如果您启动并运行了一个稳定的项目，那么您应该不再考虑框架（完成！），而只关注您的网络应用程序。您不需要每月用最新版本更新框架本身。
就我个人而言，我认为最重要的一点是您找到一个对您的项目来说直观的东西。什么最有意义？ MVC？ URL 中的每个元素都应该是一个单独的对象吗？交互性 (AJAX) 如何运作？仅仅因为它是“行业标准”或者因为它被许多知名网站使用而选择它是没有意义的。也许他们选择它的原因与您的需求完全不同。 阅读每个框架的教程并保持批判性。如果它不符合您的思维方式，或者您发现它做得更优雅，那么就继续吧。您在这里考虑的是设计，好的设计就等于保持灵活性和可扩展性。每种语言都有数百个新旧 Web 框架。您一定会找到六种符合您在项目中的想法的方法。
我认为强制性的要点：
总而言之：灵活性。如果我对所有四点都满意，我就差不多完成了。请注意，我在那里没有任何有关“死亡”的内容？如果核心设计很好，并且有易于安装的插件来完成您想做的每一个 Web-dev 3.0-beta 流行语，那么我不在乎最后一次 SVN 提交是否是在 2006 年。
I'll say that so-called "dead" projects are not that great a danger as long as the project itself is solid and you like it. The thing is that if the library or framework already does everything you can think you want, then it's not such a big deal. If you get a stable project up and running then you should be done thinking about the framework (done!) and focus only on your webapp. You shouldn't be required to update the framework itself with the latest release every month.
Personally, I think the most important point is that you find one that is intuitive to your project. What makes the most sense? MVC? Should each element in the URL be a separate object? How would interactivity (AJAX) work? It makes no sense to pick something just because it's an "industry standard" or because it's used by a lot of big-name sites. Maybe they chose it for needs entirely different from yours. Read the tutorials for each framework and be critical. If it doesn't gel with your way of thinking, or you have seen it done more elegantly, then move on. What you are considering here is the design and good design is tantamount for staying flexible and scalable. There's hundreds of web frameworks out there, old and new, in every language. You're bound to find half a dozen that works just the way you want to think in your project.
Points I consider mandatory:
All in all: flexibility. If I am satisfied with all four points, I'm pretty much done. Notice how I didn't have anything about "deadness" in there? If the core design is good and there's easily installable plug-ins for doing every web-dev 3.0-beta buzzword thing you want to do, then I don't care if the last SVN commit was in 2006.
在决定将框架用于生产环境项目之前，我在框架中寻找以下内容：
大量布局良好且书面的文档。糟糕的文档只是意味着我在浪费时间去寻找一切是如何运作的。如果我正在使用一些很酷的新微框架或其他东西，这是可以的，但当它是为客户使用时就不行了。
一个规模适中的社区，以便您可以提出问题等。一个有趣且活跃的 IRC 频道是一个很大的优势。
一个
产品不断迭代。 bug 是否每天/每周都会被关闭或打开？也许是一个好兆头。
我可以浏览框架的代码并了解发生了什么。好的框架代码意味着项目的长期生命周期有更好的成功机会。
我喜欢使用它。如果我玩了几个小时，而这是我一生中最糟糕的时刻，我肯定不会为客户使用它。
我可以继续说下去，但这些只是我脑海中的一些主要问题。
Here are the things I look for in a framework before I decide to use it for a production environment project:
Plenty of well laid out and written documentation. Bad documentation just means I'm wasting time trying to find how everything works. This is OK if I am playing around with some cool new micro framework or something else, but not when it's for a client.
A decently sized community so that you can ask questions, etc. A fun and active IRC channel is a big plus.
Constant iteration of the product. Are bugs being closed or opened on a daily/weekly basis? Probably a good sign.
I can go through the code of the framework and understand what's going on. Good framework code means that the projects longterm life has a better chance of success.
I enjoy working with it. If I play with it for a few hours and it's the worst time of my life, I sure as hell won't be using it for a client.
I can go on, but those are some primary ones off the top of my head.
除了查看框架之外，在评估风险时，您还需要考虑许多关于您自己（以及任何其他团队成员）的事情：
如果框架是一个新的、不成熟的、“流血的”， -edge” 框架，您是否愿意并且能够调试它并修复或解决您遇到的任何问题？
如果社区规模较小，您将必须自己进行大量调试和诊断。您是否有时间这样做，并且仍能满足可能的最后期限？
您是否亲自查看过该框架以确定它有多好，或者您愿意依赖其他人的评价吗？您为什么相信他们的判断？
为什么要使用这个而不是“官方认可的 Java EE 框架”？这是一个务实的原因，还是只是想尝试一些新的东西？
如果框架问题导致您错过最后期限或交付质量较差的产品，您将如何与老板或客户谈论它？
Besides looking at the framework, you also need to consider a lot of things about yourself (and any other team members) when evaluating the risks:
If the framework is a new, immature, "bleeding-edge" framework, are you going to be willing and able to debug it and fix or work around whatever problems you encounter?
If there is a small community, you'll have to do a lot of this debugging and diagnosis yourself. Will you have time to do that and still meet whatever deadlines you may have?
Have you looked at the framework yourself to determine how good it is, or are you willing to rely on what others say about it? Why do you trust their judgment?
Why do you want to use this rather than the "officially sanctioned Java EE framework"? Is it a pragmatic reason, or just a desire to try something new?
If problems with the framework cause you to miss deadlines or deliver a poor product, how will you talk about it with your boss or customer?
您引用的所有迹象对于您的框架选择来说可能都是坏消息。
我寻找的另一件事是亚马逊等网站上提供的书籍。如果有好的文档可用，则意味着作者相信它具有吸引力，并且您将能够找到了解它的用户。
我能想到的唯一可取之处就是相对成熟。如果框架或开源组件成熟，它就有可能按照编写的方式完成工作，不需要进一步扩展。
仍然应该有一个带有一些活动证据的错误跟踪器，因为没有软件没有错误（除了我的）。但在这种情况下，不一定会出现大量的请求。
All the signs you've cited could be bad news for your framework choice.
Another thing that I look for are books available at Amazon and such. If there's good documentation available, it means that authors believe it has traction and you'll be able to find users that know it.
The only saving grace I can think of is relative maturity. If the framework or open source component is mature, there's a chance that it does the job as written and doesn't require further extension.
There should still be a bug tracker with some evidence of activity, because no software is without bugs (except for mine). But it need not be a gusher of requests in that case.