“迭代细节”一次，是我根据“iteration detail”直接翻译过来的。中文名词里是什么，我不清楚。
我们项目的第一阶段终于完成了，最后的任务就是填写迭代细节表格：包含了用户需求、使用案例、估计时间与风险时间、任务说明以及最后的迭代细节。其它的部分我们一开始都填好了，但迭代细节我们一直留着没填。这本来应该是在项目开始的时候填写的，为什么留到现在才弄呢？
原因和过去一样，我们选择了一条偷懒的方法。开始的时候就填写迭代细节，有点无的放矢。虽然这样做并不是正确的方式，但相对来说容易一些。我们的另一门课《分布运算》课上老师给我们讲过类似的情况：以往的第二个作业是做一个服务器-客户端模式的任务管理系统，交作业的时候要叫做出的成果和设计的报告。本来设计报告是要在项目实际操作之前写的，但老师发现学生们都是先完成系统，再写报告。于是后来老师就把这么一次作业分成了两次作业了，于是现在的第二个作业成了设计一个这样的系统，提交设计的报告，而第三次作业则成了实现你设计的系统。
虽然道理我明白，不过过去我一直觉得做文字上的设计会影响一瞬而逝的灵感，应该抓住灵感后马上开始写代码。想我们项目这种巨细靡遗的迭代细节，我是连想都没想过的。Knuth倡导的Literate Programming，像在程序里写文学作品一样的做法，我是更无法接受的。
通过上次的经验，我体会到完成详细的文档对后面的维护是相当必要的，因此我才话了很长时间为几乎每个函数都写了尽量详细的Javadoc。过去我看Java api的源码，感觉似乎注释比代码还要多。现在我觉得这是应该的了。