对 PowerShell 脚本游戏的思考

我还要明确一点，对于那些还不熟悉 PowerShell 的人来说，当在 PowerShell 提示符下交互使用它时，如果它可以帮助您高效地完成工作，那么一切都会顺利。但是，当您创建脚本化的 PowerShell 解决方案（将继续存在）时，准则会有所不同。

确实，过去这组比赛的挑战很复杂。坦率地说，我什至不确定我该如何开始其中的一些。也就是说，我们最终仍在讨论 PowerShell 脚本。在我评判的条目中，让我印象深刻的一件事是，我经常感觉自己在阅读 Visual Studio 项目的源代码，而不是 PowerShell 脚本。一方面，这可以被认为是一件好事：PowerShell 足够灵活，可以创建从基本脚本到我查看的条目类型的任何内容。但话又说回来，如果您有足够的技术能力来编写像我读到的代码，您可能可以创建一组“真正的”编译工具。在开发过程中的某个时刻，您可能会问自己是否正在创建 PowerShell 脚本或已经超越了脚本，也许脚本不是正确的解决方案。是的，游戏条目需要是 PowerShell 脚本和模块，但是您正在做什么呢？

即便如此，这还是让我想到了下一点：可维护性。测试这一点的最佳方法是将您的脚本文件交给其他人（最好比您拥有更少的 PowerShell 知识），看看他们是否可以理解您的脚本的用途和方式。我读到的许多条目都是庞大而复杂的函数、脚本和 .NET 代码。在很多情况下，我都面临着尝试弄清楚到底发生了什么的挑战。如果“我”必须努力弄清楚脚本或模块的所有部分是如何工作的，请考虑一下您的同事，当您升职时，他会向您提供解决方案以进行维护或故障排除。或者你可能会在 6 个月后回来。

评论不会受到任何惩罚。我鼓励初学者先写评论，以便他们可以组织和计划他们的工作。对于模块，您还可以编写自己的“关于”帮助主题。在我看来，此类信息与您正在使用的 PowerShell 命令同样重要。

最后，我通常担心语法和语言选择。是的，我知道总会有例外。当 cmdlet 可以时，不要诉诸于使用 .NET 类。在命令名称中使用标准动词和有意义的名词。但也许对我来说最大的烦恼是继续使用 Return 关键字。

每当我看到 Return 关键字时，我就感觉脚本作者还没有完全掌握 PowerShell 范例。按照我的想法，我们不会返回值，而是将对象写入管道。我唯一一次使用 Return 是当我有意退出脚本或函数并优雅地终止一切时。通常，当我看到 Return 的使用时，我还会看到很多不必要的辅助函数，每个函数都旨在“返回”某些内容。这只会增加您工作的（不必要的）复杂性。再加上缺乏文档，你就会得到一堆混乱的、我们称之为次优的 PowerShell。

精心设计的 PowerShell 脚本文件可以是一件美丽的事情。

管道打开，
物体绽放带来欢乐
格式为幸福

你怎么认为？您在公司或野外看到过什么好的、坏的或丑陋的事情？