有病呻吟
[关于单元测试]
我曾经有试一些经历，越接近项目尾声的时候越感到焦虑不安。项目的结束更多时候是工期的结束，而产品则是一大坨代码的堆砌。我不清楚这样的代码是否可以经历起风雨，而当时最提心的事情莫过于客户提出的更改要求。因为那意味着动一而发全身的工程，调试的思路会非常混乱，你并不清楚哪些代码是可以信赖的。直到Kent Beck给我讲授的关于辘栌的故事。
在小时候，我姥姥家的家村见过这种东西，那个时候并没有自来水管的概念。如果谁家要吃水，需要到村口的水井去挑。水井很深，为了节省气力，大人们在转动的曲柄上安装了防止倒转的据齿。这样可以在提水的过程中稍做休息。
记住，代码的行进一定是一小步一小步的。每个人都希望大踏步的前进，但是不行。在我的一些培训课程中，常常会有一些学员对单元测试的内容提出异议。他们认为这种工作方式太慢了。他们希望在更短的时间内完成更多的代码。这样才会有效率。然而真正的效率并不是完成了多少代码。而是完成了多少有质量的代码。在我对众多项目的观察中发现，人们写代码的时间总是很快的。而更多的时间则是花费在了思考和调试上。
[关于开会]
所以，我总结了一套快速讨论，简单设计，代码实现，单元测试，重构，完善文档的开发流程。快速讨论的原因是针对国内项目组爱开会的毛病。其实爱开会是好事，但是我们的会议常常会走题。很可能从一个话题引申开去，在外面转了一大圈，发现跑题了，再绕回来。针对这种问题，可以采用站立式会议或者走廊会议的形式。因为站着，所以坚持不了多长时间，必须在最短的时间内把问题解决。我个人则常常在卫生间的时候和人讨论问题。在那种环境和空间下会非常的专注和易于思考。也可以在午饭的时候，快速而有效。如果非要找一个正式的场合，则可以借助一些工具。诸如MindManager，将本次会议的内容通过思维导图的形式规范出来。如果分支超过两层或者超过了预定的时间，马上结束。
[关于架构]
很多软件团队常常自觉不自觉的模仿建筑行业的施工过程。把一开始的想法展现在图纸上，然后对照着图纸进行讨论审核，将这些图纸作为编写代码的依据。我曾经不只一次被客户要求给他们讲解一些如何制作图纸的课程。人们习惯性地把其称之为软件工程。这其中最为典型的课程包括UML的课程里，80%的时间用来讲解ROSE的使用。而在软件工程的课程里大部分的时间用来分解文档的格式。这种垃圾性的课程非常符合中国人好大喜功的性格特点。所以这两年关于此方面的课程异常火爆。然而那些距离地面三千英尺的大师们忘了一件最为重要的事情，即相对于建筑行业，软件行业的需求并不是确定的，而是不断变更的。所以这种所谓的工程不可能适应软件行业。至少不可能像建筑工程一样实施。所以对于那些被称为架构设计的文档亦或是图纸是非常苍白无力的。而真正的架构是那些对最重要的问题做出解释的被用户认可的代码实现。我认为只有基于这种代码之上的结构体系才可以称之为架构。让那些对喋喋不休的真空架构师滚回到他们的星球吧。这个星球的人类需要氧气才可以生存。而我们的氧气是那些整洁可用的代码。
[关于UML]
我并不是建模的反对者。事实上我鼓励建模。但他们不是重点。真正的重点是功能的实现。UML主要用在简单设计之前的讨论上。他最大的展现地点在白板，而不是那些漂亮的文档，它的目的是为了沟通、整理思路。当然在完成代码实现之后将它们整理进文档用以后期的维护和阅读是个不错的习惯。这就像吃饭一样，对于我来说，吃饭最主要的功能是为了解决生存问题，然后才是其他的什么。因此，我对一直以来对我们在西餐厅使用筷子的行为投来怀疑眼光的绅士和太太们表示歉意。我实在无法将我的真实意图隐藏在华丽的包装之上。在我的需求中，生存的需求排列在任何需求之上。当然如果我解决了温饱问题，我是非常愿意和你探讨一下关于“左手拿刀，还是右手拿刀正确”的话题。我甚至会推荐在您用餐的过程中，右手的无名指上佩带一枚5K的钻戒会更加诱人。
我曾经有试一些经历，越接近项目尾声的时候越感到焦虑不安。项目的结束更多时候是工期的结束，而产品则是一大坨代码的堆砌。我不清楚这样的代码是否可以经历起风雨，而当时最提心的事情莫过于客户提出的更改要求。因为那意味着动一而发全身的工程，调试的思路会非常混乱，你并不清楚哪些代码是可以信赖的。直到Kent Beck给我讲授的关于辘栌的故事。
在小时候，我姥姥家的家村见过这种东西，那个时候并没有自来水管的概念。如果谁家要吃水，需要到村口的水井去挑。水井很深，为了节省气力，大人们在转动的曲柄上安装了防止倒转的据齿。这样可以在提水的过程中稍做休息。
记住，代码的行进一定是一小步一小步的。每个人都希望大踏步的前进，但是不行。在我的一些培训课程中，常常会有一些学员对单元测试的内容提出异议。他们认为这种工作方式太慢了。他们希望在更短的时间内完成更多的代码。这样才会有效率。然而真正的效率并不是完成了多少代码。而是完成了多少有质量的代码。在我对众多项目的观察中发现，人们写代码的时间总是很快的。而更多的时间则是花费在了思考和调试上。
[关于开会]
所以，我总结了一套快速讨论，简单设计，代码实现，单元测试，重构，完善文档的开发流程。快速讨论的原因是针对国内项目组爱开会的毛病。其实爱开会是好事，但是我们的会议常常会走题。很可能从一个话题引申开去，在外面转了一大圈，发现跑题了，再绕回来。针对这种问题，可以采用站立式会议或者走廊会议的形式。因为站着，所以坚持不了多长时间，必须在最短的时间内把问题解决。我个人则常常在卫生间的时候和人讨论问题。在那种环境和空间下会非常的专注和易于思考。也可以在午饭的时候，快速而有效。如果非要找一个正式的场合，则可以借助一些工具。诸如MindManager，将本次会议的内容通过思维导图的形式规范出来。如果分支超过两层或者超过了预定的时间，马上结束。
[关于架构]
很多软件团队常常自觉不自觉的模仿建筑行业的施工过程。把一开始的想法展现在图纸上，然后对照着图纸进行讨论审核，将这些图纸作为编写代码的依据。我曾经不只一次被客户要求给他们讲解一些如何制作图纸的课程。人们习惯性地把其称之为软件工程。这其中最为典型的课程包括UML的课程里，80%的时间用来讲解ROSE的使用。而在软件工程的课程里大部分的时间用来分解文档的格式。这种垃圾性的课程非常符合中国人好大喜功的性格特点。所以这两年关于此方面的课程异常火爆。然而那些距离地面三千英尺的大师们忘了一件最为重要的事情，即相对于建筑行业，软件行业的需求并不是确定的，而是不断变更的。所以这种所谓的工程不可能适应软件行业。至少不可能像建筑工程一样实施。所以对于那些被称为架构设计的文档亦或是图纸是非常苍白无力的。而真正的架构是那些对最重要的问题做出解释的被用户认可的代码实现。我认为只有基于这种代码之上的结构体系才可以称之为架构。让那些对喋喋不休的真空架构师滚回到他们的星球吧。这个星球的人类需要氧气才可以生存。而我们的氧气是那些整洁可用的代码。
[关于UML]
我并不是建模的反对者。事实上我鼓励建模。但他们不是重点。真正的重点是功能的实现。UML主要用在简单设计之前的讨论上。他最大的展现地点在白板，而不是那些漂亮的文档，它的目的是为了沟通、整理思路。当然在完成代码实现之后将它们整理进文档用以后期的维护和阅读是个不错的习惯。这就像吃饭一样，对于我来说，吃饭最主要的功能是为了解决生存问题，然后才是其他的什么。因此，我对一直以来对我们在西餐厅使用筷子的行为投来怀疑眼光的绅士和太太们表示歉意。我实在无法将我的真实意图隐藏在华丽的包装之上。在我的需求中，生存的需求排列在任何需求之上。当然如果我解决了温饱问题，我是非常愿意和你探讨一下关于“左手拿刀，还是右手拿刀正确”的话题。我甚至会推荐在您用餐的过程中，右手的无名指上佩带一枚5K的钻戒会更加诱人。
