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

　　前言

　　这周看了几个敏捷软件的设计原则。单一职责原则与开放封闭原则。

　　这让我想起了昨日……因为一个同事任务没做完，我和另一人被经理指派去帮助他。

　　正文

　　这让我想起前几天看到的一句话，大概意思是，当你认为项目紧急时，急急忙忙的往里面投人却往往不会起到很好的结果。

　　但没办法，领导让人去，哪有不去的道理呢。也算是阴差阳错吧，体会到一把“结对编程”的快乐。书中所说的，在一个安静，大家都在讨论问题的环境。昨天是真的有了。

　　因为只有2个文件夹下的功能，却有3个人，就让我和帮忙的同事负责具体功能的编码，另一人就告诉我们其中的业务与代码写在哪就可以了。写起来还是挺快的，就是看别人的代码，容易挑毛病。却猛然惊觉，发现别人的缺点很容易，为什么不去发现下别人的优点呢？

然而看了许久，却是真没发现哪里有闪光点，可能是我格局不够吧。后来听了他的一番吐槽，才终于明白。

　　需求一直在变化，2个月前就做了第一版了，然后发到现场去，返回来了20多行字的需求文档，设计人员也不懂，问什么都说：“行啊，那你就先做成这样子吧！”而过一段时间后，又说，这么做不行啊！到最后，错的全是开发……而需求，直到这周一才确认下来。

　　换位而处，以前我可能也会和他一样吧！需求变来变去，改起代码，好好地功能一改就会报错了。改了一个地方，另一个完全不相关的地方就报错。这就是因为设计时没把功能想好。引起变化的地方太多了，就会这么疯狂报错……

　　写到一半，我们也忍不住疯狂吐槽起他的代码来了。

　　“你这代码也太脆弱了吧！怎么随便点个几下就是个报错啊！”

　　他说：“别问，DNF当年刚出来时不也是这么多报错吗，你看现在，多完美啊！”

　　DNF当年是什么人在改bug啊！！能比ma！

　　想起书中所说，好的代码，应当能实现功能，能应对变化，能让别人读懂。

　　然而同事的代码，却。。需求变化，真的是太……就突然明白了设计模式是为什么存在了，前人也是尝过没设计模式的痛，才发明了这些模式的吧！

　　总结

　　能抽象出来的方法就要抽出来，共同的部分就抽个单独的方法出来，方法名也要命名的好，让人容易理解。不能疯狂复制粘贴的对代码，代码量越多，就越不易读。开放与封闭原则原来不是我理解的，改代码时新增个方法不在原有方法上改那么简单啊！但也殊途同

归吧。工作中也试着用这书中的方法来做了些，需求下来了，先想好了再动手，不直接码；确实有条理了很多。功能昨晚，即时和设计说，即使设计不怎么懂，也是很好的甩锅。