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

投稿元：

レビューを見る

コード例を示しながら読みやすいコードについて具体的に書かれている。
また、本書の良いところは、デメテルの法則や結合度の低減など、一般的に良いとされるプラクティスも盲目的に適用すれば保守性が落ちる事を事例を通して示しているところ。

投稿元：

レビューを見る

LINE株式会社でAndroidアプリの開発に従事しながら全社レベルでのソースコード可読性向上に取り組んできた著者による一冊。焦点は「読みやすさ」に絞られており、また企業の開発現場でやるべきことを書いてくれている（＝机上の理想論で終わっていない）のが嬉しい。ところで、本書が良書であることは大前提とした上で、この手の「良いソースコード」に関する書籍や記事が昔から定期的に刊行される背景は何なのだろう？とふと考える。システムの設計・技術選定であれば仮想サーバからコンテナ、パプリッククラウドなど日進月歩で10年前の設計思想が現在には通用しないということはあるように思われる。ただ、プログラミング言語とその書き方って（もちろん同じ言語でもバージョンアップを繰り返して機能追加は行なわれているが）そんな革命的にひっくり返ることは無さそうな気も。まぁでも命名の話は20年以上前から広く言われてる一方で例えばDIはそれに比べれば確かに新しい概念ではあるか。この本の内容がいつかの未来に古くなるということはあるのだろうか？

投稿元：

レビューを見る

良いこともたくさん書いてあるんだが、Kotlinがベースということもあり、Kotlinならそうだね、という箇所などあり、SwiftかKotlinを含む複数の言語を触っている前提かなと思い、人を選ぶ感覚はある。
!isDisabledとかナントカflagとか、実装を日本語に翻訳しただけのコメントとかはそうそうこれという感じ（みんな結構これやる）。
ListenerEventMessageClickViewTextなどの例示はあーまさにこれこれという内容が多く、経験値からは納得感は高い。

投稿元：

レビューを見る

「~でしょう。」で終わる書き方が多すぎて嫌だった。言い切ってくれればいいのになと思って、気になってしょうがない。
「・」の使い方も気になった。並列表記として使ってるのだと思うけど、一続きの単語に一瞬見えてしまってすぐに理解できずにストレス。「・」は外国の人の名前だと一つの名前のために使われるので紛らわしい。
こういった技術本の常だけどコード例と言及している文が離れていることが多くてページをめくり直すことが多くてストレスになる。
だけど、内容は良い。リーダブルコードと合わせて書き方の2大参考本としてこれからの開発者の指針になる。

投稿元：

レビューを見る

多くの内容がすでに知っていたり、実践していたりすることではあったけれど、意識したことがなかったり、やったことない内容も書かれていており、機会があれば実践してみたい。仮引数名や関数名はどこから呼ばれたかではなく何をするかで名付けるとか、for文のネストを関数として抽出するとか。『リーダブルコード』とか『プリンシプル オブ プログラミング』よりはあとに読むと良さそう。

投稿元：

レビューを見る

# 読み物としてコードを捉える視点を授けてくれる一冊

## 面白かったところ

- コードを文章と捉えることで、「書き手」ではなく「読み手」に配慮した注意点が記載されている点

## 微妙だったところ

- 依存に関して意外と深く書かれていて、軽い気持ちで読んでいた自分にとってはいい意味でドッキリだった点

## 感想

コメントや変数・クラス名、型の命名などは容易に想像できたけど、コンテキストや文章構造的な視点も混ざっていて面白かった。

読みやすいコードをプロダクトに乗せるためにはGithubのPull Requestで先ず誰かに読んで貰う必要があるが、その際の注意点も書かれていてとても親切。

現場で働いてきて、「feat: ◯機能の実装」みたいなゴミコミットメッセージを親の顔よりも見てきたが、やはりこれはアンチパターンであった。

意味のある単位でコミットを分けないと読み手には伝わらないし、小さなプルリクでは全体像が読み手には伝わらないからかなり配慮が要る作業。

コードを書くことは手段でしかなくて、受け入れられるコード（文章）を書き上げる力がソフトウェアエンジニアには必要だと改めて自戒。

いい本だから、若手に手にとってほしい。推薦しよう。

#読書 #読書好きな人と繋がりたい #読書記録 #読書好き #読書日記 #読書部 #読書の時間 #読書タイム #読書時間 #読了本 #読了記録 #本スタグラム #本好きな人と繋がりたい #本好き #本好きさんと繋がりたい