脳に収まるコードの書き方―複雑さを避け持続可能にするための経験則とテクニック

Ｓｅｅｍａｎｎ，Ｍａｒｋ【著】/吉羽 龍太郎/原田 騎郎【訳】/Ｍａｒｔｉｎ，Ｒｏｂｅｒｔ Ｃ．【まえがき】〈Ｓｅｅｍａｎｎ，Ｍａｒｋ〉

オライリー・ジャパン（2024/06発売）

• サイズ B5判／ページ数 312p／高さ 24cm
• 商品コード 9784814400799
• NDC分類 007.64
• Cコード C3055

出版社内容情報

コードの複雑さを減らし、人の頭で理解できるソフトウェア設計を解説！
開発者が優れたソフトウェアを構築するためのソフトウェア設計のメンタルモデルを考察し、ソフトウェアの設計やコードを書く際に、人の頭で理解しやすいようにするための方法を解説します。ソフトウェアが複雑になることを避けるため、設計/開発/API/テストなど一連の流れで、ソースコードをどのように整理して構造化するかを紹介し、それをチームメンバーがスムーズに理解し、作業を効率的に進めるための方法を説明します。

内容説明

ソフトウェアを思い通りに動かすために、頭に収まり、人間が理解できるコードを書く！拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説。サンプルコードで試しながら学べる。

目次

第１部　加速（アートかサイエンスか；チェックリスト；複雑さに対処する；バーティカルスライス；カプセル化；三角測量；分解；ＡＰＩ設計；チームワーク）
第２部　持続可能性（コードの増大；ユニットテストを編集する；トラブルシューティング；関心事の分離；リズム；いつもの顔ぶれ；ツアー）
付録Ａ　プラクティス一覧
付録Ｂ　参考文献

著者等紹介

シーマン，マーク［シーマン，マーク］ ［Ｓｅｅｍａｎｎ，Ｍａｒｋ］
プログラマーとしてセカンドキャリアを見つけたダメなエコノミストで、１９９０年代からＷｅｂ開発者、エンタープライズ開発者として働いている。若いころはロックスターになりたいと思っていたが、残念ながらその才能もなければルックスもなかった。しかしのちに、認定ロックスター開発者になった。また、依存性注入について書いた本でジョルトアワードを受賞し、１００以上の国際的なカンファレンスで講演し、ＰｌｕｒａｌｓｉｇｈｔとＣｌｅａｎ　Ｃｏｄｅｒｓで動画のコースを制作した。２００６年以来、定期的にブログを更新している。妻と２人の子供とともにコペンハーゲンで暮らしている

吉羽龍太郎［ヨシバリュウタロウ］
株式会社アトラクタＦｏｕｎｄｅｒ兼ＣＴＯ／アジャイルコーチ。アジャイル開発、ＤｅｖＯｐｓ、クラウドコンピューティングを中心としたコンサルティングやトレーニングに従事。野村総合研究所、Ａｍａｚｏｎ　Ｗｅｂ　Ｓｅｒｖｉｃｅｓなどを経て現職。Ｓｃｒｕｍ　Ａｌｌｉａｎｃｅ認定スクラムトレーナー（ＣＳＴ）、認定チームコーチ（ＣＴＣ）。Ｍｉｃｒｏｓｏｆｔ　ＭＶＰ　ｆｏｒ　Ａｚｕｒｅ

原田騎郎［ハラダキロウ］
株式会社アトラクタＦｏｕｎｄｅｒ兼ＣＥＯ／アジャイルコーチ。外資系消費財メーカーの研究開発を経て、２００４年よりスクラムを実践。ソフトウェアのユーザーの業務、ソフトウェア開発・運用の業務に両方をより楽に安全にする改善に取り組んでいる。Ｓｃｒｕｍ　Ａｌｌｉａｎｃｅ認定スクラムトレーナー（ＣＳＴ）（本データはこの書籍が刊行された当時に掲載されていたものです）
※書籍に掲載されている著者及び編者、訳者、監修者、イラストレーターなどの紹介情報です。

感想・レビュー

※以下の感想・レビューは、株式会社ブックウォーカーの提供する「読書メーター」によるものです。

[むらさき]

うーむ。良い本なのだと思うが、リーダブルコード的なものを想像していたので、少しイメージと違っていてとっつきづらかった。。。先にテスト駆動開発とかを予習しておくともうちょっとわかるのかもしれない。機能を表紙にあるようなヘックス図で整理して、多ければ統合して関数にすることで認識する量を減らす。あとサイクロマティック複雑度はわかりやすくて良かった。テスト駆動の部分は理解しづらかったかも。。。あと具体例のコードを追いながらじゃないと読めない気がした。。。コードの方は読めてない。いつかリベンジする。

2024/08/15

[sho_kisaragi]

255ページからのプラクティス一覧がとても便利。 人間が読めるコードを書くためのプラクティスを一切合切集めてまとめた本です。まず最小限、人がプログラミングするべき約束事はここを見れば良いと判断できます。これで全てではないでしょうが、ここで実現・実装できることは実施すべきと思われる内容がほとんどです。 いったいどこに読みづらさの課題があるか、そしてそれをいかに読みやすくするべきかを、ここで学んで、リーダブルコードへと進めていくヒントにしてください。

2024/07/01

[ottylab]

エンジニアとして無意識にやっているようなことが言語化されていてとてもよかった。特に最クロマティック複雑度をメトリクスとしたヘックスフラワーは自分が作った関数が既に大きすぎるかどうかを測るのにとても良さそう。また、トラブルシューティングで出てくるgit bisectはあまり使ってこなかった。これは、私が作成するコミットの粒度が大きいことに起因する（開発の意味単位でまとめようという意図がある）が、本書ではドライバー単位で小さくコミットしておりその方がメリットが大きいと感じた。コードを見ながら2回目を読む。

2024/06/30

[むらむー]

ソフトウェア開発をプログラミング（個々の技量によったり、作ったらおわりなもの）からエンジニアリング（スケーラブル、サステナブルなもの）にするためのTIPSが詰まった本。 技術書の名著から引用されているTIPSが多く、うまくまとめられていて、良い振り返りになりました。 個人的に一番刺さったのは「メソッド名でつたえられることはコメントに書くな。型で伝えられることをメソッド名に書くな」というTIPS。後半部分があまり意識してこなかったものだったので、これから取り入れていきます。

2024/06/30