あらすじ
※PDF版をご希望の方は Gihyo Digital Publishing (https://gihyo.jp/dp/ebook/2022/978-4-297-13037-4)も合わせてご覧ください。
開発が大規模化・長期化するほど，コードを「読む」コストは増大していきます。そのため「読みやすさ」の向上は，生産性を改善し，プロダクトの成長限界を引き上げる重要な手段と言えるでしょう。
本書は，読みやすさの本質を学び，実践するための考え方をマスターできる一冊です。体系的な理解を実現するため，あらゆる角度から，豊富な例を交えて解説しています。表面的なテクニックではなく，いま目の前にあるコードに最適な改良方法を選び取る力が身に付きます。
感情タグBEST3
Posted by ブクログ
ちょうどチームで悩んでいたことに対するアンサーがたくさんあり、今後の改善につながります。
割とぶつかる問題が多くあり、エンジニアなら書かれている内容を理解し、自らのコードの書き方を振り返るいい機会になると思います。
今後、エンジニアに読んで欲しい本にも入って欲しい内容です！
Posted by ブクログ
コード例を示しながら読みやすいコードについて具体的に書かれている。
また、本書の良いところは、デメテルの法則や結合度の低減など、一般的に良いとされるプラクティスも盲目的に適用すれば保守性が落ちる事を事例を通して示しているところ。
Posted by ブクログ
多くの内容がすでに知っていたり、実践していたりすることではあったけれど、意識したことがなかったり、やったことない内容も書かれていており、機会があれば実践してみたい。仮引数名や関数名はどこから呼ばれたかではなく何をするかで名付けるとか、for文のネストを関数として抽出するとか。『リーダブルコード』とか『プリンシプル オブ プログラミング』よりはあとに読むと良さそう。
Posted by ブクログ
中級レベル向けの一冊であると感じた
原則や概念の名前について説明はあるものの、初学者には理解に一苦労するかなと思う
ただ、非常に実践的な内容であることは間違いなく、コードの例もわかりやすい
自分にとっては命名やレビューで身に覚えのあるアンチパターンがあったので、繰り返し本書を振り返りながら改善していきたいと感じた
Posted by ブクログ
「~でしょう。」で終わる書き方が多すぎて嫌だった。言い切ってくれればいいのになと思って、気になってしょうがない。
「・」の使い方も気になった。並列表記として使ってるのだと思うけど、一続きの単語に一瞬見えてしまってすぐに理解できずにストレス。「・」は外国の人の名前だと一つの名前のために使われるので紛らわしい。
こういった技術本の常だけどコード例と言及している文が離れていることが多くてページをめくり直すことが多くてストレスになる。
だけど、内容は良い。リーダブルコードと合わせて書き方の2大参考本としてこれからの開発者の指針になる。
Posted by ブクログ
良いこともたくさん書いてあるんだが、Kotlinがベースということもあり、Kotlinならそうだね、という箇所などあり、SwiftかKotlinを含む複数の言語を触っている前提かなと思い、人を選ぶ感覚はある。
!isDisabledとかナントカflagとか、実装を日本語に翻訳しただけのコメントとかはそうそうこれという感じ（みんな結構これやる）。
ListenerEventMessageClickViewTextなどの例示はあーまさにこれこれという内容が多く、経験値からは納得感は高い。
Posted by ブクログ
LINE株式会社でAndroidアプリの開発に従事しながら全社レベルでのソースコード可読性向上に取り組んできた著者による一冊。焦点は「読みやすさ」に絞られており、また企業の開発現場でやるべきことを書いてくれている（＝机上の理想論で終わっていない）のが嬉しい。ところで、本書が良書であることは大前提とした上で、この手の「良いソースコード」に関する書籍や記事が昔から定期的に刊行される背景は何なのだろう？とふと考える。システムの設計・技術選定であれば仮想サーバからコンテナ、パプリッククラウドなど日進月歩で10年前の設計思想が現在には通用しないということはあるように思われる。ただ、プログラミング言語とその書き方って（もちろん同じ言語でもバージョンアップを繰り返して機能追加は行なわれているが）そんな革命的にひっくり返ることは無さそうな気も。まぁでも命名の話は20年以上前から広く言われてる一方で例えばDIはそれに比べれば確かに新しい概念ではあるか。この本の内容がいつかの未来に古くなるということはあるのだろうか？
