代码质量之可维护性

 

我的心态变化

第一次接触编程，学习C语言，交换两个数的值： 

c = a 

a = b 

b = c 

后来我我从师兄那学到了下面这段代码，觉得写的比我之前的更漂亮：

a = a + b 

b = a - b 

a = a - b 

最后参加工作了，看到很多别人的代码，最后又觉得最漂亮的代码是这样的： 

c = a 

a = b 

b = c 

请问大家，为什么我的心态有这样的变化？

 

软件开发的现实

• 一个软件生命周期中，80%的时间和精力花费在维护阶段。
• 几乎没有任何一个软件，在其整个生命周期中，均有最初的开发人员维护。
• 几乎没有任何一个软件，在其整个生命周期中，它的文档与代码是保持同步的。

场景再现

有两种人，第一种人维护的是自己的代码，但是，随着时间的流逝，以前的关于系统的理解和记忆已经逐渐消失了，每次修改bug或增加新功能时，要通过看文档、看代码来回忆当时开发系统的场景。

第二种人，代码不是自己写的，需要阅读相关文档和代码，为了弄明白某一处代码的意图，需要了解整个模块的逻辑流程，还要看相关需求和设计文档，但是很遗憾，这些文档都和实际代码不同步。

最终，没有彻底理解到代码意图的人们急于修改代码，只会给系统引入新的bug。

 

如何解决—提高软件的可维护性

影响可维护性的因素

1.是否是同一个开发人员

2.人的质量如何，技术功底，对业务领域的熟悉程度

3.是否有完善的文档，文档是否同步

4.代码是否自解释，是否有足够的注释

 

落地措施

1.提高自身的质量，技术功底（面向对象、重构），熟悉业务，多与同事face to face交流

2.关键地方一定要写单元测试，单元测试能够让你更快速回忆当初开发系统时的场景。

3.利用卡片、白板、或者excel（如果你喜欢敏捷，可以试试scrum），为你维护的项目或者模块写一个故事，每一个项目，每一个模块，甚至每一行代码都有自己的故事，我们大部分时间都只是它的过客。你为它们建立了历史档案，总有一天你用得着。

4.你可以写一个小的工具自动化完成相关维护任务（ 常规性的，有规律），提高你的工作效率。

5.养成随时记录思维的好习惯，利用思维导图软件，我用的就是xmind。

6.代码要多些注释，改动代码要写名字和原因，写名字的意思表示个人对此次改动负责，能够提高代码主人翁精神，潜移默化的影响开发人员反复琢磨代码的好坏。

 

可维护性的前提——可理解性，如果你不理解它，你怎么维护它？

其实，维护软件最头痛的是，随着时间的流逝，以前的关于系统的理解和记忆已经逐渐消失了。每次修改bug或增加新功能，要通过看文档，看代码来回忆当时开发系统时的场景。

软件质量特性中最重要的我认为是可维护性，而可维护性的前提是可理解性。

 

我们要理解谁？

1.理解人，我们每天的开会，日常交流，任务分配，培训都是在人和人的交流。 你是一个理解性强的人，还是一个表达性强的人？这都很重要。

2.理解文档，信息只有被用心组织才能有更好的可理解性。

3.理解代码，好的代码会自解释，会说话，坏的代码面目狰狞，五官发育不全，代码的可理解性是靠开发人员来控制的，是造一个天使还是一个怪物，全看我们的态度是怎么样的。

 

可理解性强的代码不是一门技术，而是一门艺术。