予防に勝る防御なし
問題発生を事前に防ぐ
正しい書き方というものがある
絆創膏を当てるな、正しい実践の積み重ねだと言っているsta.icon
1 できないことを禁止する → できていいことだけできるようにする
2 型つくって影響範囲を小さくしろ、文字列じゃなくて列挙型もつくれ
3 ドメインを理解してそれを構造（≒型）に反映させるのも大事、理解してないとうまく反映しづらい
4 Immutable使え、クローンを返すようにしろ、そうしないとどこかで破壊的変更や参照渡しからの全部更新されちゃいましたとか起きちゃうから
6 表明と例外を使い分けろ。利用者の責任のときは表明、プログラムの不備（起きたらおかしい）は例外
どっちつかずの設計になってしまうという
Easyは別のレイヤー（たとえばテスト用ヘルパー）でも提供できる
sta.icon
コンストラクタは二度呼べる、ウケる
（※ こちらは今回の講演の元となった講演のスライドとなります。こちらをカスタマイズして講演いただきました）
（そしてt_wada講演と言えばQ&Aでいかに引き出せるかゲーでもある）
Q: 手を出せない外部システムの影響を防ぐには？
Q: 今回取り扱った設計手法について、実践して試すには似た問題に当たるまで覚えておく必要があるかと思います。こういったことを実践していくにはどうやっていくのが良いでしょうか？
供養時間
１人で覚えておくのは無理があるので、スクラムのスプリント周期ごとに、前回の周期での振り返りや思い残しを供養する時間を設ける、というのを現場ではやっていました。実際には、翌スプリントの午前中2時間を使い、モブプログラミングで「こう出来たはず」「こうすればよかった」という振り返る時間を設けるなどしました。
まあ振り返りやなsta.icon
Q: 学習テスト（学習用テスト）をうまく運用・活用している例を知りたいです。学習テストとは「利用している言語やライブラリの挙動に関して書くテスト」という理解ですが、アプリケーションコードと同じ場所に書くのは違和感があります。 不安定なライブラリや仕様変更多いライブラリなどに備えて、の意味合いが強い
やりすぎると俺達がライブラリのテスト書いてるんだがなんで？になる
Q: （コードレビュー観点においても）どこまで Simple でどこから Easy なのかの境界やそういった勘所を養うためにはどうしたら良いでしょうか？
まずOSSのフレームワークは割とEasy
これはもう現代の潮流だと思うよsta.icon
設定よりも規約
Simpleは見分けやすい
Simple は Easyより見分けやすいです。Simple は少なさ、短さ、が概念としてあり、機能が多ければその時点で Simple ではありません。Simple とは 脳の認知資源を消費しないものであり、組み合わせて利用することになるので Easy にはなりません。
わかる。美的感覚というか「上手い」ってのが明らかにわかるよなsta.icon
でもそういう感覚含めて「実力」が無いと素通りしちゃう印象もあるsta.icon
Q: 今回の講演で取り上げられた問題は、言語（特に関数型言語）によっては言語仕様でカバーされている部分も多くありますが、問題解決している言語を利用するのではなく Ruby や PHP などのオブジェクト指向での開発を啓蒙するのにはどういう思いがあるのでしょうか？
既に開発されてプロダクトにはレガシーが多く残っており、また日々増築されているような状況です。増築する際にもっと堅牢にする、触ったところはきれいに書き直す、ということをしていかないと、どんどん辛い状況になっていきます。個人としてプログラマーとして使っている道具と、仕事場でお客様が使っている言語は違います。新しい言語の啓蒙は他の人がやっていますので、そうではない場所で「こうできる」というのを話していこう、と考えています。
現実的なレガシーの部分をやってる奴がいねえから俺が救うんだ