我的心态变化
第一次接触编程,学习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.理解代码,好的代码会自解释,会说话,坏的代码面目狰狞,五官发育不全,代码的可理解性是靠开发人员来控制的,是造一个天使还是一个怪物,全看我们的态度是怎么样的。
可理解性强的代码不是一门技术,而是一门艺术。