Zenn
📖

【書評】読みやすいコードのガイドライン -持続可能なソフトウェア開発のために

2022/10/31に公開
Kotlin
#
オブジェクト指向
#
命名
#
書評
#
ベストプラクティス
idea

こんにちは！
日々オブジェクト指向でコーディングしていると、色々な方法論やアーキテクチャ設計・DDDなど、いかに綺麗にコードを書くかということを意識されていると思います。
このような意識を持ち始めたのも、自他ともにカオスなコードを読み書きしてきた歴史があるからだと思います。
そこで今回はそんなカオスコードを量産しないための本、LINEのMobileDeveloperである石川さんの「読みやすいコードのガイドライン」という書籍をレビューさせて頂きます。

読みやすいコードのガイドライン -持続可能なソフトウェア開発のために

想定読者
初級者〜中級者くらい？

サンプルコードの言語
Kotlin

最初に感想💡

まず前提としてマクロな視点でのアーキテクチャ設計本ではないです。どちらかというともう少しミクロな視点でのコーディング改善に特化した本でした。読みやすいコードを書く上で必要な知識は沢山ありますが、その中でも2022年時点のコーディングで絶対に押さえておかなければならない部分を集中的にLINEさんのチームで培ったノウハウをしっかり凝縮し、解説されている印象を持ちました…！
著者はAndroidアプリ開発者ということもあり、解説は主にKotlinでどちらかというとクライアントサイドよりの関心事を例に挙げて解説されていることが多かったです。ただ、コードを綺麗に書くという意味ではサーバーサイドの方でも問題なく読めると思うので心配する必要はないです。

1章.可読性の高いコードを書くために

導入では可読性の高いコードを書く意味などをしっかりと解説されていました。日々自分の頭の中にある課題感を元に綺麗に書く意識はしていましたが、ここまでしっかりと文章化できるのはさすがだと思います。

可読性の高いコードを書く意味 -> 書くためには -> 具体的方法

上記のようにわかりやすく解説されています。書店でこの章だけ少し読んでみて購入を検討してもいいかも👀

2章.命名

個人的にはコーディングにおいて命名というものが一番大事だと思っています。
なんならオブジェクト指向プログラミング　≒　処理・概念に名前を付ける作業だと考えています。
初級者から中級者の方は命名というものがどうしても苦手意識があると思いますが、本書ではどういう考え方でどのように命名すればいいかという部分を非常に具体的に書かれています。普段命名に困っているエンジニアはこの章だけでも買う価値はあると思いました。

3章.コメント

大体のプログラミング言語にはコメントという仕様が実装されていますが、みなさんどのような目的でコメントを使っているでしょうか。
本書では以下の2分類に大別されると書かれています。

・ドキュメンテーション
-> コードの中身を読まずとも概要を理解するためのコメント

・非形式的なコメント
-> コードを読む際に補助をするためのコメント

ドキュメンテーション

「ドキュメンテーション」に関してはIDEなどを使われている方だと自動生成機能があったりして馴染みのある方も多いかと思いますが、ある決まった形式でコメントを書くというものです。そうすることでエディタなどの補完が効くようになり、参照先のコードの中身を読まずとも概要が理解でき効率的に開発することができるようになります。
本書ではドキュメンテーションの書き方のアンチパターンがいくつか紹介されており、非常に参考になりました。

非形式的なコメント

一方で「非形式的なコメント」というのはコードの中身を読む際に、一見分かりづらい部分の理解を手助けするためにあります。基本的にはそのような非直感的なコードはクラス分割を行うなどで可読性を上げるようにする方向性が望ましいですが、どうしても仕様上分りづらくなるところも出てくることはあるので、そのような際にコメントで補助して上げるのがいいと思います。ここでも沢山具体例が挙げられているのですぐに実践に取り入れられると思います。

補足

あとたまに見るのが、メソッド名を読めばわかるものをわざわざ日本語で翻訳コメントのようなものを書いている初級者さんです。英語が苦手な国に多いのかもしれませんが、英語を読めばわかるものは誤訳リスクなど逆に可読性を悪化させる可能性があるのでわざわざ訳コメントのようなものを残すのはやめた方がいいです。

4章.状態

状態とはオブジェクト指向でプログラミングをしている以上、避けては通れない概念となります。
この章では状態を管理する上で複数の変数間の関係・状態遷移という２つの観点から 「直交」 という概念を元に望ましいクラス・モジュール定義の方法を説明されています。

直交とは
2つの変数について、それぞれの値の取りうる範囲（変域）がもう一方の値に影響されない場合、それらの変数は互いに直交の関係にある

定義だけだとあまりイメージが沸かないと思うので、しっかりとコードや図解で説明されている本書を実際に読んで見るのが一番早いと思います。

5章.関数

本章では関数を作る上ではその関数が何をしているのか予測可能にすることで中身を読まずとも理解できるようにすることが大事だと述べられています。予測したい内容としては以下が挙げられていました。

  • 戻り地が取りうる値とその意味
  • どのような副作用をもつか
  • エラーとして扱われる条件とその時の動作

また、予測可能な関数にするための要素として以下が挙げられています。

  • 関数の名前の意味と関数の動作が一致している
  • 関数の名前が十分に具体的
  • ドキュメンテーションの要約を容易に書ける

本章でもやはり命名の大切さは再び述べられています。
それに付随して関数の責任や関数の流れなど、読みやすいコードを書くための知恵が沢山書かれていました。
具体的には以下のような読みやすいコードを書くための必須テクニックが散りばめられています。

  • CQRS
  • メソッドチェーン
  • 早期リターン
  • マジックナンバー撲滅
  • etc..

6章.依存関係

本章ではクラス同士の依存度を極力減らすための方法が具体的に書かれています。以下のような依存度の強い順に論理的に説明されていてかなり頭の中が整理される内容でした。

※上から順に依存関係が強い

内容結合
共通結合
外部結合
制御結合
スタンプ結合
データ結合
メッセージ結合

ここまで細かく結合の種類を考えながら設計したことはなかったので非常に勉強になりました。

7章.コードレビュー

本章ではチーム開発では欠かせないコードレビューのプラクティスについて書かれています。
LINEさんのような技術力の高いチームの開発フローを覗けるのは非常にありがたいですね…！
レビューワー・レビューイーどちらの視点でも適切な方法論が書かれており、gitの具体的なブランチ運用まで書かれていたのでとても参考になりました。
レビューをしてもらう立場の人は本書を読んで読みやすいコードを書けるように心がけましょう。

以上、「読みやすいコードのガイドライン -持続可能なソフトウェア開発のために」の書評でした。本の簡単な紹介と思ったことをツラツラと書いた内容になりましたが、今後も技術本の書評は書いていこうと思いますので少しでもみなさんの参考になればいいかなと思います😀
Twitterでエンジニアアカウント作りましたので随時そちらでも発信します。良ければフォローして頂けると嬉しいです！

Discussion