“时隔 10 年，重新开始写代码的我要崩溃了！”
共 3676字，需浏览 8分钟
·
2021-05-12 14:03
用“日新月异”一词来形容 IT 行业的变化，最为恰当不过了。本文作者于 20 年前是一位奋斗在一线的开发人员，10 年前晋升为管理层，而近日，他因工作需求，再次开启了自己的 Coding 生涯，而这一次，他却有了不一样的体验。
以下为译文：
20 年前我是一位前线编码人员，10 年前我转向开发管理，现在我又成为一名需要编码操作的开发顾问。在开始这份工作之际，我对编程行业的一些变化感到惊喜莫名，同时也对其他变化感到惊讶万分。
本文我将解释一下是什么几乎要将我压跨。
Unix 又回到了开发者的身边
在整个 80 年代和 90 年代初期，许多专业软件都是在昂贵的 Unix 工作站（比如 Sun Sparc 或 NeXT 工作站）上开发的。到了 90 年代，WinTel 后来居上，几乎每个人都在 Windows 上使用微软的 Visual Studio 之类的大厂商提供的开发工具或者 Eclipse 之类的开源开发工具进行编程工作，而 Linux 那时只是在桌面电脑上有少许爱好者。
2001 年，我在一家初创公司工作，当时只有一位开发人员使用 Linux，在没有任何源代码管理（SCM）工具和 Outlook 电子邮件的情况下，他工作得非常艰难。他经常给我们发求助邮件，让我们帮他提交代码。我记得那时我使用的是XEmacs——是的，那是个经典软件。
快进到现在。Unix 已经成为一个非常流行的开发平台，特别是在 Mac 电脑上（因为它的 Unix 内核），同时 Linux 在 Windows 上也有广泛运行（因为 WSL）。这是我很容易回到的一个领域。有趣的是，我的一些年轻同事几乎不知道如何使用 Windows，相反，他们非常擅长 Linux/Unix！
版本经理不再需要
在过去，代码分支、合并和解决冲突是一项可怕的工作，有时需要版本经理的专业技能。当软件配置管理（SCM）工具的庞然大物 ClearCase 流行时，需要有一个庞大的团队来维护和管理代码分支、代码合并和代码发布（至少基于我 2002 年在 HP 的经验是这样）。
自我管理的拉请求（PR）的概念实际上是一个非常新的概念，显然来自基于 Linux 平台的开发和分布式 SCM（比如BitKeeper和Git）的新浪潮。能够请求在工作流中进行合并是像 ClearCase、CVS、SVN 和 PerForce 这样的老系统所不具备的。这个工作可以由代码库所有人或版本经理来做，也可以由每个开发人员自己执行。这确实简化了流程，让用户能够独立协作。
QA 测试团队在哪里？（单元测试/持续集成）
我第一次了解单元测试和持续集成（CI）是通过 Kent Beck，他是 Agile Manifesto( 敏捷宣言)的奠基者之一，也是极限编程的发明者。20 年前这些都是革命性的，但是需要一些时间才能在开发工作流程中达到当前的标准化。
不幸的是，我发现持续集成在敏捷（Agile）和 Scrum 中没有得到更多的强调，但我很高兴看到它在现在得到了很好的采用。
我参加过一个软件开发会议，还记得在一个讨论单元测试的小组会上，看到 Java Collection的 作者 Josh Bloch 站在台上说：“感谢（Agile 或 JUnit）让测试变得富有魅力。”
这是事实。在过去，编写测试程序是一件非常枯燥和不受欢迎的工作，所以公司雇佣 QA 测试工程师致力于为你找出所有的错误！哇，多么轻松的生活…
单元测试和持续集成几乎消除了对黑盒 QA 测试人员的需求，因为开发人员现在拥有测试程序编写和持续集成的基础设施，并且可以运行测试并获取测试报告。它确实使软件变得更可靠，开发周期更快。它还能够促使程序员更全面地思考问题，并且以更友好的方式编写代码。
开发->测试->产品环境问题消失？（Docker）
容器，即 Docker，在你将代码通过 QA 发布到生产环境中时，它确实简化了打包过程并减少了与环境相关的问题（所付出的代价是让一个好的 DevOps 工程师建立一个 Docker 生态系统）。
在过去，你会在一个与部署系统完全不同的系统中进行开发（比如 Windows 上编写代码，然后部署到Unix），这必然会导致 bug，并导致在每个测试和发布周期中需要进行更多的工作。
此外，在过去，开发、测试或 DevOps 工程师们会依据 SCM 标签来从相应的分支中提取代码，并找出如何编译、测试和迁移它的方法。通常他们会发现一大堆硬编码的路径和变量，或者丢失的库和文件，这些都需要重新设计或修改编码/配置文件才能让其正常工作。
Docker 通过再次授权程序员自己构建和测试 CI 和 CD，从而真正简化了流程，并保证了持续集成和持续部署的实现。
开源软件（OSS）选项太多？
在当前这个开源软件风行的世界里，人们拥有太多的选择。当我设置 Jenkins，并希望将其集成到 BitBucket 时，我用“bitbucket”关键字作插件搜索，得到了 400 多条结果（多数是开源软件）。
图片来源: Atlassian Search
这样带给我两个问题：
可供挑选的选项太多了。
这么多选项中，很多会失去支持而无法存活下去。
好的方面是：你几乎不需要构建基本的基础设施和工具，你只需要找到一个合适的选项并重用它即可。
20 年前，构建基本库和数据结构是一种“乐趣”。如今，每种编程语言都有了现成的框架和库，99% 的开发人员不再需要编写 b 树、hashmap，甚至 OAUTH 连接器。
敏捷(Agile)和 Scrum 已经占据主导
尽管 Agile 在20年前就已经存在（敏捷宣言可以追溯到 2001 年），但它的广泛采用却是最近的事情。甚至在软件行业之外有时也会出现一些变种。敏捷，已经成为 CxO 们的一个时髦术语（“你的业务必须敏捷才能生存”）。
我记得以前的软件发布周期相当地长（在一家初创公司通常要长达三个月）。在参加软件规格说明会议并且彻底了解需求之后，开发人员可以到他们的办公桌上玩几个星期的游戏，而不必发布他们所负责部分的任何更新。现在情况变了，你有一个每日进度例会和每两周的冲刺计划，所以你不能有丝毫的懈怠！
随着敏捷的发展，BA（需求分析师）的作用也在削弱，因为开发人员现在直接面对用户或产品经理。你不能再躲着不说话了。因此，开发人员的沟通技巧比过去重要得多。
Tom Smykowski:
好吧，听着，我已经告诉过你了：我和该死的客户打交道，这样工程师们就不用这么做了。我有交际能力，善于与人打交道。你不明白吗？你们这些人到底怎么了？
引自Tom - 需求分析师/需求分析经理（资料来源：Office Space）
敏捷使开发速度加快了很多。它不仅仅是 Scrum 的例行程序和每日进度更新例会。敏捷工具包使得开发效率更高，JIRA 看板、拉请求（PR）和CI/CD都让你走得更快。虽然日常工作更加有点忙，但能更快更全面地完成这些工作也是非常令人欣慰的。
结束语
如果你考虑进行一个类似的旅程，那么开始吧，祝你好运！我享受我的技能更新的快乐（尽管它几乎把我压垮了）。软件工程的基本原理是一样的，所以我认为我可以生存下来，但是工具已经发生了巨大的变化，这极大地提高了生产力。
在本文中你可能感受到的一个印象是，今天的开发人员比 20 年前有更广泛的任务集。他们编写代码、管理 SCM、与用户沟通、测试自己的代码、构建和部署容器等等。这可能令人难以理解，但是至少他们不再需要编写链表了。
参考资料
1. 极限开发（XP）
https://en.wikipedia.org/wiki/Extreme_programming
2. 敏捷开发（Agile）
https://www.mckinsey.com/business-functions/organization/our-insights/the-journey-to-an-agile-organization
原文链接;https://betterprogramming.pub/how-going-back-to-coding-after-10-years-almost-crushed-me-88c85ceb5376
2021-05-08
2021-05-07
2021-05-06
