上个月，我关于用 shell 脚本编写 Blackjack 游戏的系列文章结束了。我不知道你们怎么样，但我在开发过程中很愉快，甚至对游戏本身也有了更多的了解。我收到了读者关于专栏的一些有趣的电子邮件，但也收到了一封最发人深省的邮件。

作者批评我，因为我在洗牌程序等事情上使用了次优算法，脚本编写风格也很差，并且总体上质疑我对 shell 脚本编程到底了解多少。

在互联网上生活了将近 30 年，我对抨击和充满敌意的电子邮件非常熟悉，人们吹毛求疵，只关注叶子的分子，甚至不知道前面有一片森林。但这条消息仍然让我开始思考脚本编写和一般编程的实践。

引用我的同事 Ken McCarthy 的话，更好的策略是什么，不完美的行动还是完美的无动于衷？

尽管 Bourne Again Shell 功能非常强大，并且确实具有更复杂的编程语言的所有基本编程结构，但我认为说它是一个轻量级的，甚至是可抛弃的编程环境仍然是公平的。你不会用 shell 脚本编写大型、复杂或任务关键型应用程序，对吧？

这就是我一直以来编写 shell 脚本的方式——基本上是作为一个快速原型环境。你想知道一个文件有多少行？可以使用类似这样的命令

lines=$(wc -l < $filename)

这是最优雅和高效的解决方案吗？可能不是。实际上，如果你这样做是为了测试文件是否具有非零内容，你应该使用 test 命令来代替，但我的重点是：这真的不重要。

这就是我所说的不完美的行动。开始编写你的脚本，构建一个粗糙的原型，完成它，远比在截止日期后两周的凌晨 3 点还在调整、清理、微调、重写和优化要好得多。那是完美的无动于衷，对吧？热衷于等待、等待、微调和推动，直到它真正完美，但到那时你已经错过了你的截止日期和目标。

所以，当我收到这位读者的批评，说我没有选择最好的算法，也没有使用他认为最佳的脚本编写技术时，我很高兴看到他是如何认为事情应该完成的。但我也并不感到惊讶，因为我认为软件开发人员面临的最大挑战之一是认识到，在许多情况下和情况下，“足够好”真的就是，嗯，足够好了。

我是在提倡下次你为波音 777 的飞行控制器编写固件时，应该偷工减料，跳过测试，编写糟糕的代码，以便按时交付吗？当然不是。但是你知道吗？如果你正在编写一个测试框架 cron 脚本，它只是记录测试的开始，调用一系列 MySQL 查询并记录测试的结束，那么，是的，在这种情况下，相对糟糕的代码，足够好用的代码，可能正是所需要的。

我在偶尔收到的购买了我的 Wicked Cool Shell Scripts 书籍的人的来信中也看到了这种完美主义态度。他们没有意识到编写 shell 脚本本质上是一种粗略的原型设计练习（因此缺乏复杂的 shell 脚本开发环境和测试框架），而不是一个完美代码是数字圣杯的编程世界。

我也认为，这些相当势利的软件开发人员，他们崇拜优雅，并对那些仍在编程道路上蹒跚学步的人开发的软件不屑一顾，这对计算机世界造成了巨大的损害。

别误会我的意思，当我阅读代码时，我欣赏巧妙的算法和简洁的实现，但大多数软件和应用程序的真正创新都来自那些凑合的人，来自粗糙的原型和“勉强 beta”的软件，这些软件足够好用，可以演示概念并让社区开始尝试。

你们中的一些人无疑对我在专栏中提出的观点感到有些困惑——困惑的是，一个本应教你 shell 脚本编程技巧的人实际上却在提倡马虎的代码和快速的“抛弃型”脚本。我想反问的是，为什么你们会对“尽快完成某件事，快速且合理地解决问题，通常比浪费——是的，浪费——时间编写“完美脚本”更好”的想法感到惊讶呢？

这让我想起了多年前我在加州大学圣地亚哥分校上的一门计算机编程课程。我们的挑战是为给定的情况找出最佳排序算法，并编写一个实现它的程序。班上几乎每个人都在苦苦挣扎，但我拿出了 Knuth 的 计算机程序设计艺术，挑选了他推荐的算法，并将其输入，并附上了适当的引用。我因“作弊”而受到惩罚，不得不坚决辩称，事实上，没有比参考该主题的权威著作更好的学习如何选择最佳排序算法的方法了。最终，教授让步并给了我满分。

Shell 脚本编程也是如此：快捷方式总是好事，效率是衡量你解决问题速度的指标，尽管调整和微调作为一种智力练习可能是有益的，但在一天结束时，90% 的时间里它都无关紧要。

好好想想。并问问自己，你是如何在朝着不完美的行动努力，而不是陷入试图实现完美的无动于衷的困境。

下个月，我们将回到 shell 脚本编写的实质内容。但是，请不要期望我编写完美的小脚本，或者为给定的任务使用世界上绝对最好的算法。事实上，有时我的代码会效率低下，会产生比完全必要的更多的子 shell 或子进程，甚至可能存在不必要的循环和条件语句。也许，仅仅是也许，这也没关系？