「脳に収まるコードの書き方」を読んで学んだこと

読書シェア会 vol.4
https://yumemi.connpass.com/event/349910/

Transcript

1. 「脳に収まるコードの書き方」 を読んで学んだこと 読書シェアNo.4 mikan( 一瀬喜弘)
2. 自己紹介 object Mikan { val name = " 一瀬喜弘" val company = "karabiner.tech" val work = Engineer.Android val hobby = listOf( " 漫画", " アニメ", " ゲーム", " 折り紙", "OSS 開発・コントリビュート", ) }
3. 書籍紹介 脳に収まるコードの書き方
4. 学び​ その​ 1. 建築の​ メタファーは​ 害悪である
5. 1.1 開発 = プロジェクト と勘違いしてしまう プロジェクト=> 始まりと終わりがある
6. 1.1 開発 = プロジェクト と勘違いしてしまう プロジェクト=> 始まりと終わりがある 開発 => 次の開発が始まる
7. 1.2 建築フェーズは存在しない 家の建築 設計→建築 " 設計" = クラス設計、要件定義？ " 建築" = 実装？ 本書での解釈 " 建築" = コンパイル → 人間の仕事ではなくコンパイラの仕事 開発にかかわる、人間がやる作業は全て「設計」 コードを書くことも「設計」
8. 学び​ その​ 2. テストが​ 実装を​ ドライブする​ 意味が​ 分かった
9. 失敗するテストが実装をドライブする TDD = 「レッド→グリーン→リファクタリング」のサイクル 「グリーンから始めちゃダメなの？」 TDD の本当の強みは、実装方針が立てにくいときにある どういう動きをしてほしいかは分かる。でも、それをどう実装するかはまだ決まってない。 まずテストを書く → 最小限の実装（ハードコーディングでもOK ） → パターンを増やす → リファクタリング × 理想の実装で悩む ◦ 目の前の失敗しているテストを通す テストがあるから、安心してリファクタリングもできる。
10. ほかにも コミットメッセージは​ どう​ 書けば​ チームに​ 伝わるか？ レビューでは​ 何を​ 見るべきか？​ どんな​ スタンスで​ 臨むべきか？ などなど、​ 「現場の​ 実感に​ 即していて」​ 「でもちゃんと​ 筋の​ 通った」​ アドバイスが​ 詰まってる​ 一冊でした。