SE Can't Code

A Tokyo based Software Engineer. Not System Engineer :(

優しいShellスクリプトを書こう.

SIerにいると業務改善系のスクリプトを書くことがある。泥臭い作業は仕事の結構な割合を占めていて、意外にもこうした作業に対して非効率なまま放置されているケースは多い。この非効率さが許せないという人は片っ端から効率化用のスクリプトを書いて、無駄な作業を排除していくことになるが、そうした精神はSEたるもの皆が持っている必要がある。これが出来る人と出来ない人では作業効率に大きな差があるものだが、Perlスクリプトは書けないけど、Shellスクリプトぐらいなら、、という人は多く、業務改善系Shellスクリプトをファイルサーバ上で見る事は結構多い。

ただ、こうしたShellたちの中にはREADMEやヘルプメッセージの出力機構すらない、イケてないスクリプトたちがよく見受けられる。使い捨てのスクリプトであればそんなものは必要ないのだが、今後運用していくようなものであればチーム内での共有や引継ぎというタスクが発生するため必須であると言える。これが意識出来ておらず、スクリプトさえ書ければ満足してしまう人がちょいちょいいるので、そういう人はヘルプメッセージを書くことを心掛けると良い。

Shellの場合は本体を書き始める前にusageを書くようにする。事前にusageを書くようにすると、ヘルプメッセージの恩恵以外に、スクリプトの本来の目的を見失わずに済むようになる。変に機能を追加し過ぎて運用が煩雑となってしまうような肥えた設計はスクリプトをガリガリ書いている中であれもこれもと陥りがちなので、シンプルさを保つためにもusageを事前に書くことは良い効果をもたらす。

usageは以下のようなルールが基本となっている。

  • 「Usage:」で書き始める
  • 必須でないものは[arg]のように名前を括弧で囲む
  • 複数指定可能な場合は … を付ける
  • 引数付きオプションには分かりやすい引数名を付ける


実際にusageは以下のように書く。

function usage {
    cat <<EOF
$(basename ${0}) is a tool for ...

Usage:
    $(basename ${0}) [command] [<options>]

Options:
    --version, -v     print $(basename ${0}) version
    --help, -h        print this
EOF
}


業務の中で何かスクリプトを書くといった場合は、自分がいずれチームからいなくなった際の引き継ぎをスムーズに済ませるところまで考えてやれると、人に優しいスクリプトが書けるようになる。Shellの場合は「usage読んでください」とさえ言えば済んでしまうことが理想で、わざわざ対面での引き継ぎを必要とする時点でイケてない仕事をしているとも言える。綺麗なコードを書くことと同じぐらい重要なことだと僕自身は思っているので、このような他の人が使いやすいShellが書けることはSEとして大事な素質であると思う。

ということで、僕の2016年最初の仕事はShellを書くことなので、usage意識して人に優しい仕事をしたいと思う。
(...できればShellなんて書きたくないんだけどね。)

Remove all ads