Don Jones 谈 PowerShell、职业成长与第一位追随者

Jane Street 的一位主持人欢迎大家参加 PowerShell 聚会，并介绍 Windows 团队广泛使用 PowerShell 自动化基础设施。组织者邀请首次参加者和有意演讲的人加入每月的社区聚会。

我在 PowerShell 于 2006 年 11 月发布之前就开始使用它了。Jeffrey Snover 在 TechEd Europe 推出它时邀请我一起上台，从此我们一直是朋友和同事。我还参与创办了 PowerShell.org，并与组织其峰会的伙伴们共事。

我想把塑造我职业生涯的经历与一些实用的 PowerShell 习惯联系起来。回顾过去很重要：看似无关的经历，只要你认识到它们如何为下一步做准备，就能变成自己的优势。

十几岁时，我帮忙举办《星际迷航》大会。有一次，Denise Crosby 为慈善拍卖了内衣。我们要支付酒店、机票和嘉宾费用；早在我把自己看作生意人之前，就学会了预算和日程安排。

在 Electronics Boutique 工作，又以另一种方式教会了我很多。经历就像箭袋里的箭，日积月累。认识到以前的工作如何塑造了你的思维，你就能在下一份工作中有意识地运用这些优势。

一位升学顾问告诉我，我数学不好，不能从事计算机工作。我没有上大学，而是在 Virginia Beach 的一所职业学校学习电子技术和计算机维修。

海军招募民间员工，为包括 F-14 在内的飞机进行基地级维修。在漫长的学徒期里，我学习了整架飞机的工作原理，还练习寻找最快、最省钱的方式，让受战损的飞机重返服役。

那段训练让我把生活中的许多事看成工程问题：我在哪里，要到哪里，关键路径是什么？小屋里结冰的水管爆裂时，我们必须迅速判断能否恢复供暖和供水，还是必须离开。

临时修复只要能让飞机重新起飞，就不一定要漂亮。但记得之后再回来彻底修好；IT 从业者有时在紧急情况过去后会忘记这一步。

那座设施在 20 世纪 90 年代初关闭后，我做过零售，最终成了一名 AS/400 操作员。我对那台机器所知甚少，甚至需要别人告诉我它是一台计算机。我知道的大部分东西都是在工作中学会的。

我以 VBScript 为基础建立了职业生涯，还与 Jeff Hicks 合著了书。后来 PowerShell 出现时，这种学习习惯帮了我：我必须边实验边学习。即使是一段不情愿的绕路，只要让你学会如何学习，也能成为财富。

想象一个函数同时有计算机名参数和文件路径参数。我宁愿让它只做一件事：接受计算机名。你可以在别处从文件或数据库读取名称，再把它们传给函数。

否则，每增加一种来源，函数就多出一个参数：今天是文件，明天是 Active Directory。不断增加的复杂性会让维护更加困难。保持组件小巧，利用整个系统组合出你需要的行为。

一位听众问，这是否意味着总要使用管道。不是：要理解系统，按它的设计方式使用。例如，你也可以将一个集合作为参数传入。这不是必须遵守的仪式，而是为工作选择合适的机制。

输出端也有同样的问题。工具应该把结果输出到管道，而不是不断增加单独的文件或 CSV 参数：另一个命令就能把结果写入文件或数据库。

初学者常犯的错误是在函数内部使用 Format-Table。屏幕上的结果可能很好看，但在这里格式化数据会大大降低它对下游命令的用处。等到有人需要这种呈现方式时再格式化输出。

遵循 PowerShell 的动词—名词命名惯例，使用认可的动词，不要发明自己的命名体系。熟悉这一环境的人应该无需学习一套私有词汇，就能理解你的命令做什么。

另一个示例输出两种不同类型的对象。Jones 认为，混合输出类型会让 PowerShell 的使用者更难处理结果。更好的办法是将相关属性组合成一个自定义对象，再把这个对象传入管道。

我区分工具和控制器。工具执行小型通用操作，不需要知道业务情境。控制器为特定流程组合工具，例如生成报告、展示菜单、写入 CSV 或配置用户。

保持通用工具简单，将与情境有关的决定放进控制器。工具越小，单元测试就越容易编写。一位听众指出，这与软件设计中的单一职责原则有关。

遵循成熟的软件工程实践，也会改变别人看待你工作的方式。你不只是写脚本应付日常工作的人，而是在构建可能支撑关键业务流程的工具。

在这场 2019 年的演讲中，我建议避免使用 Write-Host，尽管后来的版本已将它连接到信息流。我更喜欢使用 Write-Information、Write-Verbose、Write-Warning 和 Write-Error 等明确的命令，让目标流一目了然。

我也反对在脚本中使用全局变量，因为代码可能在处理全局状态方式不同的宿主环境中运行。模块级变量的作用域更窄；一位听众提出的 GUI 示例通常可以改用脚本级变量。

我不建议在类外使用 return，因为它的行为可能误导那些期待其他语言中 return 语义的人。PowerShell 在 return 之前就可以输出值；我更喜欢明确的输出和控制流。在类内部，return 的用途有所不同。

另一项需要说明的是演讲时 PowerShell 类的情况。我认为大多数任务更适合用函数表达；类可以定义结构化对象，但如果要大量使用类，我建议考虑 C# 及其工具。

格式化代码并做好缩进，让别人能够读懂。当时我建议使用 VS Code，替代日渐老旧的 PowerShell ISE，并提到新出现的 Windows 终端是较新工具环境的一部分。

将小函数放进模块，用控制器脚本把它们组合起来。用户配置流程可能依次调用几十个小工具。选择合适的输出流，也要考虑运行脚本时是否会有人在旁观看。

学习 Pester，并尝试测试驱动开发：写下输入和输出，为期望的行为编写测试，然后实现工具，直到测试通过。在这个过程中，测试也成了功能规格。

使用现代版本控制，并为代码编写文档。好的命名能让明显的操作不言自明，因此注释不必重复每一条命令。但仍要提供真正的帮助文档，无论是基于注释还是从 Markdown 生成。

我写的关于帮助他人的书和练习册要求读者写下目标。我认为亲手书写以及有意识地营造学习环境，有助于记住想法。Jones 将此作为对记忆与感官如何相互作用的一种解释。

为学习留出专门的时间和空间，不要以为在不断受打扰的工作环境里看一小时视频，就能自动记住所学内容。他的实际建议是持续专注于材料，并创造有利于专注的条件。

我也开始关注通才的价值：他们能够充分胜任各种任务，推动项目向前。翻修我们的小屋意味着要做水管、电工、木工和铺地板等工作，即便成果并非完全整齐。

在 Electronics Boutique，我们的经理教每位员工开店、关店、清点钱款、接收货物和联系总部。这种要求让我对业务的了解远比狭窄的岗位职责所能提供的广泛。

后来，我作为 AS/400 操作员主动学习使用一套新的电话交换机。一次暴风雪期间，我重写了一个麻烦的销售终端程序，经理为这项工作付了钱。反复出现的教训是：根据情况需要学习。

不要让自己在组织架构图中的位置成为身份。雇主拥有岗位，应为你胜任工作提供条件；你的职业生涯则属于你自己，包括这份工作结束后可能需要的技能。

这可能意味着买一本书、寻找培训，或搭建实验环境，学习当前岗位不要求的技术。一位朋友错过了薪酬和福利更好的机会，因为他一直没有学习一项他知道自己需要的相邻数据库技能。

你可以热爱自己的公司，同时继续投资自身发展。裁员、公司倒闭或一个诱人的新机会，都可能暴露出擅长眼前工作与拥有灵活职业生涯之间的区别。

DevOps 不是买回来安装的产品。我把它描述为组织 IT 运营的一种方式，以实现预期成果，尤其是快速、反复地部署软件。如果那不是你需要的结果，单纯照搬这个标签没有用。

在传统组织方式中，项目经理、设计师、开发人员和基础设施团队隔着一堵堵墙交接工作。运维负责部署，出了问题就要承担指责，即使他们几乎没有参与构建过程。

Jones 批评繁重的变更控制流程阻碍快速交付。在他看来，频繁进行小幅变更更容易定位和回退故障：一次部署如果只包含一项变更，需要调查的范围就比大型发布小。

以产品为中心的组织则让相关专业的人员加入同一个团队。大家共同关注的是客户获得什么，而不是各部门是否完成了自己独立的交接。

请客户画一张草图，描述他们认为你的组织在做什么。他们不太可能画出一个负责 IP 地址电子表格的团队，以及互相隔离的 Windows 和 Linux 团队。围绕客户成果组织，能让组织结构更容易与实际价值联系起来。

一个人可能同时参与多个产品团队。为了让这些团队的专业实践保持一致，Jones 介绍了专业社群：开发人员、设计师或系统工程师在其中交流标准，并作出相互兼容的决策。

在他的公司，首席专业人员在团队之间流动，参与实际工作，传播有用的实践，并帮助业务负责人评估专业发展和晋升。不同组织可以用不同方式实现相同的基本理念。

大型组织需要领导层支持，因为这种变革会影响招聘、优先级和人力资源。但公司不必一次重组所有部门：从一个产品开始，了解什么有效，然后边实践边调整结构。

向管理层介绍这个想法时，要说明预期成果和需要进行的组织变革，而不是兜售流行词。决定不提供资金也可能是合理的；此时个人需要决定什么样的工作环境适合自己的职业生涯。

不要只当一个到处寻找钉子的锤子。学会足够多的知识，为问题选择合适的工具。不同产品团队可以使用不同的语言，只要这些选择有助于完成各自的工作。

例如，尽管 PowerShell 支持跨平台，我仍可能因为 Python 的生态成熟而用它自动化 Linux。学习另一门语言需要付出努力，但我当初也学会了 PowerShell；任务需要时，我可以再学别的东西。

我认为雇主越来越需要能够跨技术栈学习并适应需求变化的人。你不必成为每一种工具的世界级专家；有价值的习惯是迅速学会足够多的知识，从而取得进展。

Jones 认为，技术已成为远不止软件行业的企业的核心。他对比了背负旧系统的老牌公司与能够快速构建和发布产品的小型新进入者，说明适应能力和产品上市速度的重要性。

一段独自跳舞的视频展示了另一种领导力。一个人加入舞者，邀请其他人，很快就形成了一个群体。一个人做时看起来很奇怪的事，随着参与者增多，也变得更容易加入。

这里的关键是第一位追随者。领导者可能提出不同寻常的想法，但第一位追随者向其他人展示了如何加入。Jeffrey Snover 曾播放那段视频，称自己是舞者，而我是 PowerShell 的第一位追随者。

担任这个角色不需要成为最顶尖的专家。许多人通过我的书或课程第一次接触 PowerShell，但我喜欢教授最初的概念，让他们之后能向更高级的老师学习，最终自己创造东西。

有人告诉我，迈出第一步改变了他们的工作或家庭的发展轨迹。我的回应是：去帮助其他人。偶尔回头看看，伸出援手；你知道的某些东西，别人可能还没有学过。

几年前，我在 Las Vegas 创办了一本面向酒店礼宾人员的杂志：餐厅付费刊登菜单，组成一份集中、持续更新的参考资料。这个想法很有前景，但经济衰退到来，餐厅开始削减开支。

当这项业务明显走下坡路时，我们选择退出，没有把它当作道德上的失败。花时间做试点，发现想法行不通，记录原因，再尝试其他办法，这没有什么问题。

失败可以帮助你判断是继续迭代还是停止。分享背景，而不只是给某个产品下“很差”的结论：你想完成什么，期待什么，它在哪里失败了？这样别人才能决定哪些教训适用于自己。

Jones 以 Windows PowerShell Workflow 为例：在他看来，这是一个好想法，但实施失败了。团队仍然可以从经历中学习，而不必假装结果是成功的。

《星际迷航》粉丝能为一处不一致编造精巧的解释，例如没有声音的传送装置，但真实原因可能只是制作失误。软件中也有这样的意外，后来用户依赖上了它们，因此很难移除。

Jones 将 PowerShell 的 filter 结构描述为历史遗留：一次版本控制回滚后，它留在了产品中，用户逐渐依赖它。他想说明的是，并非每个别扭的功能背后都有宏大的设计理由。

在演讲结尾，我说明自己正从 DevOps Collective 退下来，转向企业管理和战略。新作者将接手 PowerShell in a Month of Lunches 系列书籍，新团队也将继续社区的会议工作。