向急需重构的代码库添加功能
我正在开发一个有点难以使用的系统。它 99% 没有文档记录，不遵循最佳实践，并且相当难以理解（大量全局变量、跨越 50 行的方法、滥用评估等）。不幸的是，我对代码库相当陌生，我需要添加功能。
我确信其中有我可以重用的代码，但我必须在截止日期前完成，并且担心抢救所花费的时间最终会导致我最后匆忙。从长远来看，什么更好？我一方面希望尽可能多地重用，但另一方面又说我应该专注于从头开始编写新功能，冒着重复的风险（计划在我有更多时间花在现有代码上时进行重构） ？我倾向于后者，但想听听一些意见。
谢谢！
I am developing on a system that is a bit difficult to work with. It is 99% undocumented, does not follow best practices and is fairly difficult to understand (globals galore, methods spanning 50 lines, eval abuse, etc.). Unfortunately, I am fairly new to the code base and I need to add functionality.
I am sure there is code in there that I could reuse, but I have to meet a deadline and am afraid that the time spent salvaging will end up with me rushing at the end. What is better in the long run? Part of me wants wants to reuse as much as possible, but another part says I should focus on writing the new functionality from scratch, at the risk of duplication (with a plan to refactor when I have more time to spend with the existing code)? I'm leaning towards the latter but wanted to hear some opinions.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
http://www.joelonsoftware.com/articles/fog0000000069.html
http://discuss.joelonsoftware.com/default.asp?design.4.469415.13
http://www.joelonsoftware.com/articles/fog0000000007.html
< a href="http://www.paulgraham.com/hp.html" rel="nofollow noreferrer">http://www.paulgraham.com/hp.html
话虽这么说，如果有小要清理的部分，通常没问题。一旦您已经研究了一段时间，您就会更好地了解战略性的本地化重写在哪里最有效且最不危险。
在生产代码库中，请记住，为客户保持现状比推出新东西更重要。这并不能阻止你的老板对你大喊大叫。但是问问自己，有多少次因为错误而切换到替代产品，有多少次因为您想要的增强功能在其他可行的产品中不够快而这样做。
http://www.joelonsoftware.com/articles/fog0000000069.html
http://discuss.joelonsoftware.com/default.asp?design.4.469415.13
http://www.joelonsoftware.com/articles/fog0000000007.html
http://www.paulgraham.com/hp.html
That being said, if there are small sections to clean up, that's usually fine. Once you have been working on it for a while, you'll have a better idea of where a strategic, localized rewrite will be most effective and least dangerous.
In a production code base, remember that keeping things status quo for the client is more important than getting new stuff out the door. It won't stop your boss from yelling at you. But ask yourself how many times you've switched to an alternate product because of bugs, versus how many times you've done so because the enhancement you wanted wasn't fast enough in an otherwise workable product.
我会跟随你的直觉：按照你知道的方式编写。 TDD，如果这是你的方法；无论如何，尽量确保你的新东西经过了相当好的测试（当然，比现在的东西要少一些混乱）。
将来，您可能确实有机会进行重构，找到重复的功能，并选择哪些方法和功能。要保留的课程；在这些情况下，您可能会发现自己是守护者。
当然，“未来”完全有可能永远不会到来。至少你的新东西是工作的、可读的和可重用的——这比你花时间在现有代码库中追踪一个函数（正如你所描述的）并重用它更好。
I'd go with your instinct: write it the way you know how. TDD, if that's your approach; at any rate try to make sure your new stuff is reasonably well test-covered (and, of course, less of a mess than what's in there now).
Down the road, you might indeed get the chance to refactor, to find duplicated functionality, and choose which methods & classes to keep; it's likely that in those cases you'll find your own are the keepers.
And, of course, it's entirely possible that "down the road" will never come. At least your new stuff is working, readable, and reusable - and that's a better situation than if you took the time to track down a function in the existing code base (as you have described it) and reuse it.
您遇到的所有问题都可以通过阅读有效使用旧代码来克服。我知道您说过您的截止日期很紧，但仓促且不完全理解核心代码库可能（并且可能）会产生一些负面影响。
另外，您提到计划在时间允许时进行重构。我已经说过很多次了，让我告诉你，那个时刻几乎永远不会到来。第一次就做对，这对下一个开发人员或以后添加新功能时有好处。
Everything you are experiencing can be overcome by reading Working Effectively With Legacy Code. I know you said you were on a tight deadline but rushing and not fully understanding the core code base could (and probably) have some negative side effects.
Also, you mention planning to refactor once time permits. I've said that many times and let me tell you that almost always that time never comes. Do it right the first time and do yourself a favor for the next developer or when you add new features later on.
我们在我的企业中处于同一条船上：第一阶段的方向有效，但并不理想。第二阶段改变了业务模式和逻辑……这个阶段是离岸的，如果公司真正了解他们选择构建的框架，那么这本身就不会成为问题。因此，我们在这里试图完成第 3 阶段（消除第 2 阶段的混乱，按照预期正确使用框架），同时感叹必须在编写如此糟糕的代码库上工作。我们面临着重大的挑战——使用两个 javascript 框架、笨重的旧版 UI、垃圾代码，以及框架的重大更新，这些更新使我们使用的版本过时并且几乎不可能迁移到新版本。
这是我们选择做的事情......它可能不适合您的情况。首先，我们的产品开发副总裁花了两周时间彻底重构了数据库结构。他重新安排我们的编程人员根据需要修改现有代码，以适应正确、高效的数据库结构。一旦完成这个（痛苦的）步骤，我们就休息了两周，以在新功能上取得进展。然后，我从自己的职责中抽身出来，完全重构了 UI，取消了对一个 Javascript 框架的使用，这样我们就可以在一个通用平台上（多好的一个概念，暗示着可怕的离岸公司......）并制作有效利用现代、高效、当前的 UI 元素。在产品结束测试版之前，我们将遵循 80%-20% 的任务组合——80% 实现最终需求，20% 重构代码并清理遗留混乱。每个员工都有一个负责“清理”或提高效率的区域。流程记录也是一项已委派的任务，并且是每个员工每周工作的必需百分比。
我认为我们流程成功的关键是在第三阶段完成之前就着眼于第四阶段。新代码正在以最高的效率和可互换性构建，因此如果我们离开这个过时的平台，将需要最少的更改。我正在尝试一种方法来划分我们的流程（而不仅仅是代码），以便理论上可以在适当的时候将它们单独移动到新的框架。我们未来的计划已经写在纸上，不断变化的需求清单和正在进行的研究，以寻找最好的工具。最重要的是，团队领导者坚持正确有效地做事，因此当前或未来的任何事情都不会做得不对。
很难向管理层证明你需要倒退才能前进。当您公司的整个未来都依赖于像我们一样陷入测试阶段的产品时，情况就更加困难了。我将其与花更多钱购买节能设备进行比较……现在成本会更高，但最终会获得巨大的经济回报。我认为在这种情况下取得成功的秘诀是找到你的产品的中位数，在你花时间让产品变得更好的同时，它“足够好”可以独立存在。制定满足该中位数的策略将要求业务部门保持耐心，并最终在成功时让您成为英雄。制定一个强有力的计划，传达该计划，与他人良好相处，并全力以赴。很快，您将再次享受生活！
We're in this same boat at my business: Phase one went a direction that worked, but was not ideal. Phase two changed the business model and logic.....this phase was offshored, which itself wouldn't have been a problem if the company had actually understood the framework they chose to build on. So, here we are trying to finish phase 3 (undoing the mess of phase 2, properly using the framework as it was intended) while lamenting having to work on such a poorly written codebase. There were significant challenges--the use of two javascript frameworks, clunky legacy UI, junk code, and a major update to the framework that makes the version we're on obsolete and near impossible to migrate to a new version.
Here's what we've chosen to do....it may not be ideal for your situation. First, our VP of product development took two weeks and completely re factored the database structure. He re purposed our programming staff to modify existing code as necessary to accommodate the proper, efficient DB structures. Once that (painful) step was done, we took a two week break to make progress on new features. Then, I took a break from my duties to completely refactor the UI, un-doing the use of one Javascript framework so that we're on one common platform (what a concept, hint-hint awful offshore company...) and making effective use of modern, efficient, current UI elements. We'll be following an 80%-20% mix of tasking until the product is out of beta--80% achieving finalized requirements, 20% refactoring code and cleaning up the legacy mess. Each employee has been given an area that they are responsible for "cleaning up" or making more efficient. Documentation of the processes is also a task that's been delegated and is a required percentage of each employee's work week.
I think the key to the success of our process is an eye toward phase 4 even before phase 3 has been completed. New code is being built with maximum efficiency and interchangeability, so if and when we move off this outdated platform, minimum changes will be required. I'm experimenting with a way to compartmentalize our processes (not just the code) so they could theoretically be individually moved to a new framework when the time is right. Our future plans are on paper, with a requirements list evolving and research in progress for finding the best tools. Most importantly, the team leader is a stickler for doing things correctly and efficiently, so nothing current or future will go forward that's not done right.
It's tough to justify to management that you need to go backward to go forward. It's even more difficult when your company's entire future is dependent on a product that's stuck in beta as we were. I compare it to spending more for a fuel efficient appliance....it's going to cost more now, but ultimately it's going to reap huge financial rewards. I think the trick to being successful in this situation is finding the median for your product where it's "good enough" to stand alone while you spend time to make the product great. Developing a strategy to meet that median will challenge the business unit to be patient, and ultimately will make you the hero when it succeeds. Develop a strong plan, communicate that plan, play well with others, and work your tail off. In no time, you'll be enjoying life again!
不要担心您要添加的这一小块功能。做得又快又脏。
如果您的团队计划重构源代码，请确保获得管理层的支持。让您的管理层了解您现在面临的问题：当前的代码库未遵循最佳实践。应用程序变得越非结构化，添加功能所需的时间就越多。构建新功能不会花费最多的时间，但确保它在每种情况下都能按预期运行，并且在 foobar 出现问题时修复问题也将花费宝贵的时间。
如果您要重构应用程序，请考虑一下如果您选择一些现成的解决方案来更好地实现应用程序的某些部分，您将会获得哪些收益：
我可以继续一段时间。
有时，应用程序的完全重建会后退两步，但会前进四到五步。
Don't worry about this small piece of functionality you are adding. Do it quick and dirty.
If your team is planning a refactoring of the source code, make sure you have the support of your management. Let your management know about the issue you are now facing: the current codebase is not following best practices. The more unstructured the application becomes, the more time it will take to add functionality. Building the new functionality will not cost the most time, but making sure it will behave as expected in every situation will, and fixing the problems when something goes foobar will also cost valuable time.
If you were to refactor the application, think about the gains you would have if you would choose some readily available solutions to better implement parts of your application:
I could go on for a while.
Sometimes a complete rebuild of an application is two steps back, but four or five steps forward.