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

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

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

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

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

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

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

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

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