多个项目之间的重复功能

发布于 2024-07-16 07:49:38 字数 266 浏览 12 评论 0原文

我目前正在开发两个社交网站,它们有很多共同点,但又截然不同。 我发现自己为两者(包括 UI)编写了很多相同的代码,并且想知道是否有最佳实践可以限制重复代码。

主要问题之一是这些项目彼此非常独立,并且很快可能会出现更多的差异而不是相似之处。 此外,一旦初始工作完成,它们可能会被移交给其他程序员,因此共享代码库可能最终会成为一个大问题。

可能不得不处理类似情况的人有什么建议吗?

PS:我是这两个项目的唯一开发人员,而且看起来这种情况还会持续一段时间。

I'm currently working on two social networking sites that have a lot in common, yet are distinctively different. I find myself writing a lot of the same code for both (including UI), and was wondering if there is a best practice that will limit duplicating code.

One of the main problems is that these projects are very independent of eachother and will likely have more differences than similaries soon. Also, once the initial work is done, they might be handed off to other programmers, so having shared code libraries might end up being a big problem.

Any suggestions from people that might have had to deal with a similiar situation?

PS: I'm the only developer on both of these projects, and it looks like it's going to stay that way for a while.

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

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

发布评论

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

评论(2

千秋岁 2024-07-23 07:49:38

将共享功能抽象回具有定义的接口和默认实现的框架或库是处理此问题的常见方法。 例如,如果您选择支持一种插件架构,那么它可能可以在您的所有项目之间共享。 大多数时候,您想要共享的内容是非常基本的功能或可以轻松自定义的相对抽象的功能。 前者更容易识别并分解到公共库中。 后者有时可能比简单地通过较小的更改重新实现代码(共享模式而不是代码)需要更多的工作。

您需要注意的一件事是让实际的重用驱动公共库的设计,而不是提前提出共享架构。 人们很容易陷入框架设计并将其抽象出来以供共享使用。 不幸的是,您经常发现共享使用永远不会发展或发展方向与您预期不同,并且您最终会重写或丢弃大部分框架 - 或者更糟糕的是,保留和维护未使用的代码。 让 YAGNI(你不会需要它)作为你的指南,并延迟对公共库的重构,直到你真正需要为止。

Abstracting shared functionality back to a framework or library with defined interfaces and default implementations is a common way to handle this. For example, your plugin architecture, if you choose to support one, is probably something that could be shared among all of your projects. Most of the time the things you want to share are pretty basic functionality or relatively abstract functionality that can be easily customized. The former are easier to recognize and factor out to common libraries. The latter may sometimes be more work than simply re-implementing the code with minor changes (sharing patterns rather than code).

One thing you want to be careful of is to let the actual re-use drive the design of common libraries rather than coming up with a shared architecture in advance. It's very tempting to get caught up in framework design and abstracting it out for shared use. Unfortunately you often find that the shared use never develops or develops in a different direction than you expected and you end up rewriting or throwing away much of the framework -- or even worse, keeping and maintaining unused code. Let YAGNI (you aren't gonna need it) be your guide and delay refactoring to common libraries until you actually have a need.

回忆凄美了谁 2024-07-23 07:49:38

这里有几种(至少)不同的方法,您当然可以同时使用这两种方法。 首先,您可以将一些通用代码删除到单独的项目中,然后静态调用该代码。 这很容易做到,有时我会使用简单的辅助函数来采用这种方法,这些函数可能不属于我的主项目中的类 - 一个很好的例子是数学库或类似的东西。 另一种方法是将通用功能提取到类或接口中,然后继承和扩展。 根据您希望重用的代码,您可以使用其中一种(或两种)方法。

我怀疑你会发现这比你想象的要容易。 使用一些简单的代码进行尝试,在同一解决方案中设置一个新项目,从现有代码中引用您的库,看看效果如何。 也没有理由不在多个解决方案中引用您的共享项目。

如果开发被移交,拥有共享代码库不一定是问题。 目前,您可以让您的 2 个站点引用您维护的相同库(或多个库),但是如果您将项目拆分给其他团队,您可以向每个团队提供共享代码的副本。

There are a couple (at least) of different approaches here, and you could certainly use both. Firstly you could remove some common code in to a separate project and just call that code staticaly. This is pretty easy to do and I sometimes take this approach with simple helper functions that probably don't belong in a class in my main project - a good example would be a math library or something like that. The other approach is to extract common functionality in to a class or interface which you then inherit and extend. Depending on what code you are looking to reuse you might use either (or both) of these approaches.

I suspect you will find it easier than you think. Try it with some simple code, set up a new project in the same solution, reference your library from your existing code and see how it goes. There is also no reason not to reference your shared project in multiple solutions either.

Having shared code libraries need not be a problem if the development gets handed off. For now you can have your 2 sites reference the same library (or libraries) which you maintain, but if and when you split the projects out to other teams you can give a copy of the shared code to each team.

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