Morning@Weblog

Write the tests you wish you had. If you don’t, you will eventually break something while refactoring. Then you’ll get bad feelings about refactoring and stop doing it so much.

一种工具、技术，甚或是方法论，能否被大家广为接纳与传布，有两点至关重要：其一是自身简洁直观便于掌握，其二是恰如其分的方式方法。如果达不到前者，那么工具、技术、方法论的实际价值就值得怀疑。反之，则是个人认识与修为的欠缺，而不能盲目的一概否定。比如上面的反面教材，正是由于没有适时的引入测试，才致于对重构产生怀疑与恐惧，并最终止步不前，重回老路。而导致这一结果的真正原因恰在于错误的实践方式，并非重构之过。

很多时候，失败的软件过程实践往往就是因为团队成员觉得难于施行，在遇到一系列挫折之后，最终选择了放弃，甚至产生了偏见，即使他原本很想尝试新鲜事物。应该从上述两点来考察失败的原因。是方法论本身的问题，还是自身理解的偏差。

一件最近发生的让我很沮丧的事情：在我充分认识沟通的重要之后，却无奈于我与另一位同事的相隔距离十分的远（他的办公地点在与我们部门相对的另一个部门，分属两个办公场所，中间一条过道相隔），于是，我希望借助于远程桌面，但是对方的Win XP（SP2）操作系统似乎很顽固，致使我最终选择放弃。由此带来的影响，我估计沟通起码减少一半。

Kent Beck在他的TDD一书讲到有关TDD的“节奏”的问题：

The rhythm of test-driven development
1. Quickly add a test
2. Run all tests and see the new one fail
3. Make a little change
4. Run all tests and see them all succeed
5. Refactor to remove duplication

很喜欢rhythm这个词。实际上，如Kent所述，编写Test Case有如跳“韵律操”，节奏快慢全然在乎于自己的掌控。而对于节奏的把握，恰是因人而异的，即使同一个人于不同时段，亦有不同的表现。以往曾听人抱怨于TDD的“琐碎”：一个Money Example，就这么点内容，要分作这么多步序，要构筑一个大系统岂不累死人了。并且，这种夸张的“微观”行为难道不会影响实践者的“大局关”吗？难道不会使其偏题于千里之外吗？殊不知，Kent作为教练，在传授TDD技艺的时候，自然是要循循善诱的讲解分解动作的。但是作为实践者的我们，并非要拘泥于老师所教的“节奏”，所谓授人以渔，这才是老师的真正本意。何况Kent在书中不止一次的重申了这一点，看看下面这些散布于TDD中的零星陈述，是不是觉得软件的实现过程也很具“韵律”呢？

When everything is going smoothly and you know what to type, use Obvious Implementation—type in the real implementation. As soon as you get an unexpected red bar, back up, shift to Fake It—return a constant and gradually replace constants with variables until you have the real code. When confidence is back, go back to obvious implementations.

This is the kind of tuning you will be doing constantly with TDD. Are the teenytiny steps feeling restrictive? Take bigger steps. Are you feeling a little unsure? Take smaller steps. TDD is a steering process—a little this way, a little that way. There is no right step size, now and forever.

It is not necessary to work in such tiny steps as these. Once you’ve mastered TDD, you will be able to work in much bigger leaps of functionality between test cases. However, to master TDD you need to be able to work in such tiny steps when they are called for.

You will likely end up with about the same number of lines of test code as model code when TDDing. For TDD to make economic sense, either you will have to be able to write twice as many lines per day as before, or write half as many lines for the same functionality. You’ll have to measure and see what effect TDD has on your own practice. Be sure to factor debugging, integrating, and explaining time into your metrics, though.

我们通常所说的软件设计与开发过程，无论是top-down（自顶向下）还是bottom-up（自底向上），都是一种过于简单化的认识。由此产生的对TDD的错误认识也就变得可以理解了。关于这一点，Kent Beck在他的TDD一书中讲的非常透彻：

A program grown from tests can appear to be written top-down, because you can begin with a test that represents a simple case of the entire computation. A program grown from tests can also appear to be written bottom-up, because you start with small pieces and aggregate them larger and larger.

Neither top-down nor bottom-up really describes the process helpfully. First, a vertical metaphor is a simplistic visualization of how programs change over time. “Growth” implies a kind of self-similar feedback loop where the environment affects the program and the program affects the environment. Second, if we have to have a direction in our metaphor, “known-to-unknown” is a helpful description. Known-to-unknown implies that we have some knowledge and experience on which to draw, and that we expect to learn in the course of development. Put these two together and we have programs growing from known to unknown.

有关开发尽可能最简洁的J2EE架构的若干原则
- 没有充足的理由就不要使用分布式架构
- 没有充足的理由就不要使用EJB
- 不要自己动手开发复杂的底层设施，使用现成方案，比如开源方案
- 现在不要假设将来的事情，否则就会引发额外的开销和复杂度
- 花时间去领会你的业务需求，决定架构的是业务需求，而非技术平台
- 在提出复杂架构之前，用性能以及其他度量形式来为此寻找证据

(摘自J2EE Development Without EJB)

昨天看完了Robert Martin那本Agile Software Development的第六章。这一章讲述的是大师们的peer-programming实践，以一种非常写实的笔法对过程做了全程记录：设计、编写测试、实现代码、修改测试、重构代码……这些环节是经过多次迭代才得以完成的。设计中隐藏着错误，错误的讯号会反复出现，测试用例和代码是在思路的不段前进中逐步明晰与确定的。这是我第一次看到如此鲜活生动的例子，非常精彩的篇章。

对本章的结论我也颇有同感，并非到处都需要OOD，尤其对于简单的应用（又是over desgin的味道）。

更为重要的一点是，对UML的清醒认识。这段peer-programming经历中并没有完整的设计过程，从一点点简单的设计出发，首先开始的是测试用例的编写。

事情的结果告诉我们，UML图并不能避免我们在设计中犯错误，也不一定能帮助我们发现错误，即使有一套完善的序列图，错误也依然存在。也许更为糟糕的是，漂亮的UML图容易让我们盲目的坚定原来那些错误的观念和设计。同时，UML图也分散了我们的精力，极有可能导致设计的复杂性，滑向over design的危险边缘。

人非圣贤，就是大师级的R. C. Martine也不例外，唯有编码实践才最容易找到错误所在。通过画图来展开思路本没有错，但是在画完UML图示而又没有验证代码可循时，图示就是无益的，就是危险的。不能假定这种未经证实的设计是最好的。最好的设计是在编写测试，然后小幅前进的过程中逐渐形成的。这也就是测试先行的必要性所在。

上周末又去听了一回讲座（关于Web Service和Websphere的），大有上当的感觉。原定2个小时的内容，有将近一半的时间都在为某个培训机构作宣传，这真是一个糟糕的开场白，那时我正在下面翻看一本《程序员》杂志以示“抗议”。剩下的时间里，演讲者只有简单概述一下Web Service而已了，幸好草草收场，否则我就真的要坚持不住了——很不体面的打起瞌睡来。

唯一有些价值的东西都列在下面了，以表示我没有白去一趟： (more…)

Chapter 3 The Surgical Team

成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良后果（系统调试）。
千万不要忘记后半句话。

小型精干队伍对于真正意义上的大型系统而言，太慢了。就效率和概念完整性而言，最好由少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求
小型队伍开发大型系统，导致过长的开发周期，而软件是具有实效性的
(more…)

Chapter 2 The Mythical Man-Month

一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
这是一个观念的转变问题，在这个行业里“浸淫”的这几年，还好自己已经褪去那层“乐观”了

在单个的任务中，“一切都将运转正常”的假设在进度上具有可实现性。因为所遇到的延迟是一个概率分布曲线，“不会延迟”具有限定的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。
这段话有点罗嗦，简言之，任何事情只要一上规模，便会变得难于控制，这里所指的是时间可控性
(more…)

Chapter 1 The Tar Pit

有关Programming Product和Programming System的解释
不想对两者做过细的界定，一般的理解，很像是实际当中的产品开发和项目开发

有关编程这一职业的乐趣和苦恼的论述
引出了焦油坑的比喻，很有意思的比喻

Chapter 2 The Mythical Man-Month

Dorothy Sayers的《The Mind of the Maker》一书中，将创造性活动分为构思、实现、交流三个阶段。
交流实际隐含了创造者与使用者之间的反复交流过程，就像系统的反馈环节，必要的反馈使系统得以完善

对于创造者，只有在实现的过程中，才能发现我们构思的不完整性和不一致性
深有体会，不完整性和不一致性就像两对孪生兄弟般形影不离，几乎每个凡人都会在创造性劳动中同时犯下这两个错误。与其假意回避，不如坦然面对。