敏捷道路伊始——从小事做起

      最近在看《敏捷软件开发 原则模式与实践 C#版》这本书，相信各位朋友也多少有些了解或已跻身敏捷开发的领域中。

      作为软件行业的一小菜,深知自己要学习的东西还有许多,毕业后写了几年的面向过程的程序,深感内疚;更觉得对不起以前所在的公司,虽然自己兢兢业业,一直非常努力,但总是做不完的事情.当初不明白什么原因,总觉得是公司的问题.直到最近终于了解了:个人程序修养不够.

      这也不全是我的错!

      大专毕业,在学校的日子简直就是神仙般的.课程不多,关键是没明白学这么些东西可以用到哪里!数据库学得还算可以吧,但最开始学的时候确不知数据库有什么用,后来慢慢的开始接触项目有些'领悟':原来数据库就是项目的根本——不管老师是不是这么教的,但潜意识就是如此.这样浑浑噩噩居然做了几年项目,但项目的质量可想而知.

      辞职.

      虽然说不出为什么,感觉上有什么东西始终不对劲.努力了,收效甚微.甚至有倒退之嫌.果断从公司辞职,虽然公司的领导对我很好,也很看好我.却不知他们有没有看到我缺的是什么,终究没有告诉我.

      一个人的浪迹.

      辞职之后跟朋友合伙搞一个开发,他提供需求(也是半路出家,需求不到位).就这样两个半壶水,开始了所谓的创业准备.跟公司的开发一样,设计的程序非常难扩展,难维护.需求改动一个接一个,最后摇摇欲坠的项目经不起客户的考验——我宣布这个版本彻底失败了！

      不服输，设计模式.

      在软件领域,我的激情用不完.失败,就重新开始.正巧那阵子我开始接触设计模式,就萌生了重新构筑项目的想法,朋友也不反对:你做了这么久的软件从来没拿出来过一个成品东西!

      软件设计.

      和大多数开发一样,一开始定义项目的框架,这时候我还认为:失败的根本原因是框架定义得不够完善,不能最大程度的解决需求变化.所以这次在框架的定义上,几乎用上我所熟悉的设计模式来定义这个'架构'(我称之为架构,实质谈不上什么架构),想让所有的功能实现在这个框架模式下实现.

      噩梦的开始.

      决定重新构筑项目之后,我也了解了一些需求,加之一个成熟的软件作为参考,我定义所有数据库表,来从数据库设计上去实现这个软件.也用ORM工具,对象构筑起来之后,整个软件就依托这些对象,我几乎可以看到软件运行的摸样!一直以来潜意识中项目就是数据库,只要数据库设计出来,项目就设计出来了.满怀欣喜,埋头苦干!这也正是我在公司的态度.一开始我拒绝把项目的雏形和设计思想跟我的合作伙伴讲,一部分原因是我自认为自己了解系统及需求,另一个原因是我的软件还没有完成大部分功能,觉得没必要给'客户'看,实际上也不能给客户看!

      几乎又失败了.     

      问题又出现了,这次是我自己深感危机.最近我提交了一个一定程度上可以运行版本给客户(暂且将我朋友看做客户),结果我也预料得到,很多东西客户不了解,很多功能客户不需要,很多BUG在客户在乱操作一通之后涌现出来我费尽心神构筑的软件就这样运行在几乎崩溃的境地.我修改了一些功能,客户说另一些功能以前是正常的现在出问题了!这几乎是我不敢相信的事情,但确实如此.更要命的是客户提出了一些合乎道理的需求,我仔细看了下,在这个我定义良好的框架下几乎已经容不下这个合理的要求,原因是如果接受这个合理的要求,很多地方需要修改,而且修改的程度不亚于重写的难度(需要变更最初的最底层功能设计,所有的功能都构筑在这些基础之上).我迷惘了!

     笔记本坏掉了,但似乎是好的开始~

     不知什么原因,笔记本硬盘坏掉了,需要更换新硬盘,硬盘是7200转的,电脑城没货了,需要一个周(结果几乎过了一个月).这样我就没事可做了,不能修改那个千疮百孔的项目.静下来好好想了几天:这样的开发绝对行不通!

     TDD.

     几天之后,我决定去新华书店打发无聊的时间.发现很多关于软件测试的书,测试有什么用,我几乎都没接触过测试,公司也没有,近乎提过这个概念,但没有下文.随便拿起几本看了下,发现有本关于 测试驱动开发(TDD)的书写得蛮不错,翻了几页之后,把我当前面临的窘境写得非常准确!当中提到 敏捷开发 的概念.似乎以前我的项目经理跟我讲过,但也是没有注意,也没什么下文.

    《敏捷软件开发 原则、模式与实践（C#版）》

     能看到这本书,近乎巧合.一个不起眼的角落!完美的解决方案,分析项目失败原因,从需求到测试(TDD)到编码,迭代开发,时时跟进需求,应对需求变化.很奇怪敏捷开发不主张一开始构建项目的框架,框架的构筑是在一个一个的功能的叠加之上的.很多非常新颖但确实是当前最佳解决方案的看法.草草的读了一遍之后,了解了当前面临的问题原因所在,也知道在公司的面临的各种问题.犹如抓到了救命草,决定开始认真学习这种优秀的方法,来解决当前的问题,并指导以后的开发.

     又陷入迷惘.

     按我当前的项目写法,是不可能完全转入这种方式之中的,因为本身实现一个功能的方法是固定的方式,涉及到系统原本的设计,无论是新增或修改都比较困难,虽然《重构》有讲，无论项目进行到何种程度，都可以进行重构.也许是吧,但工作量之巨大!到底是用敏捷开发的思想TDD作为工具对项目进行重构,还是重新开发.据我所估计这两种的工作量,估计相差不大,加之现在对敏捷开发的领悟不是很透彻,两种方法都有相对难度.书看了两遍,收获不少:书越看得到的越多!

     从小事做起.

     无论如何,都决定开始用敏捷方法来对待我的项目,无论多么痛苦!