「コードの綺麗さ」と言う言葉に対する表面的な理解

「コードの綺麗さ」といった場合、いくつか評価軸がありますが恐らくほぼ以下の 3 つに集約できるのではないかと思います.

(1) 関数内部、ファイル内部等の局所的に記述されているコードの見た目 (改行とかスペースとか) が綺麗かどうか
(2) 関数内部、ファイル内部等の局所的に記述されている処理や記述に無駄なく美しいかどうか
(3) モジュールの切り分け、命名等を含む、大域的に見た設計が統一され美しいかどうか

もちろん全部綺麗なことに越した事はないですが、(3)が最も重要度と抽象度が高く、逆に(1)は個人的にそこまで重要では無いと思っています.

何故なら、見た目の統一感の無さよりアーキテクチャ上の統一感の無さの方が余程問題だから. どうしても見た目を揃えたいならツールにやらせれば良いことで、このような作業を人間が時間を割いてやるほどアホで愚かな事はありません.  (後れ馳せながら最近仕事で golang を触り始めたのですが、go fmt を処理系と一緒に用意して宗教戦争も含めた無駄を排除するという考え方、すごく良いなと思いました.)

ですが、現実にはコードの綺麗さを(1)でしか測れず、コードレビューの際にもこういった見た目の指摘ばかり繰り返す人間がかなりの割合でいます.  そういう人達に欠如しているのは、本質が何なのかを理解する能力や、コードを俯瞰してみる(つまり木ではなく森を見る)と言う視点です.

優れたソフトウェアほど一貫した設計思想があり、その思想を理解することで細部を読まずとも全体を想像し、構造を把握する事が出来ます.

自分は何度か転職をしていますが、一番最初と現在の会社を除いてこのような視点を持っている人間は皆無でした.

以前自チームで構築したプログラムを同僚に解説せよと上から仰せつかった際、全体の規模が大きかった事もありアーキテクチャーの解説を中心に行った所、「お前の説明はなっていない」と言わんばかりの感じで何故それが知りたいのか理解出来ない細部の説明ばかりを求められた事があります.

転職の際の引き継ぎだったので無表情で言われるがまま応じましたが、言うまでもなく死ぬほどウンザリしました.

残念な組織ほどこういった本質に対する理解力の欠如した人間が大きな顔をし、挙句の果てにコーディング規約なんか作っちゃってるからもう…

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中