关于编程的一点感慨

写的代码缺乏生命力：

1. 过段时间自己看，都有些陌生。
2. 缺乏：设计思路图文，文档类注释，测试样例代码。

工作中，有时要维护修改业务功能时，总想重写掉得了，反而好维护。
大抵也是代码缺乏生命的缘故，这些代码不能离开维护他的人。
业务型的代码诞生之初一般不太考虑离开维护他的人。

设计图文

当代码量多时，一般都会在心中或者在纸上，有个大概的结构设计思路。
现在也仅仅有时写下些设计思路相关的注释，没有图文。

实际也在本子上画了些，但是没有保存到文档里。

注释

很少写注释，觉得麻烦。只在个人觉得要说明的地方写些自定义的注释。

有注意把函数名和参数名取的有意义。发现这时不够的，有些信息无法描述：

1. 异常相关的信息
2. 调用的约束
   1. 参数和返回值的范围
   2. 函数调用的外部条件
   3. 函数的一些特殊行为

google的代码注释详尽，格式规整，可用某某工具生成文档。注释的数量要和代码量差不多了。

两个工作里，都没有强调注释的规范。
想是业务性的代码更在乎快速出结果，业务代码都是谁写谁维护。

注释小结

1. 业务代码：写点简单注释就够了。一般逻辑不复杂，都是在某个框架下，复制模式。
2. 库代码：这种是把代码当成产品发出去的，需要详尽的文档。

测试代码

毕业进百度时还写过一段时间php的单元测试代码。
好麻烦，为了测试数据库部分，还要用个mock框架。测试代码比业务代码还多，感觉没什么收益。
当时就我这个刚入职的写了一段时间。

看luna的源码时，发现有专门写一套测试代码，而后在自己写脚本语言时也写了个。主要是对功能块的黑盒测试样例。
当修改代码时，运行测试可确保定义的行为没有改变。

google开源的代码普遍带有测试代码。

测试小结

1. 业务代码：就不用写测试了，特别是单元测试，耗时费力收益小。
2. 库代码：最好写一批模块黑盒测试代码，确保定义的行为一直正确。

后续看看要不要给子集写的几个基础库形式的代码加上测试代码。

异常处理

一般不处理异常的，把异常当Assert，直接抛出它让程序挂掉，处理的目的就是没有异常。

有些时候异常是要处理的，如给人用的编辑器。
写编辑器工具时，码那么多简单的测试输入的代码真是手酸。
业务性的代码差不多都是这样吧，各种检验输入。