软件迭代开发的痛苦与乐趣

          在软件开发过程中，我们不可能一开始就实现软件系统所需要的所有功能。反之，我们应该只去实现今天的用户故事，然后重构，明天再扩展系统、实现新的用户故事。虽然这是迭代和增量敏捷的精髓所在。但是这种开发过程又是比较痛苦的，它要求程序员不断的根据系统架构需求来完善功能，而在系统架构上每一次的更新意味着程序员需要对前面的代码进行比较大的修改。这时候成员开始骂人了。

          如何解决这个普遍存在的问题值得让人深思，这好比人的成长永远都不会出现一蹴而就的情况，要不然人的出生到死亡不过一瞬间的功夫，那么我们不仅要怀疑造物者是多少的脑残，更会怀疑人是否有存在的必要。而软件开发也是如此，我们不能为了一次性解决所有的问题而将软件的使用寿命降到了最低。而需要在不断的完善软件功能过程中增强软件的生命力，延长软件的存活时间。这或许就是软件系统的生命周期本质。

          要做到迭代开发是比较难的。在开发过程中，我们常常会遇到3个月后看现在编写的程序，会有一种完完全全鄙视的感觉。这样子无厘头的程序真的是我三个月前写出来的吗？遇到了这种情况，我们都开始窃窃偷欢，看来3个月的知识沉淀，让我有了一个质的飞跃呀！

           事实真的是这样子吗？可能未必吧！出现这样子的情况，不唯一但是最有可能的情况是，3个月后的自己已经站在了一个局外人的角度来审视这些代码。同时，也在从各个不同的角度来挑拣出这些代码的瑕疵。这时候，咱们学过的关于代码规范、代码的重构、代码的整洁、可读性等等规则都有了用武之地。不管这些代码对以后的开发是否有利，我们还是有一种想修改这些代码的冲动。让自己的代码更体贴别人，也顺便在别人的面前秀一下自己的coding功底。

           因此，在当前的编程过程中，我们既要以一种主人翁的态度对自己编写的代码负责到底，即满足软件的架构功能需求。同时也要以旁观者的观点来审视代码，让自己的代码能够快速干净的脱离自己，让别人在最短的时间理解代码的功能。这对程序员提出了一种高标准的要求，也对项目的管理提供了一种可控的风险。

          说来说去，其实要做到这些要求软件架构师能够将系统进行有效的水平和垂直划分，将系统的架构接近于真正的关注面切分。而在功能实现过程中，要求程序员不断的提高程序的内聚，降低耦合度，程序员需要不断的重构自己的代码，让代码简单，简单，更简单，直到最简单。