读敏捷软件开发

读敏捷软件开发

在阅读The Clean Coder，书中提到这本书，闲暇之余，找来这本书翻看了一下，发现对我来说同样是一本难得的好书，触及到了我很多知识盲点。这本书英文出版于2002年10月，中文版出版于2003年9月。同样也是bob大叔的大作。

这本书介绍了敏捷软件开发和极限编程的实践，中间部分讲诉了软件设计原则，后面几个章节介绍了一些常用的设计模式，并且结合一些具体的案例来具体阐述设计模式的使用。

敏捷开发宣言

2001年，Kent Bech，James Grenning，Robert C.Martin,等一些名声显著的业内专家聚集在一起，概况出了一些让软件开发团队具有快速工作、相应变化能力的价值观和原则，即敏捷软件开发宣言。

• 个体和交互 胜过 过程和工具

• 可以工作的软件 胜过 面面俱到的文档

• 客户合作 胜过 合同谈判

• 响应变化 胜过 遵循计划

虽然右侧也有价值，但是我们认为左项具有更大的价值。

在这本书中讲诉了极限编程，读完一遍之后，我所理解的极限编程就是测试驱动开发加结对编程，再加上敏捷实践。在我仅有的开发经验中，客户的存在感并不强烈，在我工作环境中，客户是和我们的需求方对接，而且我们的需求人员都是经验非常丰富的开发者，他们会和客户沟通协调开发的任务。或者说，在我们这里，我们的需求人员某种程度上就代表着客户，从这一点来看，需求的反馈和理解都不算什么问题。值得一说是，在书中极限编程一章的末尾提到重构，这在我们的团队中，是比较少见的，这也非常容易理解，我们项目的单元测试才刚刚起步，大多数人不会去编写测试用例，编写测试用例，仅仅是为了过所谓的代码红线。这就相当于我们没有测试用例可用，没有测试用例也就意味着我们无法进行回归测试，无法回归测试就造成重构的代价异常之大。我们对重构后的代码无法确认是否会引入bug（其实往往会的）。这就会回到了那种情况，代码能跑就不要动，不然你难以承受其修改之重。

前不久在知乎上看到一篇文章《天下程序员苦“敏捷”久矣！》，文章里提到现在的很多公司曲解敏捷的概念，敏捷意味着干更多的活，Bob大叔写了一本书来批判这种情况，即《敏捷整洁之道》（看来要读的书单中又多了一本）。敏捷开发提出了二十多年，众多公司纷纷拥抱敏捷开发，但其实能做到和理解敏捷开发的公司应该是不多见的，就我在华为的所见来看，依然有很大差距，当然我也看到了很多改变，比如开始要求编写单元测试，需求串讲后，会组织开发反串讲，以及测试用例评审。很多地方相比我刚刚进入项目时要显得专业一些。华为公司有些部门尚且如此，国内更多的公司的敏捷实践，可能更加糟糕。链接： 天下程序员苦“敏捷”久矣！《敏捷整洁之道》告诉了我们什么？ (zhihu.com)

设计原则和设计模式

令人遗憾的是，这本书成书过早，在2002年的时候泛型编程还未走向成熟，泛型编程起源于C++，在C++11之后才是较为成熟的泛型编程，虽然STL使用在那时就出现了，但是程序员对多态的使用还基本都是动态的面向对象。这也造成了这本书里对于软件的设计基本都是关于面向对象的。在我看来，泛型编程在近十几年的发展是较为成功且令人眼前一亮的，使得多态的实现有了一个全新的方式，在编译时期来决定具体的运行内容，以代码空间来换取运行速度，来规避抽象带来的代价。虽然泛型编程也同样会面临一些问题，我们往往会陷入无尽的模板套娃和异常复杂的元编程中，还有一堆令人头痛的编译错误，但是泛型编程依然为我们打开另一条思路，所以我更倾向于结合泛型编程和面向对象共同来组织我们的代码架构。

对于普通的开发者而言，代码采用面向对象的结构，就可以给程序带来设计原则和设计模式，当然这其实是不太准确的，面向过程编程同样也可使用设计原则，但是远没有面向对象这么强烈。对于设计原则和设计模式，对于程序的开发有非常大的影响，或者可以认为是颠覆性的影响。初学者对于设计原则的感悟不深，可以根据代码的使用场景，选择一些成熟的设计模式，较为快速地搭建软件架构，当然其中也难免会出现一些模式的误用，但随着开发经验的增加，也越来越理解设计模式和其背后的设计原则，渐渐地可以脱离教条的模式，根据自己的理解和设计原则，来设计自己的程序结构，一味地遵循设计模式，不顾代码的实际需求，反而成为一种拖累，成为软件中的八股。

设计原则应该是独立于编程语言的，是软件历史发展所总结出的精华，不会因为编程语言的变动而有所变化。那设计模式呢，有人说设计模式也是语言无关的，其实，对也不对，设计模式也确实超出某种语言的限制，但也不是任何语言都能适用，这和编程语言的特性息息相关，有些常用的设计模式在动态编程语言的使用效果就不太显著，比如装饰器、迭代器在Python中的使用，由于Python有自己较为一致的装饰器和迭代器实现，通过魔术方法来编写Pythonic风格的代码，比纯设计模式的实现更加简洁高效。同样由于泛型编程的出现迭代器模式在C++中也退出了舞台，由模板来实现迭代器，也显得更统一高效。在流畅的Python中提到"23种设计模式，其中有16个在动态语言中不见了，或者简化了"。所以设计模式也并非是一层不变的，我们学习设计模式是学习其价值体系，设计原则和哲学思想，不应固化在某一种设计模式之中，我们应该时时关注最新的软件发展趋势，没有永远不变的开发模式，只有适合当时情况和符合当时价值体系的方式才应该为我们所取。

书中的Command模式和观察者模式给我的印象尤深，我基于Command模式重新构建一套软件UI框架，兼具日志系统、单元测试系统，解耦了UI操作和业务逻辑实现，实现了基本的TUI，为GUI的实现奠定基础，命令行调用，还可以使用命令脚本来批处理程序，有C++和python两个版本，相信不久后就会这篇博客。而书中提及观察者模式比我常用的观察者模式要复杂一下，之前并不清楚，观察者模式还分推和拉两种模式，我常用的观察者模式，仅仅是推模式，但看到拉模式，不由的感叹，我靠，居然可以这样。此外，其实也感觉到，推和拉两种模式的差距其实并不大，仅仅在于被观察对象是否依赖于观察者抽象类，拉模式的实现要比推模式稍微复杂一些，我目前的项目也并没有说非得需要使用拉模式。

总结

总而言之，《敏捷软件开发》对我来说是一本难得的好书，当然贪心之余，也会感慨意犹未尽，未能尽述如今的软件开发态势，毕竟已经是一本二十年前的书了，书中设计原则，历经这么多年经久不衰，反而设计模式在这么多年之后，有些已经渐渐淡出历史舞台，我们有了更新的技术，有了更宏观的视野，不再是如同黑夜中的摸索，感谢这些业内的专家，为我们点亮了前进的方向。