敏捷之无题(代码难写就该难读？)

一步行动，胜过万千专家的意见。

                                               ——Bill Nye

         我想干嘛，我要干嘛，我准备干嘛，要是怎么怎么就好了，我说够了这种话，当你觉得时间已经不够了的时候，其实刚好是最佳的时候。我很欣赏这句话，希望以后我能多说我正在干什么。

        在敏捷开发中也是这样，我们不停的给用户描述，我们将要做的东西是什么，其实有一句搜索引擎领域很经典的话，说的用户并不知道他们想要什么，除非他们看到他们想要的东西，这句话在很多地方都适用。而敏捷开发的一个很重要的原则是，短迭代，增量开发。我们需要不停的进行迭代，然后从客户那里得到反馈，然后再迭代。如此，推进整个项目的进行。这里提到的是用户的反馈，而用户的反馈更多的需求层面的变动。其实在程序开发过程中，最多的反馈，是由代码本身提供的，常见的由模块的单元测试，整个程序的运行，等等都能提供各种反馈，这些反馈告诉我们模块是否正确，程序是否正常。这些由程序本身提供的反馈，其实是我们能获得的最频繁的反馈。

        一种观点是，使用自动验收测试，来保证程序的正确性，即把所有的单元测试工作都自动化，一种更进一步的方法是，测试驱动开发，意思是说，我们先写测试代码，然后再写具体的实现代码。当然见仁见智。

        另外一个比较关键的是，程序进度的度量。软件项目中的进度问题，一直是一个比较纠结的问题。时间的消逝可以证明，判断工作进度最好的方法是看实际花费的时间，而不是计划的时间。

        所有的软件项目，在开始之前都会有一个日程安排，而不幸的是，几乎所有公司的时间表，都是为公司的会计准备的。时间表不能反映项目的实际进展。另外一个比较客观的原因是，开发人员很难面对现实的，去度量自己的进度。一个问题没有解决的时候，我们总是很难客观的对该问题进行评估，而且由于面子问题，我们也很难承认我们无法快速解决问题的现实，所以我们在汇报进度时，总是会说，快好了，已经80%了。笔者实习期间，遇见了一个比较认真的manager。每次我汇报进度的时候，都会被其问倒，映像最深的就是，我喜欢说快好了。现在想想很是可笑。快好了几乎是什么也没说。

        上面是摆问题，度量项目进展的一个比较好的方法是，让你的下一步工作可见。一种最合适的方法是，使用待办事项。所谓代办事项就是等待完成的任务列表。当一个任务完成以后就把它划掉。

        人类对于未知的事物是恐惧的。反之，如果我们很清楚我们完成了什么，还有什么没完成，我们就会很轻松。心理和生理上都是。只是我是这样的。

        用户的每一个抱怨背后都隐藏了一个事实。没有愚蠢的用户，只有愚蠢自大的开发人员。“它就是这样的”，这不是一个好答案。

        任何一个笨蛋都能让事情变得越来越笨重，越来越复杂，越来越极端。需要天才的指点和相当的勇气，才能让事情朝着相反的方向运行。这是John Dryden说的。代码一开始都是简单清晰的，这就像是小孩，大家都喜欢，长大了就烦了。

         究竟是什么原因让原本很清晰的代码，变的越来越难以掌控。一个很重要的原因，是开发人员在完成任务时，可能会难以抵挡诱惑，为节省时间，走捷径。而这些捷径，只会推迟问题爆发的时间，并不会解决问题。当项目的时间压力变大的时候，大家都会心烦意乱，正所谓，你越烦，你就越烦。你越是为了节省这一点点时间，你在后面就会遇到越多的麻烦。这就要求我们在写代码的时候，要时刻保持敏捷。

有几个推荐的原则：

1.比如1<<2替代1*2的这种小伎俩，就不要写了，为了让代码看起来更清晰，我们可以甚至可以牺牲一点点所谓的效率。

2.关键字尽可能的符合常识。让人一看就知道意思。

3.注释很关键

         尽管江湖上有一个观点是，代码难写就应该难读。我还是认为，我们应该写清晰的代码，而不是讨巧的代码。

最后感慨一下：

           不要明日复明日。如果现在不做，将来你也不会做的。