作者: Pete Goodliffe,柴田芳樹
出版社/メーカー: オライリージャパン
発売日: 2017/12/15
メディア: 単行本（ソフトカバー）
この商品を含むブログ (4件) を見る

読書開始日
読もうと思ったきっかけ
本書の目次
まとめノート

読書開始日

2017.01.14

読もうと思ったきっかけ

なんとなく目に入って、目次を見た感じ、良さそうだったから買った。

本書の目次

1章　コードを気にかける
2章　見かけのよい状態を維持する
3章　少ないコードを書く
4章　取り除くことでコードを改善する
5章　コードベースの過去の幽霊
6章　航路を航行する
7章　汚物の中で転げ回る
8章　そのエラーを無視するな！
9章　予期せぬことを予期する
10章　バグ狩り
11章　テストの時代
12章　複雑さに対処する
13章　二つのシステムの物語
14章　ソフトウェア開発とは
15章　規則に従って競技する
16章　単純に保つ
17章　頭を使いなさい
18章　変わらないものはない
19章　コードを再利用するケース
20章　効果的なバージョンコントロール
21章　ゴールポストを抜ける
22章　凍結されたコードの数奇な人生
23章　プリーズ・リリース・ミー
24章　学びを愛して生きる
25章　試験に基づく開発者
26章　チャレンジを楽しむ
27章　停滞を避ける
28章　倫理的なプログラマ
29章　言語への愛
30章　プログラマの姿勢
31章　一生懸命ではなく、賢く
32章　完了したときが完了
33章　今度こそ分かった……
34章　人々の力
35章　原因は思考
36章　遠慮なく話す
37章　多くのマニフェスト
38章　コードへの叙情歌

まとめノート

you write (code)

見かけの良い状態を維持する

レイアウト論争は不毛。
プロジェクトで統一することが大事。
制定する場合、根拠を付ける。

少ないコードを書く

ソフトウェアの機能は、コード量に依存しない。
だから、なるべく書かないほうがいい。
ただし、読んで分からなくなるレベルに少なくコードを書くのは良くない。

少ないコードのデメリット

保守範囲がデカい
保守コストが高い
可読性が悪い
修正量が多い
バグの隠れる場所が多い
複製するとバグも複製されやすい

取り除くことで改善する

システムの改善は、コードの削減でもできる。
死んでいるコードは邪魔なだけ。
プロジェクトが大きくなるほど、死んだコードも大きくなる。
放置するのは、失敗の兆候になり得る。

コードベースの過去の幽霊

古いコードは、宝の山でもある。
そこから学べることもある。それは、いい面・悪い面も含む。
過去を知ることで、スキルを知ることができる。

航路を旅行する

コードを知るには、プロジェクトを知っている人に導いてもらうのが、一番早い。
助けを求めることを恐れてはいけない。

システムの理想は、いくつか存在しているが、忠実に再現するのは難しい。
ちゃんと現実を見据えて行動を起こさなければならない。

汚物の中で転げ回る

コードは、知らないうちにひどくなる。
ひどいコードに対策できる準備を、常日頃からやっておく必要がある。

あえて酷いコードの中に入ることで、改善方法を学ぶこともあり。
できの悪いコードは、意図してできているわけではない。

そのエラーを無視するな

エラーは、何か原因があって出る。
無視・先延ばしは、問題の解決になってない。
あとでしっぺ返しが発生する可能性がある。

予期せぬことを予期する

コードを書く際は、可能性のある全てのルートを考慮する。
例外的なルートも、なるべく適切に対処する。

バグ狩り

その場しのぎのコードは、メンテナンスコストが高くつく。

テストの時代

改善するには、問題に気づく必要がある。
フィードバックは、早く頻繁に行われるほうがいい。

開発する場合は、テスト可能な状態にすることを心がける。

複雑さに対処する

複雑さを作り出すのは、人間であることを忘れてはならない。
複雑さには、必要なものと不必要なものもある。
必要な複雑さの見極めと管理方法を学ぶことが大切。

２つのシステムの物語

誤った設計は、誤った設計を更に呼ぶ、呼び水になる。
人によって起きる問題で、政治的な背景があることが多い。

アーキテクチャがシステムに与える影響は大きい。
呼び水にならないように、変更できるように単純に保っておく。
現状を嘆かず、どうすればいいのかを考えるのがエンジニア。

練習することで完璧になる

ソフトウェア開発とは

プログラミングには、美的感覚が必要なこともある。
しかし、思いつきのコーディングはダメ。常に自問自答して、答えを探る。

単純に保つ

単純な説明のメリット

説明の簡略化
理解・図解しやすい
誤用対策になる

バグの改修

早まった最適化は、不必要な複雑さを呼ぶ。
暗黙の想定を作らない。
適度な改修ではなく、必要十分な対処で満足する。

頭を使いなさい

単純なこと≠考えなくていい

応急処置をせず、責任を持って対処する。

変わらないものはない

変更は必ずあるもの。
変化に対応して、最適化する。ありもしない変化は、考えない。
変化に対応するためには、自動テストを開発に入れる。

コードを再利用するケース

コピペは、悪魔の所業。
やる場合は、正しさを理解してからやる。

再利用のための設計は、推測でやってはいけない。
推測で作ると、複雑さを内包したものができあがる。
必要になってから、再利用を考える。
それは、ライブラリ化、リファクタリングも同じ。

購入や車輪の再発明は、コストを考慮する。
排他的になることは、コストが高いことを考慮する。

効果的なバージョンコントロール

VSCなしの状態は、支柱のない家と同じ。
間違いが起こっても戻せないことは、致命的。
VSCは、セーフティーネット的な役割を提供してくれる。

効果的に使うポイント

リリースバージョンを明確にする
管理するファイル構成はシンプルにする
必要なものだけ管理
小さな意味のあるまとまりを頻繁にコミット
コミットメッセージは、単純・明瞭・完結を心がける

ゴールポストを抜ける

腐敗した開発環境は、下水道と一緒。
リリース前に待ち構えるＱＡチームに、汚水を流してはいけない。
品質は、全員で作ることを忘れてはいけない。

凍結されたコードの数奇な人生

コードの凍結は、変更しないリリース前の期間であって、永久に変更されないわけではない。

凍結中に、技術的負債を見つけて、凍結解除されたら改善に移れる準備をする。

プリーズ・リリース・ミー

規律と計画を作り、リリースサイクルを確立する。
早めに作って、頻繁に実行することが大切。

個人的なこと

学びを愛して生きる

何もしなければ、衰退するだけ。

学ぶことはいいことだが、集中しすぎると、視野が狭くなる。
多くの情報源を持ち、広い視野でいることは大切。

学んだことは、書き出す。
持っている知識を明確化する。積極的に使って、知識を定着させる。

試験に基づく開発者

有能になっても満足してはならない。
潜在的な危険は、いつも存在していることを自覚して、考えて開発を行う。

チャレンジを楽しむ

楽しみのために開発を行ってはならない。
どうしてもやりたいことがあるならば、計画を立ててやる。

停滞を避ける

安全地帯は、有害である。
さらに良くなることはない。
なぜなら、安全だから。

変化には、リスクが常につきまとう。
意図して投資しないと、成長はできない。

倫理的なプログラマ

やってはいけないこと

可読性の悪いコードを書く
ライセンス違反
中傷不正行為
不正行為を見逃す
働きすぎ

言語への愛

成長は、複数の言語を学ぶことで得られる。
複数の考え方・解法をしることで、多くの問題に対処できるようになる。

愛に必要なもの

尊敬
信念
会話
忍耐

プログラマの姿勢

同じことばかり考えない。
同じことばかり考えていると、解法がでないうえに、心も狭くなる。

一生懸命ではなく、賢く

生産的なプログラマは、賢く働いている。

賢く働くための戦術

賢く利用（車輪の再発明をしない）
他人の解答を見る
優秀な人の解答をパクる
やらなければならないことだけやる
一時的な解決策を試してみる
タスクに優先順位をつける
本質を理解する
シングルタスク
小さく実行
先延ばししない
自動化
会話
燃え尽きない

完了したときが完了

完了は、もしかしたら、完了したと思いこんでいるだけかもしれない。
タスクをこなすときは、完了を明確に定義する。
必要以上の完了を目指さないほうがいい。

今度こそ分かった・・・

ソフトウェア開発の問題は、人間の問題であることが多い。
多面的な見方で、解決方法を探る努力をする。

人々の営み

人々の力

優秀なプログラマになるには、環境が大事。
環境を変えるには、仕事を変えるか、イベントに出るしかない。
専門家の考え方を知るのが、優秀になる近道

原因は思考

明や理由付けしたり、批判を受け入れることを習慣化する。

遠慮なく話す

開発には、コンピュータとだけではなく、人と話す必要もある。
言葉選びにも注意する。

多くのマニフェスト

マニフェストは、原則の概要にすぎない。
常に正しいとは限らないので、過信せず、状況を見て判断する。

コードへの叙情歌

コーディングの問題には、人間の問題も含まれている。
健全な状態に戻すのは、急にできない。
考え方を少しずつ変えさせるしかない。