前言
买书如山倒，看书如抽丝。买了许多书，却还有好多本没看。总是能给自己许多借口，于是参加了星球【码农翻身】的读书活动。
敏捷软件开发，看资料说是欣哥以前是国内敏捷开发的布道师，这可能也是他大力推荐这本书的原因吧！
这次看的是第一阶段，1~5章。
正文
第一章，说的是敏捷实践，说了一些敏捷开发的宣言。这些就和面向对象的思想似得，只有实践中遇到了些什么问题，才会恍然觉得某句话说的很对。让我印象最深的一句，是个体和交互胜过过程和工具。
这让我想起了自我工作开始烦恼到如今的问题，安全问题。前人的代码留下了无数的坑啊~！！在js之中写了表名与sql，当时可能很方便，但如今要想完全改好就得全部推倒重做。这要怎么改……项目管控组催的急，甲方狂喷经理，经理狂喷我们。然而项目组是用某些工具来发现安全问题的。我们只需要骗过工具就可以了，最简单的对称加密，传输过程中的request就不会有敏感信息。最简单的变量替换字符串中的关键字，响应的response里也不会有了。就是这么改会让代码更加不可读，面对变化更难变化，系统运行起来做更多无用的操作，却根本起不到任何安全的目的！
但是，谁关心这个呢？工具扫不出来就可以了。甲方和经理就会很满意。
第二章，说的是结对编程。就是2人用一台电脑。一人控制键盘，另一人在他写的过程中观察他有没有哪边能优化的。让测试驱动开发，先写好测试用例，再把单元测试写好。这样在写代码的过程中思路会更加清晰。而且单元测试就是一个最新，最全的无形文档，它是函数的第一个调用的例子。当日后重构代码，也是减少隐患的保证。我喜欢其中关于重构的说法，任何一行代码重复了，就代表它是臃肿的，是要被消灭的。我在工作中也经常看到几千行的js，java代码，其中每个文件都有许多，至少几百行甚至更多的重复代码，让我看起来很难受。然而不敢去解决，毕竟功能正常运行这么多年了。暂时来说，还是不敢去解决以前功能里的重复代码，只能自己以后开发的代码都保证抽象出其中共性的部分来吧！
第三章，说的是计划。也就是估算工作量，每次最烦的就是估算工作量了！我们的设计也是新人，然后笑嘻嘻的问我们，能不能实现呀？大概要多久呀？第一个问题，问能不能实现都是废话啊，，怎么可能说不能实现呢。而大概要多久，我怎么知道……要是一切都按我想的那样好，一会就能解决了好不好，但代码往往都有他们自己的想法。
第四章，更详细的说了测试。提到了项目一开始就要构建自动化测试框架，不要因为一开始项目较小而直接手工测试，这样越到后面测试效率越低下。与模块内部有关联且懂得逻辑的白盒测试，和与模块无关联且不关心逻辑的黑盒测试相结合，才能保证软件越变越好。
第五章，重构。提到了代码的三个职责，能运行起来；能应对变化；能与人交流。可用，可变化，可读。
想了想，我负责的模块必然是可用的，但易于变化的就很少，若是改动量大的需求，就会在问题平台躺很久，被各部门踢皮球踢来踢去，我甚至看到有个4年前提的需求今天还是挂起状态，下面长长的历史记录记载了现场，开发，总部三方斗智斗勇的回答。最终2年前被开发中心挂起而结束了。至于易读的代码，更是寥寥，工作中的代码，大多是为了实现需求吧！根本没人关心后来者要怎样。
总结
虽然读到的内容对目前的境遇看起来帮助不是很大，但是以后我写的代码会尽力往可用，易变化，易读上靠拢的。