|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-07-25
其实是一个问题。只不过那个关于注释的帖子被封掉了，我只能另开了。
|
| 返回顶楼 | |
|
发表时间：2004-07-26
凤舞凰扬 写道 首先，庄兄，我非常赞成通过变量和方法的重命名可以删除掉大量的多余注释，我也赞成尽量简洁的程序可以代替许多注释。我没有说，也从来不会说一个程序要堆砌大量的注释，我想楼上的几位朋友都是误解我了。我的意思是，注释是不能完全代替的，简单地讲，不可能什么程序都可以简洁到一看就明了的。注释有它存在的必要性，只是在使用它上面可以灵活。我很反对一些人，就自以为是的认为注释完全可以不要了，这纯粹是宣扬个人的一种情绪。
potain说，比如有些程序，我们可以指出书上说明的算法，没错，但是我想说，还有许多的程序根本就沒得算法给你提供，或者没有书籍给你提供，只有一种思路。这是你怎么引用？简单地讲，在许多最优算法中必须用到goto，只是多少的问题（我记得有一种，我说不出名字了，最少用到了9个goto），如果是你自己实现，也许存在更多。如果没有注释，单凭一个思路就能看懂程序？就能知道实现与思路是否真的符合？不至于吧。 我重视重构，我相信简洁明了的程序远胜于繁杂罗嗦的注释，但是，这并不意味着注释就可以完全被代替 A －－－ B －－－ C 甲从A往C走，乙从C往A走。他们相向而行，速度飞快。他们两人之间无法沟通，因此认为碰撞无法避免。旁观者也认为，他们快打起来了。而实际情况是，他们都打算也最终在B停下来了。大家虚惊一场。 看来如果大家走得慢点的话，可以减少很多误会。 |
| 返回顶楼 | |
|
发表时间：2004-07-26
其实我相信楼上很多朋友想法都是一致的，也只是希望凸显重构的重要，这点我赞成也理解。
不过正如庄表伟所说，走慢点，误会就少点。大家在着重宣扬一种东西的时候不要太显示地先贬死另外的东西，这样，会迎合某些人的主观而夸大它，从而给很多朋友产生误导， |
| 返回顶楼 | |
|
发表时间：2004-07-26
这话说得中肯。实际上，重构就像是呼吸，而注释就像是呼吸困难时的氧立得。很多注释在整个过程中是临时性的，只起到一个引领线索的作用。比如//todo ..... 这类的。尤其当你做了一个不完全的实现时，留下点注释还是非常重要的。不论是给自己看，还是给别人看。
|
| 返回顶楼 | |
|
发表时间：2004-07-27
看了这个帖子，我心情久久不能平静！
很多话我说不出口，只是想干嚎几声！ 你们每一个人的观点都是很有意义的，也是富于经验的，特别是chron，dlee,O6Z的帖子，简直是一语中的，感谢所有参与这个篇帖子讨论的人，感谢他们为我们奉上了关于TDD开发的见解！一鞠躬，二鞠躬！ 特别是O6Z其中一句话： 引用 实际上使用TDD的过程是这样的，先对程序要完成的任务制定一个类表；然后选择某种策略确定这个类表中功能的优先级别；对最优先的功能进行分析，转化为一个具体的测试程序；运行这个程序，应该会得到一个错误（但是确实存在某种可能你得到的是一个pass）；直接性的去使这个测试程序运行起来；重构使代码达到清晰而可工作。 其实它已经大概而且简明的道出了TDD的过程。但是太简明了可能很多人还是不清楚TDD在实际应用中的实施过程。我要从O6Z的这个概括抽丝剥卷般细细说开来！ ”先对程序要完成的任务制定一个类表“：TDD与OOD一样同样是建立在对业务用例的详细分析基础上，针对每一个核心用例，我们一一分析，分析过程中我们会得出一些类表，这些类表一般是核心领域模型，随着用例分析的深入，这个核心领域模型的架构会逐渐完整，层次逐渐形成，但在分析用例的过程中，这是复杂而且关键的过程，我们往往会在分析到后面的用例时推翻前面所建立的核心领域模型（这也可以叫做分析重构吧），直到分析完最后一个核心用例，整个领域模型已经初步完善。 “对最优先的功能进行分析，转化为一个具体的测试程序” ：上一步完成之后，我们的领域架构已经形成，接下来，我就要以用例实现为原则 以领域模型为中心进行正式的TDD开发。针对每一个核心用例，我们都可以用一个TDD来完整定义它，注意这个“定义”，我们在TDD中的所有asert必须完整而明确的定义用例完成的状态，而不仅仅是一部分状态。 “直接性的去使这个测试程序运行起来”：接着就是针对测试以及遵循我们已经确立的核心领域架构原则，直接实现测试。说白了就是编写实现代码。为了能够准确的编写，一般我们需要一个静态模型和动态模型加以指导我们的代码编写。这也是OOD的概念吧！ “重构使代码达到清晰而可工作”：这个就不用说了，但是我想还需要补充一点，在编码时，可能我们针对测试的失败，还要重构我们的UML模型，因为直到测试失败，我们才可能发现一些不易被发现的设计失误，从这点上来说，TDD确实是在尽力使得OO模型实现功能需求。 |
| 返回顶楼 | |
|
发表时间：2005-01-16
firebody 写道 看了这个帖子，我心情久久不能平静！
很多话我说不出口，只是想干嚎几声！ 你们每一个人的观点都是很有意义的，也是富于经验的，特别是chron，dlee,O6Z的帖子，简直是一语中的，感谢所有参与这个篇帖子讨论的人，感谢他们为我们奉上了关于TDD开发的见解！一鞠躬，二鞠躬！ 特别是O6Z其中一句话： 其实它已经大概而且简明的道出了TDD的过程。但是太简明了可能很多人还是不清楚TDD在实际应用中的实施过程。我要从O6Z的这个概括抽丝剥卷般细细说开来！ ”先对程序要完成的任务制定一个类表“：TDD与OOD一样同样是建立在对业务用例的详细分析基础上，针对每一个核心用例，我们一一分析，分析过程中我们会得出一些类表，这些类表一般是核心领域模型，随着用例分析的深入，这个核心领域模型的架构会逐渐完整，层次逐渐形成，但在分析用例的过程中，这是复杂而且关键的过程，我们往往会在分析到后面的用例时推翻前面所建立的核心领域模型（这也可以叫做分析重构吧），直到分析完最后一个核心用例，整个领域模型已经初步完善。 “对最优先的功能进行分析，转化为一个具体的测试程序” ：上一步完成之后，我们的领域架构已经形成，接下来，我就要以用例实现为原则 以领域模型为中心进行正式的TDD开发。针对每一个核心用例，我们都可以用一个TDD来完整定义它，注意这个“定义”，我们在TDD中的所有asert必须完整而明确的定义用例完成的状态，而不仅仅是一部分状态。 “直接性的去使这个测试程序运行起来”：接着就是针对测试以及遵循我们已经确立的核心领域架构原则，直接实现测试。说白了就是编写实现代码。为了能够准确的编写，一般我们需要一个静态模型和动态模型加以指导我们的代码编写。这也是OOD的概念吧！ “重构使代码达到清晰而可工作”：这个就不用说了，但是我想还需要补充一点，在编码时，可能我们针对测试的失败，还要重构我们的UML模型，因为直到测试失败，我们才可能发现一些不易被发现的设计失误，从这点上来说，TDD确实是在尽力使得OO模型实现功能需求。 不好意思把这么老的帖子翻出来。 但是，这里有几个问题，我觉得需要明确一下， 1. 上面描述的整个流程，我怎么看着和重型方法没有太大的区别。尤其是这个"整个领域模型已经初步完善" 2. "针对每一个核心用例，我们都可以用一个TDD来完整定义它"这句话和"直接性的去使这个测试程序运行起来"放在一起，却没有下文，看起来怎么像是先写完了该用例的完整测试，然后再写代码？ 这背离了TDD的做法。 实际上，测试程序和被测试者是互相共同生长起来的，所以并不存在"对最优先的功能进行分析，转化为一个具体的测试程序"这样一个过程，当你针对某个功能得到一个具体的而又"相对完整"的测试程序的时候，离得到相应的实现代码也就应该只是几分钟到十几分钟之遥。 TDD强调的是短促反馈的螺旋，对功能的分析反倒是粗粒度的。 |
| 返回顶楼 | |
|
发表时间：2005-01-17
firebody 写道 看了这个帖子，我心情久久不能平静！
很多话我说不出口，只是想干嚎几声！ 你们每一个人的观点都是很有意义的，也是富于经验的，特别是chron，dlee,O6Z的帖子，简直是一语中的，感谢所有参与这个篇帖子讨论的人，感谢他们为我们奉上了关于TDD开发的见解！一鞠躬，二鞠躬！ 特别是O6Z其中一句话： 引用 实际上使用TDD的过程是这样的，先对程序要完成的任务制定一个类表；然后选择某种策略确定这个类表中功能的优先级别；对最优先的功能进行分析，转化为一个具体的测试程序；运行这个程序，应该会得到一个错误（但是确实存在某种可能你得到的是一个pass）；直接性的去使这个测试程序运行起来；重构使代码达到清晰而可工作。 其实它已经大概而且简明的道出了TDD的过程。但是太简明了可能很多人还是不清楚TDD在实际应用中的实施过程。我要从O6Z的这个概括抽丝剥卷般细细说开来！ ”先对程序要完成的任务制定一个类表“：TDD与OOD一样同样是建立在对业务用例的详细分析基础上，针对每一个核心用例，我们一一分析，分析过程中我们会得出一些类表，这些类表一般是核心领域模型，随着用例分析的深入，这个核心领域模型的架构会逐渐完整，层次逐渐形成，但在分析用例的过程中，这是复杂而且关键的过程，我们往往会在分析到后面的用例时推翻前面所建立的核心领域模型（这也可以叫做分析重构吧），直到分析完最后一个核心用例，整个领域模型已经初步完善。 “对最优先的功能进行分析，转化为一个具体的测试程序” ：上一步完成之后，我们的领域架构已经形成，接下来，我就要以用例实现为原则 以领域模型为中心进行正式的TDD开发。针对每一个核心用例，我们都可以用一个TDD来完整定义它，注意这个“定义”，我们在TDD中的所有asert必须完整而明确的定义用例完成的状态，而不仅仅是一部分状态。 “直接性的去使这个测试程序运行起来”：接着就是针对测试以及遵循我们已经确立的核心领域架构原则，直接实现测试。说白了就是编写实现代码。为了能够准确的编写，一般我们需要一个静态模型和动态模型加以指导我们的代码编写。这也是OOD的概念吧！ “重构使代码达到清晰而可工作”：这个就不用说了，但是我想还需要补充一点，在编码时，可能我们针对测试的失败，还要重构我们的UML模型，因为直到测试失败，我们才可能发现一些不易被发现的设计失误，从这点上来说，TDD确实是在尽力使得OO模型实现功能需求。 我不太明白什么叫做分析重构？ 比如说，领域模型是一次由分析就可以基线化，还是要经过一次次迭代来实现领域模型的一部分？ 中间是怎么处理迭代的？ 我想应该是这样来的： 分析－测试代码实现－产品代码实现－客户验证，来实现领域模型的一部分，也就是一次迭代。 要不然，整个是需求分析－设计－实现－验证的开发过程，只是在设计和实现这两个阶段做短迭代。 如果说Working Software Over Comprensive documentation 我觉得应该是前者更敏捷一些。 |
| 返回顶楼 | |
|
发表时间：2005-04-30
因为一个BLOG的文章，来到这个帖，读了大家的争论。
关于TDD和XP的观点，在Bob 大叔的那本经典的书里已经讲得很透了，但很明显每个人的理解却又各不相同，这大都是由于自己的项目经验各不相同所决定的。建议大家去看看Bob的书吧，里面的东东很有营养，总胜过在这里似是而非的争论。 |
| 返回顶楼 | |
|
发表时间：2005-04-30
为什么bob的话就不是似是而非的。至于什么是TDD和XP的"准确"定义，我看未必那么重要。
|
| 返回顶楼 | |
|
发表时间：2005-05-08
canonical 写道 为什么bob的话就不是似是而非的。至于什么是TDD和XP的"准确"定义，我看未必那么重要。
很简单，因为BOB有很多年的开发经验，而且他成功了，并且他的著作得到了开发界的承认。 |
| 返回顶楼 | |
