3.1 re-work是否能够衡量代码质量呢？

[GreyZeng]

    “有人试图用“re-work”来表示质量，如改动少的代码最初质量高，因为re-work的次数少。笔者认为，re-work只是表明在软件开发过程中花费的时间，re-work的多寡并不跟最终的质量成正比。”

     读到此处，我想起了2.3章节中所提到的大学生和工程师在完成任务时的时间分配比例对比。其中，工程师将更多的时间用于“需求分析”、“具体设计”上，而少量时间用于“具体编码”，其意义就是要先整体设计好在进行编码，而笔者也认为这样的工作方式是高效的。
     那么问题出现了，充分的设计的目的就是为了减少re-work，倘若某段代码需要大量的re-work来进行修正，是否也就意味着设计阶段不充分，并未为后续的编码节约时间呢？一段没有被充分设计的代码是否也可以说质量并不是很高呢？

原文地址

[GreyZeng]

这个问题我目前认为书中说的不无道理，re-work的多寡确实并不和最终的质量成正比，但re-work还是可以一定程度上反应工程质量的。正如博客中所认为的，在着手具体编码实现之前的设计，其目的就是为了减少甚至避免re-work，而如果re-work较多，则说明设计不够到位，也就说明之前的工程质量出了问题，我仍然坚持认为这个逻辑是没有错的。
原文地址

[GreyZeng]

在以前任务不是那么重的时候，我认为不应使用写了再改的做法，因为当时认为写了再改也不会改出好程序，但是在这个学期的大量的代码的PUSH下，我发现在《构建之法》书中提到的某些程序使用写了再改的模式是比较有帮助的，像文中提出的只用一次的程序完全可以写一个“能跑的”出来，因为这个时候无需考虑太多知识，以后也不会用到这段代码，所以先“敏捷”出一个功能保证其他功能的完整性，这个时候如果去专门学习这个知识反而会浪费时间，不如把时间放到会反复使用的程序上。因此我现在感觉写了再改的模式对有些代码还是比较适用的，但那些反复使用的代码还是要学习相关知识在完成，否则日后修改会浪费时间，效率非常低。

原文地址