关于编程的一点感慨
写的代码缺乏生命力：
- 过段时间自己看，都有些陌生。
- 缺乏：设计思路图文，文档类注释，测试样例代码。
工作中，有时要维护修改业务功能时，总想重写掉得了，反而好维护。
大抵也是代码缺乏生命的缘故，这些代码不能离开维护他的人。
业务型的代码诞生之初一般不太考虑离开维护他的人。
设计图文
当代码量多时，一般都会在心中或者在纸上，有个大概的结构设计思路。
现在也仅仅有时写下些设计思路相关的注释，没有图文。
实际也在本子上画了些，但是没有保存到文档里。
注释
很少写注释，觉得麻烦。只在个人觉得要说明的地方写些自定义的注释。
有注意把函数名和参数名取的有意义。发现这时不够的，有些信息无法描述：
- 异常相关的信息
- 调用的约束
- 参数和返回值的范围
- 函数调用的外部条件
- 函数的一些特殊行为
google的代码注释详尽，格式规整，可用某某工具生成文档。注释的数量要和代码量差不多了。
两个工作里，都没有强调注释的规范。
想是业务性的代码更在乎快速出结果，业务代码都是谁写谁维护。
注释小结
- 业务代码：写点简单注释就够了。一般逻辑不复杂，都是在某个框架下，复制模式。
- 库代码：这种是把代码当成产品发出去的，需要详尽的文档。
测试代码
毕业进百度时还写过一段时间php的单元测试代码。
好麻烦，为了测试数据库部分，还要用个mock框架。测试代码比业务代码还多，感觉没什么收益。
当时就我这个刚入职的写了一段时间。
看luna的源码时，发现有专门写一套测试代码，而后在自己写脚本语言时也写了个。主要是对功能块的黑盒测试样例。
当修改代码时，运行测试可确保定义的行为没有改变。
google开源的代码普遍带有测试代码。
测试小结
- 业务代码：就不用写测试了，特别是单元测试，耗时费力收益小。
- 库代码：最好写一批模块黑盒测试代码，确保定义的行为一直正确。
后续看看要不要给子集写的几个基础库形式的代码加上测试代码。
异常处理
一般不处理异常的，把异常当Assert，直接抛出它让程序挂掉，处理的目的就是没有异常。
有些时候异常是要处理的，如给人用的编辑器。
写编辑器工具时，码那么多简单的测试输入的代码真是手酸。
业务性的代码差不多都是这样吧，各种检验输入。
