『ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析』では、開発者がIDEの自動インポート機能を安易に使うことで、モジュール性の低いコードが生成されるというアンチパターンが紹介されています。
たとえば、Javaや.NETの開発環境でコーディングをする場合、開発者がまだインポートされていないクラスを参照すると、IDEはすぐに開発者に参照を自動インポートするかどうかをダイアログを通して尋ねてくる。それがあまりにも頻繁に起きるため、ほとんどのプログラマーは反射的に自動インポートのダイアログを押してしまう癖がついている。
1.5.1 適応度関数の使用
「俺じゃん・・・」と思いつつもしかし、私はこのインポートが無意識に積み重なっていく状況を、逆転の発想でリファクタリングに活用しています。*1
具体的な手順:
- なんか書いてるコードがごちゃってることを感知する
- インポート文を1行削除する: 特に階層の深い、1行の長いインポート文を選ぶのがおすすめです。
- 静的解析でエラーが出ることを確認する: 動的型付け言語ユーザーはLINTツールやIDEなどを活用してください。
- エラー内容を観察する: この過程でたった1行の関数呼び出しなどのためにインポートしていることなどが判明することがあります。
- より上位のモジュールに集約して解決できないか検討する: インポート文を合体させて強くしていくイメージです。注意点としては集約を目的にすると不都合な結合も引き起こすことがあります。
要約すると「意図的にエラーを引き起こすことで依存情報の視覚化をする」という感じでしょうか
この習慣は、私がC言語を書いていた時に身に付きました。
ゆるふわにWebフレームワークに乗って開発していた時はオートローダーに身を委ねていましたが、C言語ではヘッダーファイルを明示的にインポートします。
良いIDEもなかったので、vimでインポートを毎回手書きしていました。*2
「インポート文を書くのが面倒くさい」
↓
「インポート文を書かなくて済む設計にすればいいのでは（のび太）」
という発想で、この手法に辿り着きました。やっててよかったC言語
しかし現代となってはインポート文並び替えレベルの自動化はすでにみんな行っているわけで、インポート方法をLINTしたり自動化の余地はあるのかもしれませんね。規模が大きくなるとインポート文をまとめただけのファイルなども出現しますし。
私が最近書いてるのはLaravelアプリケーションのコードなのでインポート分というよりはDIコンテナ経由で持ち込むモジュールの数とか粒度がバラバラになってきた・・ などをバロメーターにしています。
