ユーザビリティや適切なタイミングでの更新といった外部品質は内部品質の表れである。
価値があると認められたソフトはユーザーの声に応えるために変更が必要になる。
そのため、変更可能で常に価値を提供できるようにしておく必要がある。
レガシーコードは変更が難しく修正は慎重に行う必要があり時間がかかります。
開発サイドの事情でユーザーの声に応えられないといった機会損失を避けるためにも
内部品質に拘っていきたいです。

ストーリーとは「何が」「何のために」「誰のために存在する」を１文で表すものだ。
開発者は"コードが実際にすべきこと"を知っていれば開発を始められる。
詳細に意識が向くとやり方(コーディングの仕方)に気が向いてしまい、コンテキストに
集中できなくなる。設計面でも新たな発見の妨げとなってしまいそうなので気を付ける。

機能がどのように使われるかを理解していないと、恐怖から必要以上に例外ケースなどの
設計をしてしまい作りこんでしまう。
限定的かつテスト可能なストーリー単位で作ることで作りこみすぎを回避することができる。
作りこんでなんぼという所があったので意識を変える。

ソフトウェアは形のある商品とは違うので計測の仕方も異なる。
ベロシティは品質を犠牲にすれば上げられるので生産性の指標として使うのは誤り。
7つのプラクティスの中でも「コーディングに使った時間を計測する」から
始めてみようと思いました。私は1日に1時間もコーディングをする時間が取れていないので
プロセスのどこかがおかしいので…。

ブランチは分けずフィーチャーフラグを用いて準備できていない機能は無効にする。
ブランチを分けてしまうと結合するのが遅くなる。結合は遅くなればなるほどリスクがある。
現在のプロジェクトではブランチが多用されていて管理や結合に時間がかかっています。
そもそもブランチを分けないという視点を持ち運用について考えていきます。

"教える"という行為はとても価値がある。
自分のタスクが進まなくなってしまうだとか、2人で1つのタスクを実施すると
単純にスピードが半分になってしまうと思い込んでいました。
しかし、実際は2人で1つのタスクを実施した方がアイデアも産まれ効率的に進むようです。
何より教えることで身についたり新たな気付きがあるということでした。

コードスタイルは個人の好みもあり話が発散しやすいです。
コードレビューでは設計と設計の採用理由を中心に確認することで
レビューアーにも気付きがあると思いますし、必要以上に時間もかからないと思うので
意識していきます。

他の人のコードを読んで、他の人の書き方を学ぶ。
他の開発者が問題をどのように扱っているのかOSSなどを眺めて学んでみます。

TDDで書くテストは①仮説/ふるまいの仕様②コードが期待したように動いていることの検証
といった2つの役割を果たすものになります。
TDDを実践することで仕様の理解を深めたり、仕様の漏れに気付けたりします。
すぐにコードが期待通りに動いているか検証しフィードバックを受けることで
バグ改修のコストを著しく下げることができるのでやっていきます。

定数もふるまいの変化を引き起こすのでアサーションするのが望ましい。

調査用にシーケンス図を書き起こさなくても読めるようにしておくと良さそう。
もちろん振る舞いを変える訳にはいかないので変数名のリネームから着手する。

コードが機能していて変更の必要がないならそのままにしておく。
市場で使われている機能はユーザーの声に応えるために変更する機会があるので、
変更が必要になった際は他のプラクティスを用いながら変更を行う。

1回目から適切にできたと考えているのであればそれは間違い。
1つの例だけで汎化するのは難しい。
複数の具体例を探し汎化することで正しい抽象化ができる。
最高のコード書いた～と思ってもバグっていることはザラにあるので心得ます。