如何保持我的理智，同时维护意大利面条代码 [英] How to save my sanity while maintaining spaghetti code
问题描述
只是想听到一些建议（和安慰）的话，这将有助于我控制一些复杂的意大利面条代码 - 由多个程序员（通常彼此之间永远不会相遇）开发的代码。解决方案的功能只是互相补充。
Just wanted to hear some words of advice (and comfort.. ) that will help me to take control over some complicated spaghetti code -- code that was developed by multiple programmers (usually that never meet each other) over long time. the solution's features are just patched on top of each other.
通常我倾向于看到2种程序员：
Usually I tend to see 2 kinds of programmers:
-
害怕死亡程序员 - 那些家伙不会碰到他们没有的东西。他们可能会使用一个快速而肮脏的修复来完成维护任务，这将使下一个程序员开始寻找他们的家庭地址; - ）
"Scared-to-death programmers" - those guys will not touch anything that they don't have to. they will probably will complete the maintenance task using a quick and dirty fixes that will make the next programmer to start looking for their home address ;-)
它的作品
cons：
你希望你永远不会再看到这段代码..
cons:
you hope you will never see this code again..
教师 - 这些可能会在完全翻新其逻辑的情况下重写整个代码。
"Teachers" - those will probably rewrite the whole code while completely refurbishing its logic.
优点：
好吧，有人必须做肮脏的工作...
pros:
well, someone has to do the dirty work...
cons：
花费更长的时间，可能最重要的功能之一将会神奇地消失从产品
cons:
takes longer time and probably one of the most critical features will magically disappear from the product
从程序员生活的这个更黑暗的一面听到你的个人经历是很高兴的。
It will be nice to hear your personal experience from this darker side of the programmer's life.
我非常好奇地听到任何理论/动手建议，这将有助于我深入意大利面维修任务，而不会感到凄惨。
I am specifically curious to hear any theoretical/hands-on advice that will help me to dive into the spaghetti maintenance task without feeling so miserable.
推荐答案
虽然最好的建议是，就这个话题的其他海报都注意到，要写测试，我经常遇到这样的情况不切实际。如果代码是坏的（1000行方法，嵌入式和未记录的魔术数字，代码复制等），它也可能会有另一个问题，这就是它的深度耦合，组件几乎是不可能孤立的。
While the best advice is, as every other poster on this topic has noted, to write tests, I've often been in the situation where this is unrealistic. If the code is that bad(1000 line methods, embedded and undocumented magic numbers, code duplication, etc.etc) it's also likely to have another problem, which is that it's deeply coupled and components are almost impossible to isolate .
（例子
- 加载的代码库，缓存，启动时数百个不同的数据库对象组件假定高速缓存的随机部分存在，并且部分缓存假定缓存的其他部分 - 换句话说，你必须加载整个事情来获取任何
- 依赖于静态的代码，以及公开的状态变量，在那里不可能确定谁设置这些变量，甚至是什么意思）
(examples - a codebase that loads up, and caches, hundreds of different database objects on startup. Components assume random parts of the cache exist, and parts of the cache assume other parts of the cache - inotherwords, you have to load the whole thing to get anything - code dependant on static, and promiscuously public, state variables, where it's impossible to determine who's setting those variables, or even what they mean)
最佳建议我可以想出：
- 尝试修复容易/明显的事情首先。硬编码路径，魔术号码引用，明显的代码重复。也许一个快速释放可以摆脱最严重的20％的违规行为将是低风险，并使下一步更容易完成。
- 获得组织支持来反驳 - 通常不会有意志或愿意做不添加即时功能的工作，以及破坏现有代码的风险。当然，有重构的伟大论据，但并不是每个人都购买它们。如果组织不支持它，您可能必须放弃。
- 让其他开发人员围绕着同样的观点 - 如果他们有什么好处，他们可能不满意代码库就像你一样。如果新的代码是为了更好的标准而建立起来的，而且人们有动力，他们将开始修改旧的代码，因为需要调整。
- 如果一个特定的子系统真的很糟糕，达到了新的发展几乎不可能的地步，你可以利用这个机会重建它。
- Try to fix the easy/obvious things first. Hardcoded paths, magic number references, obvious code duplication. Perhaps a quick release that gets rid of the worst 20% of the violations will be of low risk and make the next steps easier to accomplish.
- Get organizational support for refarctoring - there's often no will or desire to do work that doesn't add immediate functionality, and risks breaking existing code. There are, of course, great arguments for refactoring, but not everybody buys them. If the organization doesn't support it you may have to give it up.
- Bring other developers around to the same view - if they're any good,they're probably as unhappy with the codebase as you are. If new code is built to better standards and people are motivated, they'll start to fix older code as tweaks need to be applied.
- If a particular subsystem is really, really bad and has reached the point where new development is nearly impossible you can probably use this opportunity to rebuild it.
这篇关于如何保持我的理智，同时维护意大利面条代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
