代码可维护性的神秘面纱

本文来自DZone&＃xff0c;作者Matt DuVall是一名软件工程师&＃xff0c;他在此分享可维护性在软件开发里的重要性。所谓软件的可维护性其实说简单了就是软件代码的可被修改的容易程度。为了适应新环境、满足新需求&＃xff0c;只有对当初的设计初衷进行修改&＃xff1b;在这个修改过程里&＃xff0c;只有考虑到提高代码的可维护性&＃xff0c;才能更好适应软件演化。

每一次代码评审的时候都会考虑到&＃xff1a;从长远角度来看&＃xff0c;这些代码都是可维护的吗&＃xff1f;对于这一问题&＃xff0c;估计任何一个开发者的反应都是很敏感的。当开发者A想要在代码库里添加一个比较重要的组件的时候&＃xff0c;开发者B经常会半信半疑的关心道&＃xff1a;有没有考虑到它的可维护性&＃xff1f;必须要谨慎行事&＃xff01;

对于开发者来说&＃xff0c;可维护性到底意味着什么&＃xff1f;是为了让别人能读懂这些代码&＃xff1f;保证让别人看得懂代码
只是可读性而已&＃xff1b;如果要考虑到可读性&＃xff0c;那么只能说可读性在整个开发过程算是有效地可维护性因素之一。对可维护性更恰当的解释往往需要考虑到可扩展性、抽象性和更高层次的设计以及架构等方方面面。这可能会引起很多误解&＃xff0c;为什么我们写软件。软件的存是为了驱动业务需要&＃xff0c;增加商业价值&＃xff0c;最终的目标是产生收入。废话不多说&＃xff0c;先来讲述一下可维护性几大要素吧&＃xff01;

可扩展性

如果讨论到可扩展性的时候需要深入探讨抽象的设计模式和编程语言的话&＃xff0c;那么最好是后退一步&＃xff0c;对项目的目的进行重新评估。这无异于在一个可能会花费1年、5年或10年的项目上进行跟踪评估&＃xff0c;除非开发者有预见未来的能力&＃xff0c;知道未来的软件特征集是什么样子——那样就不必煞费苦心花太长的时间进行跟踪测试了。专注于当前具体的代码编写&＃xff0c;并即时解决眼前的问题。同时&＃xff0c;不要在模糊不清、过于抽象的问题上花太多的时间。

抽象化

不可维护代码出现的迹象是代码库有漏洞&＃xff0c;或者是根本不存在抽象&＃xff0c;这样就使得其它区域的代码库在工作当中缺少娱乐性。这是真实存在的情况。如果现有的抽象感被破坏了&＃xff0c;就必须立即修复。然而&＃xff0c;抽象化在商业里也可能成为职业危害因素——为了抽象化而抽象化。所以&＃xff0c;开发者需花时间试着去理解被提出来的是什么建议&＃xff0c;建议的主旨是什么&＃xff0c;并研究一下这样做是否对目前的代码库有意义&＃xff1b;取3-4个实例来证明一下抽象是否在这个项目里有用&＃xff0c;如果没有用的话就放弃之前提出的建议。Rails社区已经采用了PDI&＃xff08;请做调查&＃xff09;方法&＃xff0c;当引入抽象层的时候可以利用PDI来观察看它是否有意义。

高等级设计

总有人会生拉硬拽将设计模式塞到一个组件里&＃xff0c;以此来进入到代码库。可维护性的典型问题是“高等级设计”&＃xff0c;同时开发者会为了自身的需要尽量和当前的问题撇清关系&＃xff0c;但最终还是会专注于抽象化和模糊性。这些设计原则需要对当下的软件开发有意义。在开发前应该具体说明&＃xff1a;更好的Web开发目的是为了让我们在长期生活里有更好的条件。　　

这并不是对抽象、可扩展性、或软件设计的批评——这些想法都是软件开发、Web开发领域的核心思想。能够帮助开发者创建出更好、更强大的软件。它们不应该被放在可维护性的背面&＃xff0c;如果将这些原则用在猜测工作上是绝对不利于创造出好的软件。                                                       &＃xff08;校审/付江&＃xff09;

原文&＃xff1a;Matt Duvall