【ITニュース解説】Swearing and Slang: Making a Dialect Measurable and Responsive

システムエンジニアを目指す皆さんへ。プログラミングを学ぶ上で、コードの書き方に関する「ルール」や「規約」に触れる機会が多くあるだろう。しかし、時にはそのルールが通用しない、あるいは適用するとかえって問題が生じるケースに遭遇することがある。今回の記事は、そんな状況にどう向き合い、どのようにしてルールを破らずに柔軟性を持たせるかについて、「Resilient」という考え方を通じて解説している。

Resilientは、JavaScriptにおける「方言」のようなものだ。通常のJavaScriptの書き方では、変数や関数の定義、データのやり取りの仕方など、コードの合意（agreement）を明確にするための形式が使われる。例えば、関数がどのような引数を受け取り、どのような結果を返すかを示す「シグネチャ」や、値が与えられなかった場合の「デフォルト値」などがこれにあたる。これらは、コードの意図をわかりやすくし、他の開発者が理解しやすくするための大切な要素だ。

しかし、世の中のすべてのプログラムがこうした「普通のコード」だけで構成されているわけではない。時には、外部のライブラリやフレームワークを使ったり、他のシステムと連携するAPIを呼び出したりする必要がある。例えば、非同期処理を行う際に、特定のライブラリが独自のPromiseチェーンの書き方を要求することがある。また、データ処理の順番を厳密に守るために、特定のループ構造が必要になる場合もある。さらに、外部APIによっては、引数を「与えないこと」そのものに意味がある場合もあり、空のオブジェクトを渡すのと、何も渡さないのとでは、動作が異なることがあるのだ。

このような状況で、常に「普通のコード」の規約に固執しようとすると、ライブラリの動作が壊れたり、APIとの連携がうまくいかなくなったりする可能性がある。だからといって、安易にルールを無視してしまっては、コードの品質が低下し、将来的な問題につながる恐れがある。ここで重要になるのが、「この部分は、一般的な書き方では対処できない特別なケースだ」ということを、コード上で明確に表現する方法だ。

記事では、プログラミング言語におけるこの「特別なケース」を、人間が使う言語における「俗語（スラング）」や「罵り言葉（swear）」になぞらえている。普段の言葉遣いとは異なる表現が、特定の状況で強い意味を持ったり、親密さを示したりするように、コードにおける例外的な記述も、その部分が持つ特殊な契約や境界を示唆しているというわけだ。

Resilientでは、このような例外を扱うために、ESLintというツールが提供する既存の機能を活用することを推奨している。ESLintは、コードの品質を維持するための静的解析ツールで、JavaScriptのコードが特定の規約に従っているかをチェックし、問題があれば警告してくれる。ここで使うのが「// eslint-disable-next-line」というディレクティブだ。これは、その行の次の行に限り、特定のESLintのルールを無効にする指示である。

このディレクティブを効果的に使うためのルールがいくつかある。まず、無効にするルール名を具体的に指定する必要がある。例えば、「// eslint-disable-next-line resilient/prefer-async-await」のように記述する。これにより、どのルールを緩和しているのかが明確になる。次に、このディレクティブが適用される範囲は、あくまでも「その次の行」または「特定の単一の文（ステートメント）」に限定するべきだ。ファイル全体や広範囲にわたるルールの無効化は、規約違反を隠蔽し、後から問題を引き起こす可能性があるため、Resilientでは禁止されている。

そして最も重要なのは、なぜそのルールを無効にするのか、具体的な理由を明確に記述することだ。単に「ここが必要だから」という曖昧な理由ではなく、「このストリームアダプターは独自のチャンク配信と拒否フローを持っているため、このPromiseチェーンが必要」といった具体的な説明が必要になる。この理由は、コードレビューを行う開発者にとって、その例外が正当かどうかを判断するための重要な手がかりとなる。この情報は、単なる個人的な好みの問題ではなく、特定の技術的な制約や外部の契約に基づいていることを示しているのだ。

このような形で例外を明示することは、コードの文法に「穴」を開けることではない。むしろ、コードの文法が完全にカバーできない「境界線」が存在することを示す、明確な「主張」なのだ。そして、この例外は、指定したルールのみを緩和するものであり、他のESLintルールによるチェックは引き続き行われるため、コード全体の品質管理が損なわれることはない。

さらに、記事では、こうした例外の情報を単に「許容する」だけでなく、「測定」し「活用」することの重要性を説いている。Resilientは、独自のツールを使って、プロジェクト内のディレクティブの使用状況を監査し、どのルールが最も多く緩和されているか、特定の境界に集中しているか、同じ理由が繰り返し現れるかなどを分析できる。

例えば、ある特定のルールに対する例外が、プロジェクト内の様々な場所で繰り返し、同じ理由で使われている場合、それはそのルール自体が、現実の開発において適切でない、あるいは、より柔軟な新しい文法形式を導入する必要があるというサインかもしれない。これは、まるで言語において、繰り返し使われる俗語が、やがては一般的な言葉として受け入れられることになぞらえられる。

しかし、これもまた慎重に扱うべきだ。例外の数が多ければ良いというわけではない。個々の例外が、それぞれ異なる明確な契約に基づいているのであれば、数は多くても正当なものとして扱われる。重要なのは、それぞれの例外が具体的な理由に基づき、必要な範囲に限定されているかどうかだ。そして、時間とともにコードが変化した場合、その例外が依然として正当な理由を持つのか、あるいはもう不要になっているのかも、定期的に確認する必要がある。不要になったディレクティブが残っていると、ESLintが「未使用のディレクティブ」として警告してくれることもある。

結論として、Resilientの考え方は、厳格なコード規約と、現実の開発における柔軟性という、一見すると相反する要素を両立させるための賢明なアプローチだ。ルールを盲目的に適用するのではなく、本当に必要な例外を見極め、その理由を明確にすることで、コードの可読性、保守性、そして品質を向上させることができる。システムエンジニアを目指す皆さんには、このような「ルールとの付き合い方」も、ぜひ意識して学んでほしい。