ソースコードを読みにくい理由

慣れない環境や言語で書かれたソースコードを読み解くのはなかなか大変だ。個々の処理は分かるのに、それによって実現される一連の機能を理解するには、また別の能力を必要とするのかも知れない。そんなコードの読みにくさは、こんな所に起因するのではないかと思う。

  • 誰からどのタイミングで呼び出されるのか分からない
    フレームワークを使っていると、例えば「UIのボタンが押された時」「ネットワークからの受信が完了した時」などのイベント発生毎に呼び出されるメソッドが定義されているので、そのフレームワークの仕組みを理解することが初めに必要だったりする。しかも、オブジェクト指向な言語では動的に処理が切り替わるので、ある箇所では「自分で定義した動作」が呼び出されるのに、別の箇所は自分では何も定義していないので「デフォルトの動作」が呼び出されたりする。そのような差異を把握しておかないと、「ブレークポイントを仕掛けたはずなのに呼び出されない」事態が起きたりする。
  • 処理単位の粒度が均一ではない
    いわゆるコンポーネントやクラス毎に処理の粒度が均一化されていると分かりやすいことが多い。例えば、高いレイヤーでは「具体的な処理は下位レイヤーに任せて抽象的な処理」を行い、低レイヤーでは「上位レイヤーから呼び出された個々の処理を具体的に行う」形になっていると、全体を理解するのも容易だし、必要なら個々の処理を参照すれば良いので理解が短時間で済む。しかしながら、上位レイヤーにて「ファイルを読み込んで中身を解析して必要な情報を参照して...というコードが延々と書かれている状態」だと、抽象的な思考の流れが分断されてしまい理解がなかなか進まなかったりする。
  • グローバル変数やそれに相当する仕組みの濫用
    さすがにグローバル変数を新規に取り入れて使う開発は減ったけれど、少し昔のコードを見るとそのようなデータがゴロゴロと転がっていたりする。しかも、スタティック変数やシングルトンのように特定の状況に依存するデータが存在していると、「単一のユニットテストでは成功するのに、一連のテストスイートを実行すると途端に失敗してしまう」ことが起きたりする。デザインパターンのリストに取り入れられてメジャーな地位を獲得したシングルトンだけど乱用は禁物だろう。

シングルトンパターンは魅力的なのですが、実は、利点よりも弊害の方が多いパターンです。

http://d.hatena.ne.jp/asakichy/20110803/1312323474

・依存関係を見えにくくし、コードが読みづらくなる。
ユニットテストを難しくする。外部から渡せないオブジェクトはモックにする事が難しい。
・プログラムの再利用性が低下する。一度しか使わないからとシングルトンで作ってしまうと複数のユーザーから利用されるような場合に対応できなくなる。

僕はアダム、シングルトン中毒から回復したんだ | A-Listers

コードの解読に苦労する度に、そのような読みにくい仕組みを避けるような設計、実装、コメント付けを行うべきだと思うことが多い。「頑張って何とかする」のが開発者の得意技だけど、本質的ではない問題に頑張ってしまうのは、時間と労力のムダのような気がしている。



関連