从最近遇到的几个故事说起.
故事一:
某天晚上和室友聊天,谈到使用Vim阅读代码,室友也是使用Vim的人,他说用类似ctags的查找定位功能不多,更多的时候,他阅读一段代码,要定位一个功能点,首先是从阅读代码文件的组织,了解项目的功能等入手,等这些都基本清楚了,定位起来就会快很多.我虽然认为,ctags实在是Vim里面一个很不错的功能,不用这个实在可惜,但是他说的那套定位思路其实也是不错的方法.其实我自己用惯了ctags类的功能之后,阅读代码的时候也会用惰性,更多的时候是要靠这些工具来帮我定位,而不是通过自己主动的思考和分析.
故事二:
我的经验里面,写完一段代码之后的第一次编译,如果编译器报错越少,那么可以认为这段代码将来可能出现bug的几率越小,简而言之,我认为代码的质量与第一次编译的报错数量成反比(哦,不用拿helloworld类的程序跟我钻牛角尖了:).有些人写的代码,哗哗的写了一大段,写之前不考虑好,只想着到时候写的不对了可以在编译由编译器的报错来帮忙找问题,这个思路是不对的.编译报错越少的代码,说明了作者写的时候思路更清晰一些,考虑的更周全一些,所有的这些流程上的步骤走的都不错了,所以才有最后编译报错少的结果.编译报错应该是写代码的结果之一,而不应当当成了找代码问题的手段,这样的思路,本末倒置了.
故事三:
进入新项目组后,组内对代码编码的流程有比较严格的要求,包括写一个API之后需要写一个针对这个API的各种情况的测试用例,提交代码的时候,需要走codereview流程,需要使用cpplint检验代码风格,需要将对应的测试用例也提交上去.这一套流程走下来,提交代码的频率比之以前,降低了很多,但是不可否认的是,也确实提高了代码的质量.假设一个功能,由N个API构成,如果能对这N个API都做过详细的测试,保证它们的输入和输出在各种情况下都能符合要求,那么很显然的,最后这个功能也应该是正确的.反之,越是到了测试阶段需要使用类似gdb这样的调试器来定位问题的,会越让人不放心---因为没有制度和流程的保证,谁也不能说将来可能在哪个点会出问题.它可以帮你定位问题,但是没有办法告诉你已经没有问题了,最后这一点,最终还是要通过严格的单元测试等流程来保证的.与第二个故事相同,我认为,在测试阶段使用gdb定位问题的次数也与代码的质量成反比:)
这几个故事综合起来,想要表达的是,做一件事情,需要有流程,制度的保证,当然也需要工具(比如这几个故事里面提到的Vim,gcc,gdb),但是工具就是工具,它只是一种手段,没有办法替代正确的思路,流程和制度等,仅能在整个过程中起到辅助的作用.而且,过分依赖工具,也会给人以惰性(比如前面提到的使用编译器编译代码来找错,比如使用gdb来保证功能正确性等).
所以,更应该提倡的是正确的流程,制度,有了这些,项目的质量才能有所保证.比如,在写一个功能点时,需要具体分解为哪几步,每一步有哪几个API,针对它们的测试用例有哪些,测试时的输入和输出有哪些,需要考虑的异常情况有哪些,等等的.这些都考虑清楚了,再动手写,久而久之,我想这方面的能力会慢慢的提高.