道法术器，第一次写书评并由此引发的思考

最近在看这本书

过程中有些感悟，写了一个书评，在写书评的过程中，又引发了我的一些思考，都记录如下：

书评部分：

之前对DevOps这个概念有一些了解，不过大多都是从一些碎片的网络博文获取。但是我们知道，碎片的信息难以成为指导自身行动的知识，就是因为不成体系，不成系统。所以，系统的了解DevOps，选择一本专业书籍就显得很有必要。

DevOps权威指南，不仅仅是一份实践指南，也系统的阐述了概念相关的理论层面的内容。术固然重要，否则我们就会因为无处着力，无处下手而觉得轻飘飘；但道也不能忽略，否则，就会陷入具体的细节而无法从更高的、全局的视角看待问题本身。这就是所谓的虚实结合吧。

通过理论层面的学习，个人感觉印证了那句话：“天下大势，分久必合，合久必分”。一个概念的产生并流行，并不是凭空出现的，而是有其背后的土壤。

DevOps也是在软件开发、运维、管理的分分合合中，逐步形成的。从早期的一人包打天下到后来的团队分工合作，再到对分工的全链条管理，有技术发展的支撑，也有大环境变化的促进。可以说，我们现在看到的与其相关的东西，都是随着软件开发过程的进行，因其内在本身的要求而孕育出来的，就如人常所说，存在即合理。相信，DevOps会伴随着信息产业的发展继续变化、调整、从而适应发展，经历“存在---变化---新的存在”的过程。

对于实践层面，书中提供了理念落地时可参考的大量方法、工具，并对这些操作实施层面的实体进行了分析对比。正如书中所讲，如何实践DevOps没有标准答案，不同企业，其规模、文化、业务类型、产品场景、应用市场等等许多维度都是不一样的，关键是要找到适合自身的一套最佳组合，这其中免不了试错过程。容忍出错，快速调整改进，我想这才是本着务实的态度去做事的应有之义。

最后，我觉得要强调一点，一定要避免将DevOps片面理解为几个流行工具的应用，没有理念和思想的深入，实践中必然会遭遇撞墙。

思考部分：

写完，感觉还没有尽兴，再补充几点：

其一，人不应该给自己设限。不要我是搞这块的，就只关注这一块就可以了。这样，容易形成收缩的惯性，导致路越走越窄。

相反的，不但应该多涉猎专业领域相关的，这里主要指大的技术方面的，也应该涉猎其他看似无关的书籍。

往小了说，会开拓思路，跟上时代，还指不定哪天会以意想不到的方式用上；往大了说，万事万物，理是相通的，所谓理想状态就是一通百通。有点佛家的大彻大悟的意思。

其二，在读书的过程中，突然对国内的教育有一点点反思。让我慢慢道来：

如上书评所说，任何东西都不是凭空创造出来的。一个概念的形成，最开始可能就只是一个简单的想法。

有人提出这个想法，大家围绕这个想法展开讨论。讨论的最初，往往是大家脑海中的一些感悟。然后大家对讨论的东西有了一个大概的模块的认识。

逐步的，大家觉得这个东西是可以深入探讨的，而最初的一些想法，比如一两个具体的东西，可能就成为了切入点。

随着讨论的深入，完整系统的概念就慢慢的形成，从而完成由信息到知识的转变。这个转变的过程，就是理论成形的过程。

转换为理论后，还有一个很好的结果，就是某些东西能不能去做，或者在多大范围内可以做，都会有公式或者数据支撑，是可复制的或者说可重复的，而不是盲目的凭感觉去做，是否可行，存在乎于个别人的一心。像中国的很多独门秘籍，就是这后一种，往往只可意会，不可言传。

由上面这个过程，我发现，这不就是国内外学习和研究的差别所在吗？

在国外，人搞研究的方法和思路，比国人要强很多，整体水平也要高很多。很多东西，我们发现后，往往忽视从理论的高度来提炼分析，来推动发展。所以，很多理念和概念，都是外来品，我们总是处于跟随追赶的角色。

老外对某一个东西了解后，会转化为研究，并会有意识的发表为论文。我们从Google的很多东西就能够看出和感受到这一点。

也许这与他们从小接受教育的方式有关。鼓励探索，鼓励研究式的学习，鼓励发表自己的观点，只要你能够探索到足够的支持自己观点的证据即可。

而我们更多的是接受一种吸收式的教育。国外会灌输很多要勇于对已有科学成果证伪的思想，而我们则是不断考察学生的识记能力，总是要提供标准答案。

其实对于科学领域的那些知识是怎么来的，了解了它们的发现过程，我们就会发现国外的教育方式，似乎是自然而然的，跟他们的前人发现成果的思考方式在一条道上，而我们则感觉就是旁观者的角色。

网上有人说，中国人的勤奋从另一个侧面反映了中国人的懒。因为我们总是“勤奋”的记住已有成果，而“懒”于去对其中的某些点展开探索研究。当思维惯性固定后，也就束缚了创新创造。

其三，由上面的第二点，我们就可轻松的发现，一个知识体系的形成，往往都不是一蹴而就的，而是经过了漫长的沉淀过程，才最终成形。

最开始可能只是很多相关的论文，慢慢的，核心逐渐汇聚，大家达成共识，形成了系统的东西。

所以，反过来，对一个东西的学习，也建议系统化的展开，系统化的思考学习。零碎的片段只能算作信息，容易产生盲人摸象的结果，容易陷于局部的片面的理解，无法从高处全局看到问题。成系统串联起来的才叫知识，内化与心，掌握本质，才叫智慧。

最终，我们不仅要重视术的传递，还应该更重视道的传授。所谓道法术器，缺一不可。

道法术器，第一次写书评并由此引发的思考相关推荐

（11）照虎画猫深入理解响应式流规范——响应式Spring的道法术器
本系列其他文章见:<响应式Spring的道法术器>. 前情提要:响应式流 | Reactor3快速上手 2 响应式编程之法上一章本着"快速上手"的原则,介绍了响应式流 ...
SpringBoot2.1.15(26) WebFlux快速上手——响应式Spring的道法术器
SpringBoot2.1.15(26) WebFlux快速上手--响应式Spring的道法术器 Spring WebFlux Spring WebFlux是随Spring 5推出的响应式Web框架. ...
（12）自定义数据流（实战Docker事件推送的REST API）——响应式Spring的道法术器...
本系列文章索引<响应式Spring的道法术器> 前情提要 Reactor 3快速上手 | Spring WebFlux快速上手 | 响应式流规范本文测试源码 | 实战源码 2.2 自定 ...
（19）Reactor Processors——响应式Spring的道法术器
本系列文章索引<响应式Spring的道法术器> 前情提要响应式流 | Reactor 3快速上手 | 响应式流规范 2.9 Processor Processor既是一种特别的发布者(P ...
2.敏捷全景图之道法术器
敏捷已经从最早的软件开发领域扩展到企业的方方面面.成为敏捷型组织,具备业务敏捷性,实现持续交付和最大化业务价值,不但需要Doing Agile(进行敏捷运作),还需要Being Agile(以敏捷思维 ...
（4）Reactor 3快速上手——响应式Spring的道法术器
本系列其他文章见:<响应式Spring的道法术器>. 前情提要:响应式流 | lambda与函数式 1.3.2 Reactor Reactor与Spring是兄弟项目,侧重于Server端 ...
如何接手别人的系统-遗留系统重建的道法术器势志（万字长文）
by zhimaxingzhe from 如何接手别人的系统-遗留系统重建之道法术器势志欢迎分享链接,尊重版权,未经作者授权,禁止转载,授权后转载请注明出处,若急用请联系. https://zhim ...
响应式Spring的道法术器（Spring WebFlux 教程）
Spring WebFlux 2小时快速入门 Spring 5 之使用Spring WebFlux开发响应式应用. lambda与函数式(15min) Reactor 3 响应式编程库(60min) ...
（6）Spring WebFlux性能测试——响应式Spring的道法术器
本系列其他文章见:<响应式Spring的道法术器>. 前情提要:Reactor快速上手 | Spring WebFlux快速上手本文源码 1.4 从负载测试看异步非阻塞的优势前面总是& ...

道法术器，第一次写书评并由此引发的思考

道法术器，第一次写书评并由此引发的思考相关推荐

最新文章

热门文章