【ITニュース解説】Good practices for Just: no '../' in pathes.

システムエンジニアを目指す皆さんにとって、日々の開発作業を効率的に進めるためのツールを知ることは非常に重要である。その中でも「Just」は、コマンドの実行手順をシンプルにまとめることを目的としたツールであり、特に小さな規模のプロジェクトでその真価を発揮する。従来の「make」のようなビルドツールとは異なり、主に「特定の処理を実行する」という目的に特化しているのが特徴だ。例えば、開発環境のセットアップやテストの実行、デプロイといった定型的な作業を、あらかじめ「レシピ」と呼ばれる形でJustfileというファイルに記述しておくことで、コマンド一つで実行できるようになる。

Justは非常に便利だが、プロジェクトが成長し、Justfileに記述するレシピの行数が増えてくると、次第に管理が難しくなり、混乱が生じる場合がある。特に、レシピの中で参照するファイルのパスの指定方法が、その混乱の大きな原因となりやすい。ここでは、そうした問題を避け、効率的かつ安全にJustfileを運用するための、重要な「良い習慣」について解説する。

Justfileのレシピを実行する際、Justの基本的な振る舞いとして、常にJustfileが置かれているディレクトリが「現在の作業ディレクトリ」（カレントワーキングディレクトリ）として設定される。これは非常に便利な仕組みで、例えばプロジェクトのルートディレクトリにJustfileがあり、その中に「playbooks/deploy.yaml」というパスを指定するレシピがあったとする。この場合、たとえ「playbooks」というサブディレクトリに移動してJustコマンドを実行したとしても、Justfileが置かれたルートディレクトリが基準となるため、常に「playbooks/deploy.yaml」という正しいファイルを指定できる。このように、Justfileの場所を基準とした相対パスは、多くの場合でシンプルかつ効果的に機能する。

しかし、時にはレシピの中で、現在の作業ディレクトリを変更する必要が生じることもある。例えば、特定のディレクトリ内に設定ファイルや必要なツールがあり、そのディレクトリに移動してからでないとコマンドが正しく実行できない場合だ。このような状況でcdコマンドを使って作業ディレクトリを移動すると、その後のパスの解釈は変更された新しいディレクトリが基準となる。問題は、この新しい基準から、さらに別の場所にあるファイルを参照しようとする場合に発生する。

もし、参照したいファイルがcdで移動したディレクトリの「親」や「祖先」にあたるディレクトリにある場合、「../」という記号を使って親ディレクトリを遡っていくことになる。例えば「cd production/deploy/ansible && ansible-playbook ../../playbooks/deploy.yaml」といった具合だ。これは一見すると解決策のように見えるが、階層が深くなったり、複数のファイルを異なる階層から参照したりすると、すぐに「../../../sources/data」のように「../」がいくつも連なる、非常に複雑なパスになってしまう。

このような「../」が多用されたパスは、いくつかの大きな問題を引き起こす。まず、そのパスが実際にどこを指しているのか、一目で理解することが極めて難しい。複数のcdコマンドが挟まっていたり、途中でパスの一部が変数で指定されていたりすると、さらに追跡が困難になる。次に、もしファイルやディレクトリの配置を変更するようなリファクタリング作業が必要になった場合、これらの「../」の数を一つ一つ数え直し、正しいパスに修正しなければならない。これは非常に手間がかかるだけでなく、人間が手作業で行うため、ミスが発生しやすい。プロジェクトの規模が大きくなればなるほど、このパスの管理は大きな負担となり、作業効率の低下や予期せぬエラーの原因となる。

この問題に対する効果的な解決策が、Justが提供する特殊な変数「{{ justfile_directory() }}」を使うことである。これは、現在実行しているJustfileが置かれているディレクトリの「絶対パス」を示す。つまり、どのディレクトリからJustコマンドを実行しようと、またレシピの中でcdコマンドを使って作業ディレクトリを変更しようと、この{{ justfile_directory() }}が示すパスは常に一定で、Justfileのある場所を正確に指し続けるのだ。

この{{ justfile_directory() }}を活用することで、パスの指定は劇的に改善される。例えば、先ほどの複雑な「../」だらけのパスは、次のように書き換えられる。「cd production/deploy/ansible && ANSIBLE_INVENTORY={{ justfile_directory }}/production/deploy/ansible/inventory,{{ justfile_directory }}/production/environments/{{ environment }}/ansible/inventory)」。この新しいパスは、一見すると長くなるが、その内容ははるかに理解しやすい。なぜなら、すべてのパスがJustfileの場所を起点とした絶対パスで記述されているため、どこから見ても、どのファイルがどこにあるのかが明確にわかるからだ。

{{ justfile_directory() }}を使うことの利点は大きい。まず、可読性が格段に向上する。開発者は、現在の作業ディレクトリがどこであるか、あるいはcdでどこに移動したかを気にする必要がなく、常にJustfileからの相対的な位置関係を絶対パスとして把握できる。これにより、パスの意図を正確に理解し、誤読によるミスを減らすことができる。

次に、保守性が大きく向上する。もしプロジェクト内でファイルやディレクトリの配置を変更することになった場合、「../」の数をいちいち計算し直す必要はなくなる。{{ justfile_directory() }}を起点としたパスは、Justfileからの相対的な位置関係が変わらない限り、変更する必要がないからだ。例えば、トップレベルの「production」というディレクトリ名を変更しても、{{ justfile_directory() }}以下のパスは、その内部構造が変わらなければそのまま使える。これは、リファクタリング作業の負担を大幅に軽減し、プロジェクト全体の柔軟性を高めることにつながる。

このように、{{ justfile_directory() }}は、Justfileのレシピにおけるパス指定の混乱を防ぎ、コードの可読性と保守性を高めるための強力なツールとなる。システムエンジニアとして、効率的でミスの少ない開発環境を構築することは非常に重要だ。Justのようなツールを最大限に活用し、こうした「良い習慣」を身につけることで、皆さんの開発スキルは大きく向上するだろう。今後も、より良い実践方法が発見され、共有されていくことだろう。