はじめに
新卒入社8年目のK・Fです。製品開発部門に移ってから4年ほどになります。
実は私が製品部門に移るきっかけは、とあるプロダクトの立て直しのためでした。そのプロダクトも今では改善が進み、多くのメンバーが開発する当社を代表するプロダクトの一つになっています。その経験から培った「読みやすいコード」について、自分なりに語ってみたいと思います。
「読みやすい」とはどういうことか
まずは、私にとって「読みやすさ」「読みにくさ」とはどういうことか具体的に言語化してみます。
コードを読む目的
コードを読む目的は、次の２つがあると考えています。
- コードを理解するため。
- コードを変更するため。
つまり、これらの目的を達成しやすいコードは以下のようになります。
- コードを理解しやすい（可読性が高い）。
- コードを変更しやすい（変更容易性が高い）。
こういったコードを、私は普段「読みやすいコード」とざっくり呼んでいます。
読みづらさの原因３パターン
「なんかこのコード読みづらいな……」と感じたとき、私はなぜ読みづらいのかを分析します。
以下が自分が気付いた読みづらい原因のパターンです。
1. 理解するために必要な情報が揃っていない（可読性）
書いていないことを理解しようとしてもできるはずもありませんよね。
書き手はコードの作者であり、そのコードに関する全ての背景を知っていますが、読み手はそうとは限りません。 書き手と読み手の間には大きな知識のギャップがあることを理解して、読み手が足りない知識を補ってあげる配慮が必要になります。
2. 視覚的に見やすく整頓されていない（可読性）
プロダクトの成長に伴い、コード量は多くなるのが必然なので、整理整頓しないとどこに何があるか見つけられなくなってきます。
私は、まとまりがなくごちゃごちゃしているコードは「物で散らかった机の上」と同じ印象を受けます。ここでいう「物」は「コード」です。
インデントや書式の不統一もこれに該当します。
3. 変更した際の影響範囲が広すぎる、把握できない（変更容易性）
まず、コードを変更する際は影響範囲を把握した上で修正コストを見積もるので、これが把握しやすいかどうかも修正コストに影響します。
影響範囲を調べる際はIDEやGrep検索を活用すると思いますが、これで簡単に把握できない実装は将来変更時に不具合に繋がる可能性が高いです。
また、影響範囲が広すぎることも、具体的な調査、試験や動作確認が増えるため、修正コストに影響します。
読みづらさを解消する具体的なアプローチ
必要な情報を揃える
共通認識がとれるワードを使う
コメントや変数名などでは、読んだ人全員が同じ解釈ができるのが理想です。そのため、共通認識がとれる正式名称を使い、表記揺れ・認識揺れが起こらないように意識します。
暗黙の前提で実装していないか
以下のような情報はその機能に詳しくない人にとっては気づきにくいものになります。 こういったものは、コメントで補足する等の配慮をして明示的にしましょう。
- 設計で作られた前提
（例）☓☓☓のとき、○○○の考慮は対象外
- 設計から間接的に読み取った前提
（例）☓☓☓の場合、データは常に○○の状態しか取らない
見た目を揃える
ブロック分け
プログラムは小さな処理が集まって、大きな処理を構成しているので、 それぞれが適切なまとまりになるようブロックで分けることを意識して書くと良いです。
規則性
一口に規則性といっても色々ありますが、私が特に意識しているのが「同じものは同じ見た目にする」という考え方です。
人間は学習するので、一度見たことあるコードを読むコストは二度目以降で大きく下がると思います。 なので、そのメリットが発揮されるために、同じものであれば同じものだとわかるようにすることが必要だと考えています。
対比構造
大部分は同じで一部だけ違うような処理がある場合、異なる部分以外を全く同じにすることで対比構造が作れます。これによって、片方を読んだ後に、もう片方は異なる部分だけ読めば済むようになります。
（「同じものは同じ見た目にする」の応用です。）
影響範囲は最小限にする
アクセス範囲を小さくする
C#の場合、ローカル変数のスコープはその変数が宣言されたブロック{}内のため、必要最小限のスコープになる箇所で宣言しましょう。
さらに可能な場合は、その変数を使用するコードを近くに集めることで視覚的に読みやすくなります。
クラスのメンバー（プロパティや変数など）のアクセス修飾子も必要最低限にします。
疎結合にする
機能同士が互いに結合しないようにしましょう。
私は、結合していないかを判断する際、「ある機能が他方の機能の仕様を考慮した上での実装になっていないかどうか」という見方をしています。 結合していない機能は、互いの仕様を全く知らない状態で作るべきものなので、考慮していたら結合していると判断できます。
アナロジー「割れ窓理論」
最後に、自分が好きなアナロジーである「割れ窓理論」について紹介します。
（利用者のモラルが低く汚れているコンビニのトイレを常にピカピカにしていたら使う人が綺麗に使ってくれるようになった、的な話です。）
コーディングにおいても、上に挙げたような内容を意識してコードを書き続けているうちにそれがメジャーになり、定着することをモチベーションにして日々コードを書き続けています。
おわりに
私が担当しているプロダクトのコードは当初、何もヒントがない意図不明なものをほとんど推測で解読する作業が多く、非常に悩みました。そのとき感じたストレスを自分の書いたコードを読む人には感じて欲しくない、という気持ちが今のコーディングの礎になっていると思います。
なので、読みやすいコードを書くことは、開発者全員の作業効率化だけではなく、ひいてはストレスフリーな労働環境の整備とも呼べる有意義な取り組みだと考えています。
この記事の内容が、読者のみなさまの日々のコーディングに役立つヒントとなれば嬉しく思います。
お知らせ
ecbeingでは新進気鋭のエンジニアを募集しております！
careers.ecbeing.tech
