敏捷软件开发:原则、模式与实践【总结】

  这本书趁着这两天,把后面部分,不在读书计划里的章节粗读了一番。读起来确实是没有前面的章节,读起来那种脑袋发麻,像发现新世界的感觉。有个人引路真是太太太重要了啊!知识星球,公众号这种真是网络时代传播知识最快的途径。自己一人读就是比不上这种跟团一起读的感觉。

  这本书,读的过程中很幸运的能有个开发新页面的任务。正好可以实践一番。用了书中一些思想。

  需求与变化相生相伴,只要是需求,就必然会变化。更本质的话,就是人性了。不是需求在变,是人在变;因为需求也是人定出来的。一开始都讲好的页面什么的,到最后能保持和一开始定下来的有30%就不错了!可能就像我们自己在纠结中午吃什么一样,没吃之前纠结的很,吃起来吧,才知道什么是自己不喜欢的。用户也如此,他们也不知道自己要什么,只知道个大概。做出来以后,还是不知道要什么,但一定知道自己不想要什么。

  所以,快速反馈,和现场交互更多,才更可能让质量提高。这次做一个页面,我以为需求已经理解的很透彻,然后开始做,定下了2星期完成初版。结果比预想中的快些,一周就基本完成了。然后想自己这边优化优化,顺便给现场发了版初版的页面,没想到现场提意提了2周……要不是这次版本往后延期了2周,还不一定能把页面上上去。

  快速反馈,就是快速把自己认为不变的部分开发出来,尽早的把自己的“特性”(我认为就是功能)给开发出来,给用户看看是不是他们想要的。而一些类似样式、排序、字体大小等等不是主要功能的就先算了,后续再改。第一版基本上就是发过去,看现场环境和自己这边有没有什么区别,数据能取出来;按钮都能点。就可以了,然而我开发出来的几次,第一版往往都会有各种奇奇怪怪的问题。

  这次也认识到打印日志的作用。许多没触发异常的问题,但他们是异常,或者是异常就直接走不下去,页面报错的问题。不能因为一个数据有什么问题就让系统挂了呀、、而捕获异常后,不打印日志的话也无法解决问题。想起看到的一句话,代码在开发环境是死的,而到了生产环境才是活的。没有日志就没办法知道代码活的好不好了。

  然后就是重构代码,基本原则就是,重复,或者相似度很高的代码,就肯定可以抽象封装成个方法,极大减少代码量。基本上2处重复就可以封装起来了,不然重复的多了就更不好封装了。

  这本书还是极好的,多一种视野看世界的感觉。接触更多的思想才能看事情更客观!

猜你喜欢

转载自www.cnblogs.com/weixin-tt/p/10805315.html
今日推荐