“时隔 10 年,重新开始写代码的我要崩溃了!”

【CSDN 编者按】用“日新月异”一词来形容 IT 行业的变化,最为恰当不过了。本文作者于 20 年前是一位奋斗在一线的开发人员,10 年前晋升为管理层,而近日,他因工作需求,再次开启了自己的 Coding 生涯,而这一次,他却有了不一样的体验。

作者 | Doug Foo  译者 | 苏本如

出品 | CSDN(ID:CSDNnews)

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

这样带给我两个问题:

  1. 可供挑选的选项太多了。

  2. 这么多选项中,很多会失去支持而无法存活下去。

好的方面是:你几乎不需要构建基本的基础设施和工具,你只需要找到一个合适的选项并重用它即可。

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

声明:本文由 CSDN 翻译,转载请注明来源。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 代码科技 设计师:Amelia_0503 返回首页