自動化の道具箱としてのシェル技能
9月20日に公開された技術エッセイは、シェルを学ぶことで、ソフトウェアエンジニアが日々の仕事に取り組む方法が変わり得ると論じている。グラフィカルな操作画面の制約を受け入れるのではなく、既存のプログラムを組み合わせられるためだ。著者のウィル・ケレハーは、端末で単発のコマンドを実行する段階から、ループ、条件分岐、パイプラインを備えたスクリプトを作る段階へ進んだ経験を、初めてプログラミングを学ぶことになぞらえている。
主張の中心は懐古ではなく実用性にある。グラフィカルなツールは、設計者が想定した作業にはうまく対応できるが、特殊な仕事や繰り返し作業には、プログラムで操作できるインターフェースが必要になることが多い。ケレハーは、失敗するまでテストを繰り返し実行すること、ディレクトリ内の全ファイルに処理を適用すること、リントとテストを並列に実行することなどを例に挙げる。コマンドを大きな処理の部品として扱えれば、こうした仕事は容易になる。
エッセイは、個人のシェル習熟度をチームの保守作業にも結び付けている。ビルド、デプロイ、検証、テストのロジックは、BashやZshなどのスクリプトに記述されていることが多い。そのコードを無理なく読めないエンジニアは、出来上がったツールを使えても、問題の診断や改善はできないかもしれない。その結果、重要な運用ロジックを理解しているのがチームの少数のメンバーだけになる恐れがある。
適切な抽象化の水準を選ぶ
ケレハーは、あらゆるプログラムにとってシェルスクリプトが最善だとは述べていない。準備が少なく済み、プロセス同士を自然につなげられるため、コマンドラインツール間の比較的単純な連携に向いているという。豊かなデータ構造、複雑なロジック、広範なテストが必要な作業では、汎用言語の方が保守しやすい場合がある。
記事では、テストランナーを繰り返し起動する短いシェルのループと、同じプロセスをNode.jsから起動する際に必要な追加の準備を比較している。また、使い慣れた言語の構文を保ちつつ、コマンドの連携を改善する選択肢も紹介する。一例はJavaScript向けのスクリプトツール`zx`だ。PythonとRubyも、小さなプログラムで定型的な記述を減らせる選択肢として挙げられている。
より広い教訓は、構文がシェルの能力の一部にすぎないということだ。ケレハーは、利用できるプログラムとその振る舞いを知ることの方がはるかに重要だと見ている。新たに覚えたツールはすべて、それまでに使いこなしていたツールと組み合わせられるからだ。別の言語に書き換えたスクリプトでも、作成者が基礎となるコマンドの動きを知らなければ、理解しにくいままである。
この捉え方では、シェルは単なる起動手段から統合環境へと変わる。エッセイの提案は、すべてのエンジニアが専門家になるべきだというものではない。十分なコマンドラインの素養があれば、繰り返し作業の手間を減らし、ソフトウェアプロジェクトを既に支える自動化の仕組みを、より容易に調査、修復、拡張できるというものだ。



