Web开发包的稳定性?

发布于 2024-07-12 06:23:18 字数 95 浏览 2 评论 0原文

我对网络框架的经验是它们相对“不稳定”。 并不是说它们崩溃了,而是有相当多的变化迫使人们重新编程代码。 我想知道您使用过哪些 Web 开发包以及维护该代码需要花费多少工作?

My experiences with web-frameworks was that they are relative "unstable". Not that they crash but that there are quite a few changes which then force one to reprogram ones code. I wonder what web development packages you've used and how much work it was/is to maintain that code?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

撩心不撩汉 2024-07-19 06:23:18

“改变是要求的一部分。”

我认为我们设计的网络包变化不大。 如果它改变了,那么它就是一个糟糕的设计。 如果我们使用外部 API,则极少数会被弃用,否则大多数都是相同的。

作为 JAVA/J2EE 程序员使用的一些软件包:
- MVC
- 支柱
- 一些 AJAX 框架

这些都是非常基本的框架。 其他大多数都是自行开发的,一旦网络包的设计完成,我们就不会更改设计。

"Changes are a part of the requirement."

I dont think that the web packages that we design changes a lot. If it changes, then it is a bad design. If we use external API's, a very few get deprecated, otherwise most of them are the same.

Some packages used as a JAVA/J2EE programmer:
- MVC
- Struts
- few AJAX frameworks

These are very basic one used. Most the other ones are self developed and once the design of the web package is done, we don't change the design.

再可℃爱ぅ一点好了 2024-07-19 06:23:18

任何正在积极开发的库都会不稳定。 以 .NET 为例,每个月都会有一种新的更好的方法来处理旧的事情。 另一方面,开源库更倾向于抛弃旧的不推荐使用的方法,因为这使代码变得更好,这就是让他们高兴的原因。

但无论如何,我不建议使用任何旧的和不受支持的东西,尽管环境完全稳定,但你将依靠自己。

最好的方法似乎就是冻结您开始使用的库版本并切换到新版本,这样做有巨大的好处。 至少每个人都是这样做的。

Any library which is under active development would be unstable. Look at .NET for example, every month there's a new better way to do old stuff. On the other hand open source libraries tend more to throw old deprecated methods away because it makes code better and that's what makes them happy.

But I wouldn't recommend to use anything old and unsupported anyway, you'll be on your own although the environment would be completely stable.

The best way possible seems to be just freeze the version of library you start using and switch to new one only there's huge benefit in doing so. At least that's how everyone is doing that.

热鲨 2024-07-19 06:23:18

.NET 和 jQuery 等框架在很大程度上是向后兼容的,允许您慢慢地使用新功能。

然而,Mootools...API 从 1.11 到 1.2 再到 1.3 破坏了很多东西。 在这种情况下,升级并不简单。

通常,我会尝试等待某些东西脱离测试版,然后再将其纳入生产代码中。 认可也可以起到很大的作用 - 由于 Microsoft 称 jQuery 为客户端框架的赢家,因此很容易鼓励其他人也选择它。

Frameworks like .NET and jQuery have been largely backward compatible and allows you to use new features slowly.

Mootools however... the API broke so many things from 1.11 to 1.2 to 1.3. Upgrading was not straightforward in that case.

As a rule, I try to wait for something to be out of beta before embracing it in production code. An endorsement can go a long way too - since Microsoft has called jQuery the winner of client-side frameworks its been easy to encourage others to pick it up too.

过度放纵 2024-07-19 06:23:18

我的大部分经验都是关于 Ruby on Rails 的,所以我将分享我在过去几年中所看到的内容。

Rails 的更新速度相当快,但除非您需要功能或罕见的安全补丁,否则您实际上并不需要更新。 举个例子,我现在在我们公司运行一个 Rails 应用程序,大约是 2.5 年前编写的,今年只需要对其进行一些工作即可将其升级到新版本以与 apache mod_rails 兼容,它我相信最初是针对 Rails 1.2 编写的。 当然,那是一个内网应用程序,没有任何安全要求。 总而言之,这是非常无痛的。 如果我继续使用 mongrel + mod_proxy,它就不需要只更新一次安全补丁了。

Rails 非常安全,漏洞也相当少。 如果我没记错的话,Ruby 漏洞比 Rails 漏洞多一些,但总而言之,它相当可靠,升级你的 Ruby 不应该破坏 Rails,特别是如果你使用向后移植安全修复程序的发行版。

Most of my experience is with Ruby on Rails, so I'll share what I've seen with it over the last few years.

Rails updates at a pretty good clip, but you don't really need to update unless you need features or the rare security patch. As an example, I have a rails app running in our company right now that was coded about 2.5 years ago that only needed to have some work done to it once this year to upgrade it to a new version to be compatible with apache mod_rails, it was originally written against Rails 1.2 I believe. Of course, that was an intranet app which didn't have any security requirements. All in all, it's been pretty pain free. If I had kept using mongrel + mod_proxy it wouldn't have only needed to be updated once for a security patch.

Rails is pretty secure, vulnerabilities are fairly far between. There have been a few more Ruby vulnerabilities than Rails vulnerabilities if memory serves me right, but all in all it's pretty solid, and upgrading your ruby shouldn't break rails, especially if you use a distro that backports security fixes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文