|
|
# 结束语｜技术终将老去，但好在你还年轻
|
|
|
|
|
|
你好，我是姚琪琳。
|
|
|
|
|
|
首先，恭喜你学完了《遗留系统现代化实战课》这个专栏。不知道你学完的感受是怎样的？
|
|
|
|
|
|
每每看到你们在留言区的分享和肯定，看到自己用心写出来的文字得到了回响，我就觉得所有的付出和努力，都是值得的。
|
|
|
|
|
|
现在我们回过头看专栏中讲到的各个理论，无论是认知负载、假设驱动、演进式架构，还是代码重构、测试策略、绞杀植物、扩张收缩、微服务架构、持续集成、团队拓扑……你也许已经发现了，都是现成的理论。它们有些是专为遗留系统而设计的，有些虽然不是，但我认为也同样适用于遗留系统。我不是一个发明者，而只是一个搬运工，仅此而已。
|
|
|
|
|
|
**作为一个知识的搬运工，对我来说，写这个专栏其实是一件“枯燥”的事情。**
|
|
|
|
|
|
说它枯燥，是因为我们技术人员天生就爱去做“有技术含量”的事情。而整天面对文档码字儿，会被认为是没什么技术含量的工作。尤其是你不得不去梳理躲在脑子里各个角落的知识碎片，梳理之后，还需要有条理、有逻辑地表述出来。
|
|
|
|
|
|
写极客时间的专栏尤其如此，它要求语言通俗易懂，像跟你在唠家常。我一开始在试写时很不习惯，但好在都坚持了下来。
|
|
|
|
|
|
但是也正因为坚持下来了，我才品尝到“枯燥”之后的回甘。几个月折腾下来，受益者不只是你，还有我。如果不是这个机会，我可能永远也不会这样去总结，把自己过去十五年的工作经验，把这些看似毫不相干的理论，提炼输出成系统化的专栏，为你解决遗留系统现代化问题提供参考。
|
|
|
|
|
|
我也得承认能这么做总结不是一件简单的事。因为很多人在遇到一个问题的时候，更愿意去研究能够解决这个问题的工具。但特定的工具掌握了，下次碰见类似但不完全一样的问题，可能还是解决不了。因为他根本没有了解问题的本质。
|
|
|
|
|
|
道家的“道”、“法”、“术”、“器”特别适合来解释这个现象。简单来说，“道”是指思维、原则，是问题的本质；“法”是指方法、策略，是解决问题的方法论、原则和导向；“术”是指技术、技能，是解决问题的方法和套路；“器”是指工具、资源，是解决问题的技巧。
|
|
|
|
|
|
我们对于工具的痴迷和狂热，对应的就是“器”的这个阶段。但这并不是说它不重要，而是说，你不应该只关注“器”就满足了，而应该更关注“道”和“法”。
|
|
|
|
|
|
从“器”开始，慢慢向“术”、“法”、“道”去延伸，了解事物的本质，然后触类旁通，不用花多少时间就能熟悉其他“术”和“器”。这就是一个非常不错的学习路径，也是我能够把自己多年经验、各种理论结合整合在一起的原因。
|
|
|
|
|
|
对应到遗留系统现代化，这方面的“道”、“法”、“术”、“器”是这样的：以降低认知负载为前提、以假设驱动为指引、以增量演进为手段这三大原则，是“道”；四个现代化方向中的众多模式，是“法”；实战篇里的各种实践，是“术”；而各节课中穿插介绍的一些工具，是“器”。
|
|
|
|
|
|
|
|
|
|
|
|
你会发现，我最重视的就是“道”和“法”，其次是它们在实践中的应用，也就是“术”，而作为“器”的那些工具，我大多都是点到为止。不是“器”不重要，而是你不必纠结“器”的细节，应当把有限的时间花在更有价值的本质和原则上。
|
|
|
|
|
|
**为什么说看透本质，把握原则更有价值呢？**这里再给你分享一个我的小故事。
|
|
|
|
|
|
Thoughtworks的开发团队是“敏捷原生”的，在这样的团队中耳濡目染了几年后，我作为咨询小白，参与了一个敏捷咨询项目。
|
|
|
|
|
|
当时我自以为深谙敏捷，没想到在和客户交流的时候发现，自己连一些基本的Scrum术语都不清楚，而客户则很多都拿到了Scrum Master认证。当时我的自信一下子就跌到了谷底，感觉应该回炉重造。
|
|
|
|
|
|
然而随着交流的深入，我发现他们虽然拿到了证书，熟悉那些工具，但实际上并不了解敏捷的本质和价值观，因此只要不是书本上或培训中讲过的内容，就不知道对不对，不敢尝试了。而我则引经据典、旁征博引，客户无不恍然大悟、心服首肯。
|
|
|
|
|
|
后来我的同事评价说，你只是不知道自己知道罢了。这就是深入掌握了“道”和“法”，即使不清楚具体的“术”和“器”，也一样能所向披靡，就像是手中无剑、心中有剑一样。
|
|
|
|
|
|
这就像靠刷题去准备高考，虽然这种自下而上的学习方式有可能取得好成绩，但你会发现那些真正的学霸都是熟练掌握各种公理定理，靠推导来做题的。他们不用刷太多题，也能把题做对。因此这种自上而下的学习方法，关注“道”和“法”，认识问题本质，把握规律原则的路径，才是真正高效的、聪明的方法。
|
|
|
|
|
|
在专栏讲解中，我也更偏向这种思考方式。希望这个专栏，能够帮你认识到遗留系统问题的本质，把握住更为本质的原则与模式。
|
|
|
|
|
|
这些原则和模式，包括一开始梳理问题时所使用的方法，都是遗留系统在构建之初所缺失的。
|
|
|
|
|
|
**我们做遗留系统现代化，其实就是给遗留系统补上这落下的一课。亡羊补牢，犹未晚矣。**
|
|
|
|
|
|
分享了很多学习的方法，最后我也想和你聊一聊学习的心态。
|
|
|
|
|
|
IT技术是在不断向前发展的，新技术层出不穷，各种语言也是一个版本接一个版本，就连书籍都会出新版本，那一个架构、设计和理论又怎么可能一成不变呢？
|
|
|
|
|
|
一套理论，要想达到MECE（相互独立且完全穷尽）是很难的，因为任何一个复杂问题都不可能一开始就找出所有的关键点。就像一个遗留系统的解决方案，也是通过不断增量演进浮现出来的一样，遗留系统现代化的原则和模式也是不断演进慢慢完善的。
|
|
|
|
|
|
你可能疑惑专栏里提到三个原则就够了吗？这四个现代化方向是全的吗？掌握了这些，我就能一往无前了么？我的回答很简单，当然不是。我们应该抱着一个开放的心态，去学习一切跟遗留系统有关的知识。再通过不断总结和实践，去迭代自己的知识体系。
|
|
|
|
|
|
无论是遗留系统的工程难题，还是工程师的学习成长，都是一个长期主义的实践，都需要耐心、恒心、信心和用心。
|
|
|
|
|
|
所有人都对新技术趋之若鹜，生怕没有赶上这一班车而被时代所淘汰，这就是浮躁的典型表现。就拿我们常常讨论的35岁危机来说，本来35岁是一个职业生涯刚刚步入正轨、风华正茂的年纪，我们正要一展身手，基于之前的积累，开始从学习和输入转向更多的释放和输出。怎么就成了要么财务自由、别墅靠海，要么优化解聘、打包走人的分水岭了呢？
|
|
|
|
|
|
很多人都不愿意工作在遗留系统上，觉得没有技术含量。但想成为一个遗留系统专家，你需要多专、全专。从前端到数据库，从代码到架构，从测试到运维，从业务分析到团队管理，从数字化转型到认知心理学……建立了这样全面系统的知识体系，你才能在复杂的问题面前，临危不乱，应对自如。
|
|
|
|
|
|
看到这些内容，你还敢说没有技术含量吗？要进行方方面面的治理，具备从前到后的经验，怎么也得35岁起步吧？
|
|
|
|
|
|
就像我在开篇词说的那样，你现在所写的每一行代码，都是未来的遗留系统。任何一项技术（“术”和“器”），五年后都会过时。只有那些软件设计的原则和模式（“道”和“法”）是长盛不衰、永远年轻的。你只要熟练掌握这些原则和模式，就能轻松应对技术的更新换代。作为架构师或开发人员的你，无论是25、35还是55，都是年轻的。
|
|
|
|
|
|
**我们不但要让自己的系统保持长青，也要让自己，永远年轻。**
|
|
|
|
|
|
后会有期，希望我的专栏对你有启发。最后的最后，我想听听你学习这个专栏的感受，希望你花几分钟填一下后面的[毕业问卷](https://jinshuju.net/f/QVpM6L)。
|
|
|
|
|
|
[](https://jinshuju.net/f/QVpM6L)
|
|
|
|