Don‘t Be Afraid to Break Things 24

Don’t Be Afraid to Break Things
Everyone with industry experience has undoubtedly worked on a project where the codebase was precarious at best. The system is poorly factored, and changing one thing always manages to break another unrelated feature. Whenever a module is added, the coder’s goal is to change as little as possible, and hold their breath during every release. This is the software equivalent of playing Jenga with I-beams in a skyscraper, and is bound for disaster.

The reason that making changes is so nerve wracking is because the system is sick. It needs a doctor, otherwise its condition will only worsen. You already know what is wrong with your system, but you are afraid of breaking the eggs to make your omelet. A skilled surgeon knows that cuts have to be made in order to operate, but the skilled surgeon also knows that the cuts are temporary and will heal. The end result of the operation is worth the initial pain, and the patient should heal to a better state than they were in before the surgery.

Don’t be afraid of your code. Who cares if something gets temporarily broken while you move things around? A paralyzing fear of change is what got your project into this state to begin with. Investing the time to refactor will pay for itself several times over the life cycle of your project. An added benefit is that your team’s experience dealing with the sick system makes you all experts in knowing how it should work. Apply this knowledge rather than resent it. Working on a system you hate is not how anybody should have to spend their time.

Redefine internal interfaces, restructure modules, refactor copy–pasted code, and simplify your design by reducing dependencies. You can significantly reduce code complexity by eliminating corner cases, which often result from improperly coupled features. Slowly transition the old structure into the new one, testing along the way. Trying to accomplish a large refactor in “one big shebang” will cause enough problems to make you consider abandoning the whole effort midway through.

Be the surgeon who isn’t afraid to cut out the sick parts to make room for healing. The attitude is contagious and will inspire others to start working on those cleanup projects they’ve been putting off. Keep a “hygiene” list of tasks that the team feels are worthwhile for the general good of the project. Convince management that even though these tasks may not produce visible results, they will reduce expenses and expedite future releases. Never stop caring about the general “health” of the code.

By Mike Lewis
不要害怕打碎东西
毫无疑问，每个有行业经验的人都参与过一个代码库充其量也不稳定的项目。这个系统考虑不周，改变一件事总是会破坏另一个不相关的功能。无论何时添加模块，程序员的目标都是尽可能少地更改，并在每次发布时屏住呼吸。这是一个相当于在摩天大楼里用工字钢玩詹加的软件，注定会发生灾难。做出改变之所以如此令人神经紧张，是因为系统出现了问题。它需要医生，否则情况只会恶化。你已经知道你的系统出了什么问题，但你害怕打破鸡蛋来做煎蛋饼。一个熟练的外科医生知道必须做出切口才能进行手术，但熟练的外科医生也知道切口是暂时的，会愈合的。手术的最终结果值得最初的疼痛，患者应该会恢复到比手术前更好的状态。不要害怕你的代码。谁在乎你搬东西的时候东西是否暂时坏了？对变革的恐惧让你的项目一开始就陷入这种状态。在项目的生命周期中，投入时间进行重构将获得数倍的回报。另一个好处是，您的团队处理病态系统的经验使您成为了解其工作方式的专家。应用这些知识而不是怨恨它。在一个你讨厌的系统上工作不是任何人都应该花时间的方式。重新定义内部接口、重构模块、重构复制粘贴的代码，并通过减少依赖关系来简化设计。您可以通过消除角点情况来显著降低代码复杂性，角点情况通常是由不适当耦合的功能造成的。慢慢地将旧结构转换为新结构，一路测试。试图在“一个大的shebang”中完成一个大型重构将导致足够多的问题，使您考虑中途放弃整个工作。做一个不怕切除病变部位为愈合腾出空间的外科医生。这种态度具有感染力，会激励其他人开始从事他们一直拖延的清理项目。列出团队认为有利于项目整体利益的“卫生”任务清单。说服管理层，即使这些任务可能不会产生明显的结果，但它们会减少开支并加快未来的发布。永远不要停止关心代码的总体“健康”。作者：Mike Lewis