敏捷软件开发：原则、模式与实践【读书笔记四】

　　这一部分的内容不是很明了，但这周经历的一个项目，让我对敏捷开发思想有了更深的理解。

　　这周到了第四部分，10~12章。其实这几章上周就已经看过，只是没怎么懂。这几章说了下设计模式的几个原则。

　　Liskov替换原则，意思就是子类型必须能替换掉他们的基类。

　　依赖倒置原则，高层模块不应该依赖于低层模块。

　　接口隔离原则，客户程序应该只依赖于他们实际的调用方法。

　　可能是我技术没到家，基础太薄弱的原因。虽然今天看了好多遍，也没有很深入的理解。还是写点这周发生的一些有关于敏捷思想的事情吧。

　　这周，是个平均每天晚上都10点多下班的一周。让我思考了许多。也发现了许多自身存在的问题。

　　上周被经理安排帮助同事做项目，应该项目将要延期。首先的问题就是心态上的，我并没有把这件事当成自己的。还是有很大的学生心态在作怪吧，就像以前老师给学生布置作业似得，布置下来了各人完成各人的不就好了吗？哪有自己的作业完不成还要别人帮忙做的道理。然而并不是的，我也是双标的。并不是模块固定就是谁是谁的，后来我这边来任务了，但因为我手上有事情，也有另外的同事来帮忙做。在工作时，确实不该只盯着自己手上那么点工作想，要把思维抬得高一些，想想各方面的运作。项目如果延期了，在和甲方谈项目时价格就会被压低，最后可能会影响绩效什么的。（虽然做的好看起来和我们并没有太多关系，但做的不好我们必然背锅）

　　心态方面，一开始很气，为自己莫名其妙来的活而气。但换个角度想想，也挺好的，有代码写应该开心才对。总比在那没事，解决现场问题和现场人玩尬聊来的强。

　　影响人心情的另一个原因就是代码，同事的代码写的很多，而且各个页面相似的代码很多，都是重复代码。看起来人很遭重。一开始我是边写边抱怨的。但谁不知道代码要易读易修改呢？抱怨些政治正确的话并没有用，一开始自己写的时候也是在上面乱乱的基础上写，让代码更乱了。后来猛然发觉，宁愿多花点时间，也要尽可能的把代码写的好看点。因为省那么一时的时间，后续往往要花更多的时间。CV大法只能让人一时快乐啊！

　　然后本来定的周三发包果然没有发成。真是符合那条定律啊！往延期的项目中投人，来期望项目不延期，往往项目都会延期。那天大家在那思考了许久，发现了更多的问题。也是那天开始我才发现心态上有很大的问题。在经理交给我任务的那时起，这个“作业”就不是同事一个人的作业了，是我们三个人的。我应当把它当成自己的事情来做的。

　　首先改动的是表结构，本来的表结构只有2个字段，关联id，列名集合（所有列名逗号分隔存进来），然后取数据的时候又要分成数组，数组里每个i都要各种判断，异常复杂。这样好像也不能提高效率。想起曾经学的，数据库的表结构设计，一行要能描述出来物品的属性来，这样的表结构显然是描述不出来的。但表结构一动了，前后台全要动，改动量实在太大了。所以之前就一直没动。

　　但越不想做的事越会让人做啊！最终还是改了表结构。不想让表的字段太多，但想要描述这么一个功能，就是需要这么多的字段。现在想着字段太多，会不会影响到以后的效率什么的，并不需要担心。数据量真大到那种程度了，自然就知道怎么提升效率，优化表结构了。目前的首要任务还是让用户愿意在这个系统中录入数据，增加数据量才对。这就是敏捷软件思想吧，别去自作主张的想一些未来可能有的需求。先易于眼下的变化再说。

　　于是改写了下现有的代码，找出了其中共同的部分，datagrid（我们框架中用来在网页展示一个多行表格的对象）和一个主键，写了个方法，每个需要加载列名的时候调用一下就可以。方便省心了许多。。

　　项目在昨天，周六大体上的功能都差不多完成了，还有许多值得完善的部分，但足以周一发包出去了。还是挺有成就感来着的。做一件事情时，比技术更重要的是每个人都要有做成这件事的意愿，把事情当成自己的事，才有可能把事情做好。这就是敏捷思想中以人为本的概念吧？