前言
这周看了几个敏捷软件的设计原则。单一职责原则与开放封闭原则。
这让我想起了昨日……因为一个同事任务没做完，我和另一人被经理指派去帮助他。
正文
这让我想起前几天看到的一句话，大概意思是，当你认为项目紧急时，急急忙忙的往里面投人却往往不会起到很好的结果。
但没办法，领导让人去，哪有不去的道理呢。也算是阴差阳错吧，体会到一把“结对编程”的快乐。书中所说的，在一个安静，大家都在讨论问题的环境。昨天是真的有了。
因为只有2个文件夹下的功能，却有3个人，就让我和帮忙的同事负责具体功能的编码，另一人就告诉我们其中的业务与代码写在哪就可以了。写起来还是挺快的，就是看别人的代码，容易挑毛病。却猛然惊觉，发现别人的缺点很容易，为什么不去发现下别人的优点呢？
然而看了许久，却是真没发现哪里有闪光点，可能是我格局不够吧。后来听了他的一番吐槽，才终于明白。
需求一直在变化，2个月前就做了第一版了，然后发到现场去，返回来了20多行字的需求文档，设计人员也不懂，问什么都说：“行啊，那你就先做成这样子吧！”而过一段时间后，又说，这么做不行啊！到最后，错的全是开发……而需求，直到这周一才确认下来。
换位而处，以前我可能也会和他一样吧！需求变来变去，改起代码，好好地功能一改就会报错了。改了一个地方，另一个完全不相关的地方就报错。这就是因为设计时没把功能想好。引起变化的地方太多了，就会这么疯狂报错……
写到一半，我们也忍不住疯狂吐槽起他的代码来了。
“你这代码也太脆弱了吧！怎么随便点个几下就是个报错啊！”
他说：“别问，DNF当年刚出来时不也是这么多报错吗，你看现在，多完美啊！”
DNF当年是什么人在改bug啊！！能比ma！
想起书中所说，好的代码，应当能实现功能，能应对变化，能让别人读懂。
然而同事的代码，却。。需求变化，真的是太……就突然明白了设计模式是为什么存在了，前人也是尝过没设计模式的痛，才发明了这些模式的吧！
总结
能抽象出来的方法就要抽出来，共同的部分就抽个单独的方法出来，方法名也要命名的好，让人容易理解。不能疯狂复制粘贴的对代码，代码量越多，就越不易读。开放与封闭原则原来不是我理解的，改代码时新增个方法不在原有方法上改那么简单啊！但也殊途同
归吧。工作中也试着用这书中的方法来做了些，需求下来了，先想好了再动手，不直接码；确实有条理了很多。功能昨晚，即时和设计说，即使设计不怎么懂，也是很好的甩锅。