開発のオジサンエンジニアDJです。

読みやすいコードとメンテしやすいコードのちがいについて…。読みやすいコードを書けば、必然的にメンテしやすくなるのではないか？というとそうでもありません。同様にメンテしやすいコードを書けば読みやすくなるとも限りません。

読みやすいの定義

読みやすい＝コード個人的な感想。見慣れないうちは「読みにくい」と感じていても、慣れてくることにより「読みやすい」と感じるようになるコード。慣れてる慣れてないという感覚の問題が大きい。ある人Aさんにとっては読みやすいと感じているが、別のBさんにとっては読みにくいと感じる事もあります。

読みやすいと感じるかは個人個人でバラバラです。ある料理がある人には美味しいと感じても、別の人には美味しくないと感じるのと同じです。

また、自分が書いたコードでも数か月、数年が経過する事により自分の中でも当時のコードは忘れ去っていたり、自己でのコーディング規約が変わっていたりして読みにくいと感じる事もあります。

メンテしやすいの定義

メンテしやすいコード＝類似した処理が集約化されていて変更箇所が少なくて済むコード。トレースするのには時間がかかったりするので直感的に読みやすいとは感じないかもしれません。

特に類似したロジックをコピーして改修すると、そのコピー元の処理に間違いがあり修正する時や機能を変更したくて改修をするときに2度手間、3度手間になります。共通で使うロジックに関してはコピーして改修するのではなく関数化しましょう。このタイミングで関数化しないと３番手、４番手にやる方は２番手の方と同様にコピペ＆改修して類似したコードがあちこちに存在する事になってしまいます。

WEB開発でも画面のフローは大概同じなので、既存フローを参考にしつつ、ソレに準えたルールで書くことにより新たなルールが持ち込まれず既存ルールと同じ知識でトレースできたりします。

なので「読みやすいコード」を書こうとして読みやすくなるのではなく「メンテしやすいコード」を書くように心がける事で必然的に改修の手間が減るという事です。トレースするには時間もかかりますが慣れの問題が多く占めています。

コメントアウトを書かなくても分かるように

理解できるようにコメントアウトを書くのも、そもそもコードだけで理解できないからコメントアウトを書くことになります。変数名、関数名、ファイル名、データベース名、テーブル名、カラム名、全てコメントアウトしなくても分かるような命名する事が大切です。

BLOOD_TYPE_IDのカラム説明ならカラムコメントに「1:A型/2:B型/3:AB型/4:O型」と記述しておけば、ソースコードのどこに説明があるのかな…？とか悩まずに済みます。わざわざ血液型でテーブル1枚作るケースも無いと思います…。

思いやりこそ全て

いろいろ言っても最終的には思いやりが全てです。

文：開発のDJ