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

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

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

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

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

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

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

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

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

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

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

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