首先说说测试以及文档的必要性吧
随着参与开发的项目越来越多，接触的业务和代码、以及参与开发的IT人员越来越多，我发现我并没有那么多时间去慢慢揣摩那些代码的意思，也没有那么多精力去一步步验证所有的业务逻辑。而在需要在以前的代码基础上做一些更改或改进的时候，常常也是一个头两个大，感觉是进了“坑”，当然这些“坑”有时候也有自己挖的……
在刚开始工作的时候，书上以及�前辈告诫都说最好要写好测试写好注释，说一个好的程序员的判断标准就是看其测试写的是不是够好…显然，我并没有听进去，只觉得写测试太麻烦，太浪费时间，所以一般情况下都是忽略掉不写的。
这个时候也发现了当时的我也是挖了挺多坑的……自己挖的坑迟早都要填的！而在写好了测试和文档的情况下，对于后续开发以及以前需求整理起来，真是方便太多了。
写测试代码的好处：
改变思路：能做到从需求到代码的过程转换，逐步细化；
简化代码：力图让每个方法都很小，只专注一件事；
优化代码：当测试代码写不出来，或者需要写很长的时候，说明代码是有问题的，是可以被分解的，需要进一步优化；
便于扩展：当扩展新业务或修改旧业务时，如果测试代码没有成功，则说明扩展和修改不成功；
时半功倍：貌似写测试代码很费时，实际在测试、部署和后续扩展中，测试代码将节省更多的时间。
那么现在从我个人角度出发来说说我觉得应该需要什么样的文档(文档由yard自动生成)和测试吧
注释
从model层面上说，首先得列出对应数据库的每个字段以及对应的意思，然后写明这个model存在的意义，比如说是为了计算什么或者记录什么。然后model里面的每个方法，也都要至少写一句注释，标明作用；稍微复杂一点方法则需要写明参数和返回值，以及可能在不同情况下的期望返回值；在具体方法代码里，则需要标注好实现的思路特殊的算法什么的。
在controller里，首先也是每个controller或者方法都要写明作用，然后controller里面更多的牵扯到流程以及权限的东西，这些都是需要好好注释的点
对于某些很复杂的流程，则最好单独写一个页面，演示以及写明思路和流程
测试
如果注释写的很完美，一些需要注意的问题都写全了，那么测试代码就比较好写了，那就是-->针对每句注释都写好对应的测试。
写好正向测试的时候也需要考虑反向的问题，就像如果某个方法只限定了几种类型的参数输入，那么我们除了测试允许的几种类型，也需要放几个其他类型的参数进去测试，以期望获取某个报错或者提示。
我们在写完某块代码过后回头在写测试的时候，写的过程中其实也能发现代码中的不足而去改进代码，测试和程序代码之间应该是一个互补促进的关系。
我们的007也推崇一种写代码的模式：先写测试，后写代码。先把思路和流程在测试代码里体现出来，然后再去根据测试的流程来一步步充实自己的功能代码……想想也是一件比较有意思的事
网友评论