19 现代化：如何避免落伍于行业？
你好，我是李云。这一讲咱来聊聊如何避免落伍这个话题。
这个话题的本质还是与职业安全相关，17讲时我们聊到，工程师需要通过打造软件设计能力去形成竞争壁垒，从而确保自己的职业安全。你可能会想了，这一讲探讨职业安全的角度又有什么不同呢？换句话说，这门课程为什么要设置这一讲？
就咱的工作经历，应当都观察到了一种现象，我们所掌握的工具和方法是受限于所在团队、公司的工作环境的。大多情形下，身边的人用什么工具和方法，我们也一样。这就有个问题，如果大家使用的工具和方法都是十多年前的，那是不是一种落伍呢？在这样的情形下，即便个人有很好的软件设计能力，相信工作起来质效也高不到哪去，只是不自知而已。
这就好比，一个木工师傅的手艺很好，别人用电锯他还在用手工锯，别人用电子水平仪他却用手工水平尺。这样的师傅手艺再好，生意也不会太好，因为不出活，别人不愿请。
还有，13讲我们聊学习方法时提到了目标牵引的学习方法。运用这个方法的前提是我们知道自己要什么，否则这个方法就用不起来。
那这一讲我们怎么来展开呢？软件行业的发展很快，各种工具层出不穷，场景不同方法论也不完全一样，一讲的篇幅要讲清楚不现实，何况我自己的经历也有局限性。考虑到这些因素，我想到的是先基于咱日常大致的工作场景，去介绍那些更现代化的工具和实践，这样你学起来更有体感，对课后的自我学习也更有指导作用。
工具和实践现代化
基于开发工程师在日常工作中的主要工作步骤，我画了下面这张图。注意，这张图是为了更好地介绍现代化的工具和实践而准备的，请不要在意其完备性和精确性。你可以基于自己的工作场景做定制和优化。
不过我得强调，在日常工作中，你应当有这张图中对应的每一个工作步骤才对，否则意味着你做事的专业度是不足的，做事的套路与软件行业的典型实践不一致。也许有些步骤在一些特殊的场景可以省略，但那与“一直没有”是两回事，这一区别我得提醒你，以免你将“没有”当作“特例”而心安理得。
你应当注意到了，有两种情形会触发图中一系列的步骤。第一种情形，是新功能的开发，从图中的“需求确认与评估”这个步骤开始；第二种情形，是修复软件缺陷，从“缺陷确认”这个步骤开始。不过，两种情形都是结束于将“代码合入”发布分支。
为了让你对“现代化”有更具象的认识，我将图中每一步骤涉及的工具和最佳实践，用下表进行了罗列，方便你就自己的工作环境进行对照。没有用到的，可以作为课后的学习目标；用到了但过时了的，值得找机会升级，以便跟上行业的发展。当然了，编程语言那么多，各语言主流的工具我没能一一列出。
- 需求管理/项目管理工具：禅道（有开源版）
- UML工具：Visual Paradigm（个人可用社区免费版）、PlantUML
- 设计文档编写工具：Markdown
- 版本管理实践：语义化版本
- 软件配置管理工具：Git（行业事实标准）
- 分支管理实践：git-flow、GitHub flow
- IDE工具：Visual Studio Code（免费且插件非常丰富）
- 构建工具：Bazel（非常适合跨OS项目的开发） 开发环境：Windows WSL
- 代码比较工具：P4Merge（免费，可与Git无缝整合使用）
- 静态分析工具：这个GitHub项目收录了各种语言的静态分析工具
- 动态分析工具：这个GitHub项目收录了各种语言的动态分析工具
- 代码评审工具：Review Board（开源）、Gerrit（Chromium和Android项目在用）、禅道（有开源版）
- 测试用例管理工具：禅道（有开源版）
- 缺陷管理工具：Bugzilla（开源）、禅道（有开源版）
你可能会想，哪些是自己用到了但过时了的呢？我发现软件配置管理工具是其中相当普遍的一个。如果你还没用上Git，那就代表不够现代化，因为Git目前是软件行业的事实标准，它相比上一代SVN这些产品有了质的飞跃。虽说Git的学习成本会高一点，但学好了用起来称手多了，这也是它能成为行业事实标准的根本原因，值得你跟进。
可能你的工作环境没有用上现代化的工具和实践，而且你还等着别人来推动再跟进，我的建议是：你可以成为主动推动这事的人。让整个团队用上现代化的工具和实践，在我看来这是一个很不错的绩效考察点，那代表了你的上进和积极主动。
在制作这张表时，背后有我的一些思考和洞察。接下来我想详细和你说说，能让你更好地理解我的意图，主要有这么四点。
第一，首选开源工具，以便你无需破费也能推进现代化。比如，表中的禅道研发项目管理软件就有开源版。如果你所在的公司已采用了类似的软件，那就用好就行了，没有必要另起炉灶搞一个。
第二，工具所保存的文件和各种文档，方便像代码那样管理是大趋势。比如，Markdown文档比Word文档存入到Git中更方便，可以使用代码比较工具直接Diff和Merge。再比如，尽管我有超过15年使用Visual Paradigm这个UML工具的经历，但PlantUML可以通过语言描述的方式绘图，与Markdown文档有着同样的优势，所以我也列到了表中。
第三，Bazel这个构建工具，是因为其出色的跨OS功能才列到了表中。每种编程语言都有自己约定俗成的构建工具，但对有些跨OS的大型项目来说，没有Bazel这样的工具，所带来的研发低效相当可怕。
第四，Windows WSL这个功能的出现，值得好好重视。对于绝大部分人来说，日常开发工作是在Windows、macOS、Linux中的一种或几种操作系统上完成的。从Windows 10开始，WSL成为了很重要的一个功能，使得不用安装VMware、VirtualBox这些虚拟机软件，就可以直接运行Linux，而且我们可以在Windows上，非常方便地与Linux互动。换句话说，Windows上的开发工程师，可以运用Linux上的开源工具，帮助自己提升工作质效。对于传统的嵌入式软件开发来说，可以通过打造跨操作系统的软件开发平台，更好地借力Linux上的开源软件去提升工作质效。
聊完工具和实践的现代化后，我们来聊一聊更大的话题，那就是研发方法论的现代化。
方法论现代化
一说到软件开发的方法论，那必须先说一说软件开发生命周期（Software Development Life Cycle，SDLC）。SDLC这个概念，是在20世纪60年代末到70年代初开始形成的，那时期软件行业正在应对软件开发成本指数级上升的“软件危机”，提出这个概念，是为了更好地管理软件开发过程，旨在通过定义明确的阶段，来系统化软件开发流程，从而提高软件的质量和开发效率。
SDLC的基本思想是，将软件开发过程分解为一系列阶段，如需求分析、设计、编码、测试、部署和维护等，通过明确各阶段的任务和目标，以确保软件开发的有序进行。这是应对日益复杂的软件项目的需要，使得软件开发活动更加规范化和可管理。
接下来我们聊一聊，几个当下特别值得关注的SDLC模型。
瀑布模型你一定知道吧？1970年提出的瀑布模型，是最早和最成熟的SDLC模型，是一种顺序和线性的方法论，要求完成前一个阶段的工作才进入下一个阶段。这个模型的特点是结构严谨，阶段顺序固定且清晰，过程文档丰富。不过，瀑布模型的缺点相当明显，当需求不清晰或易变时，它那严谨的结构就会暴露灵活性不足的问题，而且得等到整个软件产品开发完成，才能收集到用户的反馈，过程中稍有理解偏差，所造成的返工工作量就不小，由此带来的项目风险就很高。
瀑布模型作为SDLC的鼻祖出来后，软件行业为了应对软件开发的复杂性，又提出了好些方法论，下图以时间顺序进行了罗列。我们直接跳到2001年，那年敏捷宣言的出现，标志着敏捷软件开发方法论的正式面世。同年《敏捷软件开发》这本书的英文原版出版，2003年由人民邮电出版社引入了国内。
敏捷软件开发的核心，是在软件开发项目中运用“轻且够用”的原则，以及以人为本和以沟通为中心的原则。敏捷软件开发提出之前，行业已经有了近10年的时间，关注软件开发活动中的敏捷性，早年的SCRUM和极限编程都算。
敏捷软件开发是指一组基于迭代的软件开发方法论。与瀑布模型所不同的是，敏捷软件开发中的每个迭代，只会实现整个软件的一小部分功能，且力争每个迭代完成后，可以交付给客户。换句话说，相比瀑布模型一次性交付一个大而全的软件给客户，敏捷软件开发是一点一点增量地交付给客户的。
这样的好处有：
- 因为每次交付的功能少，软件产品的功能即便与客户真实的需要出现了偏差，也能更早发现，风险自然更小；
- 能持续并阶段性地获得用户反馈，用户也会在这个持续递进的过程中，更清楚自己最终要的软件是什么模样，通过反馈给软件开发团队尽早修正；
- 对于软件开发团队来说，因为有阶段性的成果，工作起来更有节奏感，阶段性成果也有利于团队形成良好的士气。
你发现了吗？敏捷软件开发的思路，与我们定阶段性的学习目标是一回事。学习目标如果定得太大、太远，那么我们走着走着，会因为没有阶段性的成果而更难坚持下去，使得达成学习目标的风险更大。反过来，如果定的是阶段性的学习小目标，那走起来就更有力、更坚定。
下图示例了敏捷软件开发中，以一个个迭代滚动向前的形式，来完成整个软件的开发。这张图与本讲最开头的那一张有点像，为了避免你产生困惑，我得强调一下，那张图是从软件开发工程师视角去组织的， 而这张图是从软件产品的开发去组织的，里面会包含产品经理、开发工程师、测试工程师和项目经理等角色的工作内容。背后隐含了敏捷软件开发所倡导的一点，也就是让各种岗位的人紧密地在一个项目组中协作。
敏捷软件开发中，提升开发质效的另一个关键实践是，通过持续集成（Continuous Integration，CI）和自动化测试。频繁地将新的代码集成在一起，通过自动化单元测试，自动构建和自动集成测试，让整个软件出现问题时，能第一时间发现并让人跟进处理。在18讲时，我们专门讲到了单元测试，这里补充一点，落实单元测试的另一个好处，是通过自动化单元测试，可以提高持续集成的质量。
为什么会有“持续集成”这个词呢？因为在采用瀑布模型的软件开发项目中，让大家最痛苦、风险最大的环节，正是将每个软件模块、组件、子系统集成到一起的那个阶段，各种问题都会暴露出来。解决这种问题的办法，就是早点集成、频繁集成，所以就有了“持续集成”这个概念。
除了持续集成这个概念，持续交付（Continuous Delivery，CD）和持续部署（Continuous Deployment，CD）两个概念，也是敏捷软件开发运动背景下产生的，是对更快速、更高效软件开发和发布流程的追求。
正因为敏捷软件开发有助于提升软件开发的质效，所以掌握这一方法论就是一种技能现代化的行为。你可别以为敏捷软件开发只是形式上的那些变化，最关键的，是对工程师的自我管理等能力提出了更高的要求，也需要整个项目团队有拥抱变化和包容犯错的文化氛围。换句话说，敏捷软件开发对个体的能力和团队管理都提出了更高的要求，如果没有意识到这一点，那就没法发挥它的优势。
注意一点，敏捷软件开发只是提升了软件开发的质效，但有些软件产品，除了软件开发团队外，还有软件运维团队。当软件开发走的是小步快跑的迭代模式时，意味着要发布的软件版本的数量会多得多，如果软件运维团队不提升自己的效率，那最终就会变成瓶颈。另外，开发与运维团队只要配合得不紧密，就难免出现工作上的失误，最终给用户带去不好的使用体验，甚至带来公司的资产损失。
还有，如果发布的软件存在缺陷，仅靠用户反馈而得知再处理会比较被动，如果我们能自己发现那就能起到主动预防的作用。
为了改善以上这些问题，2009年行业提出了新的DevOps方法论，如下面这张图所示。
DevOps的核心理念是，开发和运维团队要更紧密地协作，共享责任、持续改进和优化工作流程。其中进一步包含为软件产品构建的监控设施，让开发和运维团队有可能先于用户发现自身软件产品的问题。随着DevOps文化的发展，持续部署和持续交付成为了现代软件工程的重要组成部分。因为云计算技术的蓬勃发展，2015年前后，行业又进一步提出了DevSecOps方法论，增加了安全这一关键要素。
值得强调，DevOps并不是取代敏捷软件开发的方法论。敏捷软件开发聚焦的是软件开发的质效，DevOps聚焦的是软件运维的质效，两者可以认为是相辅相成的关系。
总结时刻
接下来是对这一讲学习内容的集中回顾，帮助你巩固记忆。这一讲我们聚焦于从行业的发展水平，来审视个人的技能和行业视野，探讨了工具和实践的现代化，以及方法论的现代化。
从工具和实践的角度，我们先梳理了软件开发工程师的日常主要工作步骤，然后基于那些步骤给出了需要掌握的工具和实践，帮助你更有体感地审视自己的日常工作，看是否存在落伍于行业的现象，也便于你找到课后学习的新目标。
从方法论的角度，我们主要聊到了瀑布模型、敏捷软件开发和DevOps三种SDLC。尽管SDLC的具体实现方式随着时间的推移而发展变化，但通过规范化的过程来提升软件开发质量和效率的核心思想一直没变。我们了解SDLC的目的，有助于更好地理解软件行业的发展，背后是对个人的技能和团队的管理提出了更高的要求。当我们不知道那些新概念，不实践那些新方法论，背后或多或少都意味着落后于行业。
对了，你可能会问我，“我如何才能把握住行业发展的脉搏，让自己能及时跟上行业现代化的步伐呢？”这是非常好的一个问题。
就我自己的经验，主动的好奇心并建立起意识是最重要的。现在是资讯非常发达的时代，微信朋友圈和公众号、CSDN和InfoQ这类门户网站都能及时看到新技术的讨论、布道文章，有意识地花时间阅读就能了解趋势。当然了，这种行为需要培养成习惯才对，因为新技术也不是一天突然就成熟的，都有个窗口期，阅读习惯能让咱在这个窗口期中就耳濡目染地掌握，甚至突然领悟而做出自己的判断。咳，还是有方法没捷径的事。
最后，我想请你思考，云计算的出现给个人技能的现代化带来了哪些机会呢？期待你留言与我分享交流。
我们下一讲见。
- SMTCode 👍（3） 💬（1）
在云计算出现之前，为了使用先进的工具（如devops），需要搭建运行工具的机器或集群，这个过程本身就是一个很有挑战的（当然不考虑高可用等前提下，搭建一个自己用的简单环境不算）。而且向新工具的迁移也很费精力，关键这些工作都是一种隐形的成本，不能带来直接的业务价值，很难成为个人成果或绩效评价的关键指标。但随着云计算和公有云厂商paas化服务的出现，将这些基础设施平台化了，通过简单的几步就能完成工具环境的搭建，而且还自带高可用自更新等各种可靠功能，这样就使我们能更多的将精力集中到能给产品带来价值的业务需求上去。也能让我们低成本的快速验证新的模式是否适合公司的业务等等。云计算为新工具的实施极大降低了门槛，这反过来也提高了可替代性，增加了软件工作人员的职业焦虑，但换个思路去想：不迎合技术的大趋势，淘汰的速度更快。软件行业就是这样，活到老学到老，有底层基础，再进行新技术尝试，总能有更深刻认识。但一切都是一把双刃剑，如何舞好这把剑，是一种能力，是一种眼界，更是一种气魄。世界唯一不变的是变化本身。调整好心态，收拾好行囊，随时出发，随时改变。用心生活总能看到美好的风景。
2024-04-20