tdd,设计模式,重构在软件开发中的概念和角色辨析

 

    最近匆匆看了些书，有一些感想，拿出来给大家分享下。   

    分享什么？看到的这些概念，以及概念之间的关系。

    希望呢？大家看看有没有剑走偏锋，指正一下。

    因为看的不是一类书，所以会去辨析他们的角色和作用。

    tdd解析的是tdd的实践。重构解析的是重构(废话)。effective java讲的是语言级层面。极限编程概念，模式，方法和实践讲的就更杂了，什么都有。

    一辨析，问题就来了。作者们都是大师，为什么会去造出这么些教科书没有的概念(重构，tdd)。他们之间到底啥关系?

    更大的问题是，我只是一个小兵，只能去思考思考第二个问题。第一个问题，只能以后慢慢想。

    对于第二个问题，我的回答是,一,初期设计用架构模式和设计模式,二,模块开发和类开发用tdd,三,tdd实践过程中以及后期设计变更时候用重构。

    下面一个个解释下。

    请注意，这里三句话，基本上是我的理解，可能是胡话，所以请大家能指正。而下面的解释是胡话连篇，所以更要擦亮眼睛，不要被我误导了，必要时候指导下我。

    一:初期设计用架构模式和设计模式

    先说说架构模式和设计模式关系。

    架构模式是什么？以tcp/ip为典型的分层,以浏览器应用为典型的b/s(对应的c/s),以spring为例的mvc等。

    设计模式是什么?大家常用的单例等。

    他们之间啥关系？基本上架构模式没什么新的东西，每个架构模式是几个设计模式的合起来用的结果。基本上各种框架都是架构模式的体现.

    那为什么初期设计用架构模式和设计模式？tdd不是教给我们拿着枪直接上战场，写好第一个case直接开始干么？tdd不是教给我们接受变化么，甚至制造变化么？

    我觉得，如果那样，项目后期一定很痛苦，因为连顶层设计都要经常变更的话，谁受得了？

    如果连这个都受得了，干脆重写好了。

    所以初期设计，顶层设计很重要，最好靠谱点。

    什么最靠谱?架构模式和设计模式。

    为什么最靠谱？

    因为都是大师和大侠们实践总结而来，千锤百炼，不用怀疑。

    二:模块开发和类开发用tdd

    tdd的目标就是最快速，最高质量实现功能，还改善设计，应对变化。

    最快速，最高质量实现功能，就是每个功能点映射为testcase,让每个testcase通过。这就是tdd实践的第一阶段。

    改善设计就是在功能完成之后，用重构消除重复设计，使得代码最少，最简洁。这就是tdd实践的第二阶段。(第一阶段和第二阶段应该截然分开，不要混在一块)

    应对变化，第一阶段和第二阶段的一个重新的过程。所不同的是，这回工作的前提是，已经有了一些case,变化的时候，必须保证这些case通过，或者删除其中一些不必要的。

    周而复始，应对变化。

    可以看到，tdd应对变化的哲学，并不是通过设计的完美来保证。设计之前，哪里知道有那么多变化？用户永远会提出各种各种的新功能，打乱以前的设计。

    tdd应对变化，是通过代码已经对代码的验证-testcase来保证。

    

    tdd有用么？非常有用。

    为什么?因为它只是新造的名词，它只是一个称呼，然后大师把他们平常积累的宝贵经验和原则都往里面装，装完了就说这叫tdd。

    虽然有用，但是受限，仅限于模块开发和类开发。

    它这么流行，我觉得最大的原因是，装载里面的有两件很重要的东西(一)xunit(二)质量控制。

    xunit,纯工具,但是因为tdd,不再是代码的验证工具，而进化为代码的设计工具。

    xunit不就代表着质量控制么？为什么需要单独列出质量控制?

    我其实不想说质量控制，我更想说的是进度控制。但是这两者在我看来，几乎是一个概念，所以就叫质量控制吧。

    应对变化，并不是对未来的变化了如指掌，而是对自己已经写好的东西了如指掌。只有这样，才能应对变化，而tdd让你更加明白自己的代码在干什么。

    每写一个case，就是对自己代码一个认识的过程。每一个case,也是对代码积累信心的过程。

    

    三:tdd实践过程以及后期设计变更用重构

    花6，70块钱买下重构这本书的时候，我甚至都后悔死了。

    开始感觉一堆模式，没啥深度，作者在堆砌书的厚度，在糊弄我。

    慢慢看着，看法改变了:这是有深刻的道理在里面的。

    重构的目标是什么？tdd的开发已经实现了功能，重构是用来改善设计的。也就是说，其实代码功能已经成形了，你要做的是使得它变得完美。

    既然已经成型，也就是说，一眼就可以看出来的大的缺陷，是很少的。

    有一些一眼可以看到的缺陷，就是一个函数名的替换，让它更贴近功能；一个方法的抽象，让代码更易懂。

    类似这些细节动作，比其他翻天覆地的设计变化，此时来得更加实用。

    但是我们总期望用翻天覆地的变化来让代码更加完美啊，重构能达到么？

    能！！

    重构的高级进阶，就是运用设计模式知识，重新设计。如果代码内部的细节，已经足够完美，这种所谓的翻天覆地，也不觉得翻天覆地了。

    从细节做起！！！

    除了在tdd开发过程能用上重构，重构还有一个重要战场。

    那就是，代码成形之后，外部用户添加或更改更能的时候，需要重构。

    这就意味着，不要在用户变更功能的时候，不要去想着"维护"代码，而是改进代码，重构代码！！不要放过这样的机会，否则，代码会慢慢腐烂。

    但是，每次都重构，这是需要底气的，来自哪里？

    tdd所累积的testcase!!!

    所以我们看到，重构，tdd，设计模式是有内在联系。

    最后一点感受:代码模式

    设计模式，架构模式，重构模式，一堆模式。

    大师们老是喜欢用一堆的模式来增加书的厚度。但是，给我最大启发确是最薄的tdd by example，虽然里面也一堆模式。

    所以我认为，模式很重要，模式后面的哲学，也就是为什么这么做，什么时候这么做，社么时候不这么做，才是最重要的。

    有那么多的模式，那么effective java这样的书籍说的是属于哪个模式？

    她也是模式，叫做代码模式。

    实现一个小功能，有无数种方式，哪种方式最好？主流的最好。主流意味着大家都能看懂。写机器能看懂的代码，都会，难的是写人能看懂的代码，还不用注释。

    说白了，没有牛人设计，如果每行代码都很地道，我想这样的程序仍然很牛。

    因为本来就无所谓设计，逻辑那么多，23个设计模式哪能概括得了？？？

    所以我想说的是:模式不重要，重要的是概念；概念很简单，重要的是实践；实践有很多，重要的是做细节。

    设计随处可在。每一行代码都是设计。

    成功孕育在每行代码里。而不是在设计里。

    高质量代码的累计起来，可以改变糟糕的设计。