On the Open Way

今年年末，回首过去，心里七上八下的。

首先感觉时间过的真快，不知道何以人生走完了2004年。一如既往的迷茫。

自从上了小学，就上了中学，接着是高中，然后是大学。在这一路上纵然是多姿多彩的。每一关口都不需
要我多少思虑抉择，好像人生的路就那么一条。大学毕业了，接着就是工作了，如今已经工作了一年半了。
这一切似乎自然而然的事情，不见我之力我之思改变了自己多少。当我们回首，又有多少刻骨铭心呢？心
情激动的时候我可以一件一件的数来，或许另外一个时刻我又去数落其他的事情。

随着10月份以来，烦躁的心绪越来越频繁，足以说明我无法很好的调节自己的心里。看来10月份是一年心
情的转折点，至少以后在9，10月份好好的轻松一下，疏解一下一年中的心情。
越来越发现自己的缺点太多太多了，就好像过程改进一样，在年末看到自己缩影的一部分。如果有人愿意
给我一些建议，简直是太好了。

在过去的学习中，很少做笔记，又少于记录心得。致使只见表皮，不见精髓的惯病。

缺乏与人交流，+深层次的交流。

接受新的思想比较少，吸收东西的能力亟需提高。

缺乏和人合作，现在不晓得如何和人合作。

知识支离破碎，没有形成自己的思维体系。

对软件开发本身认识甚少。

全局观很是浅薄。

想读的书很多，每一天安排在读书上的时间很少。

想读还没有读的书：
《计算机程序的解释与构造》
《UML与模式应用》
《Contributing to Eclipse》
《软件工艺》
《设计模式》
《测试驱动开发——实用指南》

"你必须习惯于一天用六个小时读代码，再用一个小时写代码－－你会发现这样的一天效率同样高得惊人。"
                                                   ----《Contributing to Eclipse》前言
"读书不二。一书未完，不看他书。东翻西阅，徒务外为人。"
"总要养得有胸次博大活泼，此后更当有长进也。"
                                                   ----曾国藩
知难行更难。

学名：Hemerocallis citrina Baroni
英文名：Citron Daylily
科名：百合科 Liliaceae 
    根常稍肥厚或末端膨大。基生叶深绿色，宽线形，通常宽l－2厘米或更宽，

较花茎短。花茎高1—2米；螺壳状聚伞花序排成圆锥状，花朵达几十朵，花午

后开放，次日午前凋萎，黄色，芳香，长8—16厘米；花被管长3—5厘米，外轮

裂片倒被针形，内轮长椭圆形。蒴果椭圆形，长约2．5厘米。花期8—10月。   

    产本省各地，野生山坡、山谷草丛中，也有栽培；分布我国秦岭以南各省

区，北方也有栽培。

    花供食用；根有毒性，可作杀虫剂。

http://download.eclipse.org/tools/emf/scripts/downloads-build-types.php

1.Releases
  Releases是由开发团队公开发布的主要build版本，比如："R1.0"。
  这种builds是稳定的(stable)、经过测试的版本(tested release),但是它不会包含最近最
新的features和improvements。
  Release Builds的版本号总是以"R"开头；Non-release builds一般都是build的日期来命名。
2.Stable Builds
  Stable builds是能够确定满足大部分用户的integration builds版本（注：Stable builds首先是一个
integration builds,并有很好的稳定性，满足用户的基本需求）。经过短期的使用和评估（或者评审）
由architecture team把stable build从integration build中提取出来（原文：They are promoted from
integration build to stable build by the architecture team after they have been used for a
few days and deemed reasonably stable. ）。
  这种builds会紧紧跟随最新的开发进程，包含最新最新的features和bug fixes,当然同时可能会由许多
bug和缺陷。
  开发团队希望能够发布这种builds来获取用户及时有价值的反馈。
3.Integration Builds
  这是一个周期性的工作，各个component teams保证释放的component都处在了稳定、具有兼容性的状态。
每一个compenent必须在配置文件中配置下一次integration build中本component的版本号。在新的稳定
component版本release到build中，必须要进行build integration builds.Integration builds经过测试
之后就会成为Stable Builds.
4.Nightly Builds
  over night build任何被release到the HEAD stream of the CVS repository的代码。
  完全没有经过测试，存在大量的问题；一般情况下都不会很好的运行。
  这一步为改项目的开发者而是实现的。
  Note: Nightly builds are produced only as requested, and not necessarily every night,
by developers to build what was in HEAD.
5.Maintenance Builds
  周期性的build,为了保持维护未来版本的发布的执行。Maintenance Builds并不一定是一个stable builds.
maintenance builds最后确定和release的时候，就成为了一个Release build.Maintenance builds的名字以
"M"开头，在稳定性方面仍然没有经过考验。如果一个版本是release candidate的时候（“RC”），那么
就是一个stable maintenance build.

接受测试驱动开发也已经有些时光了，仍然只能依靠ide来创建一些测试对象，即使偶尔自己写几个测试用例，也是环境相关、依赖多多的实例，为什么我们的代码就需要单元测试呢，部分是自己的想法，部分是与几个朋友讨论收获的，浏览了<<Junit In Action>>之后不免想记录下自己的想法了。

  自从有了代码就有了单元测试，就是最简单的debug调试也算作单元测试的一部分吧；测试驱动开发是在单元测试滞后产生的一种软件开发的方法学。只要有单元测试，它本身就含有驱动软件设计和代码重构的思想在里面。我们为了代码能够被单元测试，在设计阶段我们就会考虑怎么测试代码，同时测试用例也是代码的第一个用户；我们也需要为了测试了对代码进行重构。

1.单元测试的验证性：任何代码都是有一定缺陷的，单元测试能够尽量的发现代码中的问题和缺陷，验证了设计、业务逻辑、一些相关的特殊领域对象（一些Javabean等），保证了代码的完整性。从功能上对代码进行了验证，至少证明代码不存在功能上的问题。

2.单元测试的探索性：对于单元测试同样我们首先有一个测试列表，这个测试列表精心设计和长期习惯的积累，可能它就存在你的脑子里面。对于列表中的测试点，我们只测试可能出错的点；象那些不依赖于环境能够被间接的测试的点我们没有必要一定去测试。对于那些必要的测试点中，同样有业务逻辑的测试、模拟异常条件测试、对于预期的测试，需要我们良好的设计来实现它。在这个测试列表之外的是为测试区域，我记得哲学上有一个道理，一个圆越大，那么它与未知世界接触的区域就大。我们是不是也在做这种用例呢？单元测试就是尽可能保证我们所知道的每一个区域是“安全”的。

3.单元测试促使设计:

代码==è单元测试==è重构==è单元测试回归

首先我们对于代码进行单元测试，无论代码如何，设计如何，要保证现在代码是能够被单元测试的，这时候代码遇到了它的第一个用户：单元测试。代码如何被测试，考验代码的适应性和对变化的承受力。只有不断的重构才能使得测试更简洁。这里需要我们对于代码的重构设计成竹在胸，23个设计模式是不可或缺的方法。

4.测试用力是代码的使用手册：代码如何使用，可能客户不能很快知晓，测试用例就是一个demo,只要客户按着测试用例一样使用我们的代码，保证我们的代码一定能够被正确的使用。

4.单元测试的回归性：测试过的代码、功能等，不能证明随着时间的推移，在频繁构建之下，永远是好的。回归测试保证了在当前的测试用例之下当前的代码的良好性，是一张代码质量的协约书。谁都能“误”以为代码满足了编写者的设计意图。如果代码不能通过单元测试了，可能就是被损坏了。保证了重构中系统的完整性和一致性，随着代码的不断递增，通过机器自动保证代码测试无需人来参加。

5.防止衰退，减少调试：利用测试的回归性来进行代码的衰退，使得自动测试必须存在，他是我们代码的“守护神”（如果你也想为你的代码增加一个神，就从单元测试开始吧）。在代码、测试、重构的过程中，也是不断调试程序的过程，良好的单元测试能帮助我们发现错误和定位错误，逻辑单元测试本身就是一个细粒度的测试。

6.团队协作的可能：在一个团队，成员之间是互相信任的。我们通过什么来保证代码的可信任，单元测试让我们的代码是可以依赖的。有了单元测试的习惯，你不会在代码没有测试之前就提交它。模块之上的功能测试也是很粗糙的，对于代码的逻辑和集成性还是心有余而力不足。

突然想到，单元测试存在一块充满地雷的区域上的排雷器一样。我们验证什么地方有雷，什么地方没有；我们探索那些未知的区域；通过不断的排雷来评估这个区域的安全性；利用回归的探测来证明有没有新地雷扔到已测地区。

有一段时间一直在想，什么样子的代码是一个好的代码、高质量的代码，这些是在福建的时候写的，已经过去有一些日子了。想到那些日子里，承担者项目上的一些压力，工作之间

依然在思考代码，依然在读 软件敏捷开发 这本书。

软件设计的最终体现为源代码，满足设计标准的唯一软件文档就是源代码清单。源代码就是设计。具有灵活性、可维护性和可重用性的良好架构设计会带来高质量的代码，高质量的代码必然有良好的架构设计。

如何衡量软件的好坏呢？

僵化性(Rigidity):关联的地方太多，难以改动；实际发生改动之后，许多因改动带来的影响自己难以预测到，往往需要在庞大的代码中搜寻变动。

脆弱性(Fragility):关联了概念无关的地方，出现新问题的地方与改动的地方没有概念上的关联。

牢固性(Immobility):系统重能够被重用的地方难以抽取出来，需要巨大的努力和风险。

粘滞性(Viscosity):包括软件的粘滞性和环境的粘滞性。软件的粘滞性发生在保持系统设计的改动方法比那些破坏设计的生硬改动手法更难应用时；环境的粘滞性发生在环境迟钝、低效时，比如导致大规模重编译的改动或者需要几个小时check in几个文件中的改动。

不必要的复杂性(Needless Complexity):代码中预置的那些处理潜在变化的代码，致使设计中含有绝不会用到的结构。

不必要的重复性(Needless Repetition):开发人员忽视了抽象，对于系统的改动开始变得困难起来。

晦涩性(Opacity):模块难以理解。用清晰、富有表现力的方式编写代码。

                                     ――――读<<Agile Software Development>>

这些都是软件在腐化的臭味道，软件的腐化是由代码来表现出来的。现在我对于代码的理解：

可读性：代码不仅是给用户写的，也是给team成员读，（对我们而言，还要给维护人员读）。只有代码具有可读性，才能具有好的可维护性、才能被复用。读好的代码能提高，读不好的代码也能发现问题。通过代码评审来提高团队的代码质量是一种非常有效的方式，能够直接影响了设计。

可测试性：测试用例是代码的第一个用户，如果代码难以测试，可以说是很难用，就更难复用。

复用性：保持代码的抽象性，代码能写到没有一点能让自己copy的地方只是第一步。如果我们自己设计的代码自己都不能进行复用，还谈什么系统复用，还谈什么提高复用性。我们不能等有一个万能的复用框架别人做好给我们使用，我们应该从建立自己的复用库开始，可以建立自己的CVS（CVSNT）来管理自己的源代码库。（在不断抽象之下，就是分析的结果，一般一个包的抽象类有50%左右的时候这个包是最稳定的。）

可维护性：代码要有好的复用性，必须有良好的架构，易读，易于测试，对于改动灵活。程序在运行中不可能不遇到各种各样的问题，对于我们的项目可能是对于现场运行环境的细小的变更，可能会是运行中的性能的问题？会不会导致系统的崩溃呢？能够提供观察系统运行状态的良好的接口，能够提供分析系统异常信息的合理的结构。当系统出现异常的时候，我们不希望系统立刻就会崩溃，我们不希望只是看到异常。