标签归档:注释

与代码的相处之道

与代码的相处之道 — 读《编程人生》一二章有感

最近在阅读《编程人生》,看了作者对Jamie Zawinski(Lisp黑客、XEmacs开发者、Netscape浏览器和Mozilla核心开发者)和Brad Fitzpatrick(80后程序员、LiveJournal和memcached开发者,Google员工)的采访,除了感慨作者采访的准备充分外,对于牛人的一些观点有一些共鸣,也有一些观点不太认同,尽信书不如无书,对于牛人也是如此吧。
一个程序员,大多数时间都在写代码,调试代码,阅读代码、评论他人的代码……林林总总,都是与代码相处。那如何与代码相处呢?首先我们需要认知到代码是什么,代码是一种语言,一种我们与计算机沟通的语言。我们需要通过代码告诉那个有点傻傻的计算机需要做点什么。

对于一些新增加的内容,我们可以从如下的方面与代码相处。

  • 第一,了解写这些代码是为了什么,或者说你的需求是什么,列出所有的功能点,估算你实现这些功能需要多长的时间,在估算的过程中,你不能将自己的工作时间完全算在开发中,大概50%差不多,毕竟我们不会一整天的写,还会有思考,发呆,梦游,开各种网页,看各种新闻,被各种im打断……
  • 第二,为你的新的功能搭出基本的架子,比如写好空类或空的函数,后面的工作就是填充这些空的地方了。当然在写这些空类或空函数的过程中,把注释写清楚,这是一个理顺自己代码结构和业务逻辑的过程。
  • 第三,这一步当然就是填充之前留空的内容了,在整个过程中你可能会写入一些调试的代码,没关系,先放着,因为在这个过程中你可能会再次需要这些调试的代码。
  • 第四,验证需求,重构代码。每个设计方案在开始的时候都是完美的,包括就在刚才你的代码结构设计。只是在细化需求时,可能部分细节没有考虑到,此时你就需要重构刚才的设计和代码,以适应这些变化。
  • 第五,打完收工,这是一个收尾的工作。此时,我们需要再次阅读你刚才写好的代码,清除这个过程中出现的调试代码,确认整个过程是否已经全部完成了所需要的功能点。
  • 第六,提交

如果你不是重新开始写一个功能,而是在别人(或你自己之前)的代码上修改并增加新的功能,此时当如何相处呢?

  • 第一,了解过去,分析影响范围,列出checklist。一段旧的代码,你最好先了解他的过去,看他与哪些其它模块有耦合,或者有哪些内容依赖于他,如果修改了这些内容,对其他模块是否有影响,如果要修改的是对外的接口,是否需要适配这些接口?
  • 第二,修改代码。此时你可能会重构之前的代码,那么在重构的过程中需要把握重构的度,不要轻易的将重构变成重写。毕竟之前的一些细节可能是你没有考虑到的。如果修改的代码中有对外的接口,此时可能需要保留这些接口,或者修改所有的调用这个接口的地方,这个就要权衡两者的机会成本了 。
  • 第三,根据checklist验证所修改的内容是否正确,验证是否影响了其它相关的内容
  • 第四,提交

如果是不是重新开始写一个功能,而是由于bug或其它原因需要调试代码呢?此时当如何相处?

  • 第一,了解它。我们需要先通读代码,审阅整个代码的结构,确认在整体的方向上没有问题。
  • 第二,在关键点打印信息,当然,你也可以使用调试工具与之交互,但是打印语句是一种绿化无污染的调试方式,不依赖于外部的环境,不过你需要通过第一步,先对代码有一定的了解才行。
  • 第三,确认问题,修改。此时可能需重复上面的修改流程
  • 第四,提交

前面三个都是通过代码告诉计算机怎么做,在某些时候我们也需要计算机告诉我们他做了什么。因此,在这里我们也需要通过代码告诉计算机如何将信息反馈给我们。一般来说,需要告诉他如何将整个代码执行过程中发生了什么告诉我们,比如日志,比如执行过程中的信息打印。

如果你是想优化一些代码,此时当如何相处呢?

  • 第一,确认需要优化的内容。可能你需要优化时间,也可能是需要优化空间,确认优化的内容。嗯,Knuth说过:过早优化是万恶之源。
  • 第二,找出瓶颈。优化并不是优化所有的地方,而是要找到优化的关键点,比如循环调用许多次的函数,或者花费时间或空间较多的地方等等。
  • 第三,寻找优化方案。可能你需要的仅仅是调换一下代码的执行顺序,或者释放执行过程中的某些变量所占的内存,当然也有可能需要优化整个数据结构,或者换台机器也是一个不错的主意。
  • 第四,验证优化结果。
  • 第五,提交

优化是一个持续的过程,在写代码的过程中能够随手优化的就优化吧,比如局部变量的使用等。

代码是我们与计算机沟通的语言,也是我们与其它程序员沟通的语言,因此除了让计算机了解代码外,我们也需要为其它程序员(或一段时间后的自己)了解这些代码做点什么,除了团队内部构建良好的代码规范,统一代码风格这些老生常谈(老生常谈其实挺好)外,书中的牛人提出关于注释的观点也非常认同:关于注释我们得写点不一目了然的东西。至少不要出现类似于循环结束,某某值加1的注释,一般来说注释应该是写点与业务相关的东西,至少在第一眼看代码无法看出来的东西。虽然现在敏捷提倡“代码即文档”,不要注释,提高代码的可读性,但是一些注释还是必要的。