|
锁定老帖子 主题：目前项目的暴强代码风格 + 把它重构了！
精华帖 (0) :: 良好帖 (31) :: 灌水帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-12-17
gigix 写道 下一站，火星 写道 但对于自主研发型项目呢？很多东西是一开始我就知道大概做什么东西了，我觉得采取利用测试用例收集需求是不是有脱裤子放屁的嫌疑？
有时间写含混不清无法确保同步的设计文档，没时间写测试用例 顺便回答前面那位不理解医生的比喻： 我只是告诉你怎么做会有好处，你去不去做是你自己的事，你身体好不好跟我一毛钱关系都没有 嘿嘿，我有点明白了…… 既然文档很难维护，这个也确实，，那么测试用例好维护不？你能否说点这方面的心得？ |
| 返回顶楼 | |
|
发表时间：2008-12-17
下一站，火星 写道 嘿嘿，我有点明白了……
既然文档很难维护，这个也确实，，那么测试用例好维护不？你能否说点这方面的心得？ 首先你要明确，这是一件本来就应该去做的事 人们应该确保设计文档与实现同步，只不过大多数情况下人们没有这样做 至于具体怎么维护，很简单 先改测试，描述你希望修改后的业务逻辑是什么样，再改实现 |
| 返回顶楼 | |
|
发表时间：2008-12-17
gigix 写道 下一站，火星 写道 嘿嘿，我有点明白了……
既然文档很难维护，这个也确实，，那么测试用例好维护不？你能否说点这方面的心得？ 首先你要明确，这是一件本来就应该去做的事 人们应该确保设计文档与实现同步，只不过大多数情况下人们没有这样做 至于具体怎么维护，很简单 先改测试，描述你希望修改后的业务逻辑是什么样，再改实现 thks，测试驱动是个路子，不过我打算半TDD半妥协，纯TDD对程序员的要求还是太高了。 |
| 返回顶楼 | |
|
发表时间：2008-12-17
gigix 写道 下一站，火星 写道 gigix 写道 我的实践是，任何超过三行或者两个分支的代码片段都应该被测试
请教一个经验吧，覆盖率到多少才叫基本讲的过去？ 我所见过的代码段基本都在3行以上  这里的思路是：超过3行或者2个逻辑分支的代码片段就是有可能出错的，因此它应该被测试 所以针对符合此条件的代码，测试覆盖率应该是100%，除非你有绝对充分的理由 如果你是从一个已有代码库开始，那么至少应该保证新写的代码符合此条件的达到100%测试覆盖，并且旧代码的测试覆盖率逐步上升、永不下降 和所有的原则一样，这些原则也是可以妥协的 采用这样严格的原则，只是为了让自己不要妥协得那么容易 gigix表跑，问一下，100%的覆盖率是算出来的？用专业工具检测的？还是每个函数都测到就可以？ |
| 返回顶楼 | |
|
发表时间：2008-12-17
hurricane1026 写道 gigix表跑，问一下，100%的覆盖率是算出来的？用专业工具检测的？还是每个函数都测到就可以？
Java用Cobertura，Ruby用rcov，你试一下就明白了 |
| 返回顶楼 | |
|
发表时间：2008-12-17
顺便问一下，每一个参数是否从上限测至下限以防意外...
|
| 返回顶楼 | |
|
发表时间：2008-12-17
最后修改：2008-12-17
ray_linn 写道 顺便问一下，每一个参数是否从上限测至下限以防意外...
再说一遍 单元测试是在描述你想做的事，而不是防止出错 TDD是设计手段，测试只是顺带的收获 它只是确保你做的和你设计的一样 不确保你做的（以及你设计的）不出错 顺便说一下 没有设计到的东西希望靠测试来防意外，我认为这是个很不靠谱的想法 没有设计到的就是undefined，它恰好能工作或者它恰好不能工作，它都是undefined 为什么说测试就是文档？ 只有测试描述到的才是程序可靠的行为 测试没有描述到的都是undefined |
| 返回顶楼 | |
|
发表时间：2008-12-17
最后修改：2008-12-17
gigix 写道 ray_linn 写道 顺便问一下，每一个参数是否从上限测至下限以防意外...
再说一遍 单元测试是在描述你想做的事，而不是防止出错 TDD是设计手段，测试只是顺带的收获 它只是确保你做的和你设计的一样 不确保你做的（以及你设计的）不出错 ms有点点明白 俺要的属哪块？功能测试？ 说实话，我一直重功能测试，轻单元测试的。 |
| 返回顶楼 | |
|
发表时间：2008-12-17
gigix 写道 庄表伟 写道 我认为，重构中，最重要的一项是：“命名”。修改函数的名称，修改变量的名称，抽取函数、分解函数后，同样需要给新的函数命名。
不理解程序，你如何命名？ 如果重构的目的，仅仅是为了保持代码的行为不变，当然只需要考虑“形式化的过程”。 我很理解你会这样说，因为你并没有在一个完全不熟悉的、超级复杂的系统里去专门做重构──大多数人做的大多数重构，都是与自己的开发实践结合在一起的，这固然是很正常的，但是也决定了大多数人缺乏机会去专门思考重构本身的技术实践。 简单的说，在你重构的过程中，你就逐渐理解原来的程序了。 这才使得重构成为一个可操作的实践。否则你就会遇到一个两难境地：你要先理解原来程序才重构，但最需要重构的程序是你无法理解的。 我本来的思路是：“把程序，重构到能够理解” 你的做法是：“在重构中，实现对程序的理解” 你说的“在一个完全不熟悉的、超级复杂的系统里去专门做重构”，的确是一个非常独特的经验。大多数人，都是重构自己，最多是同事的代码。 打扫飓风过后的灾区，这种事情，实在是太罕见了。 对你干活的那种脏活累活，深表同情。 希望有机会你能够系统的写一些“专门思考重构本身的技术实践”。 |
| 返回顶楼 | |
|
发表时间：2008-12-17
gigix 写道 hurricane1026 写道 gigix表跑，问一下，100%的覆盖率是算出来的？用专业工具检测的？还是每个函数都测到就可以？
Java用Cobertura，Ruby用rcov，你试一下就明白了 比如在catch 块里面对数据库异常进行捕捉，code coverage能覆盖到这块代码么？覆盖不到，怎么可能做到100%，我真的挺疑惑的，我用过其他的code coverage 工具到80%都难。 |
| 返回顶楼 | |
