1. 良い状態とは
1.1. 開発が楽
1.1.1. 実装が早い
1.1.1.1. スケジュール内に実装が可能
1.1.1.2. 見積もり時と実際の作業工数で差が無い
1.1.2. コード記述量が少ない
1.1.2.1. ボイラープレートを書かなくて良い
1.1.2.2. 機能を満たすために必要最小限のコード変更だけで良い
1.1.3. 書いていてストレスが無い
1.1.3.1. 感覚なので分からん
1.1.3.2. システム2を使わなくていいみたいな感覚
1.2. ルールが明確
1.2.1. 手本となるコードが存在する
1.2.1.1. 同種の複数のコードで一つのルールに従っている
1.2.1.2. ルール違反している例が少ない
1.2.1.2.1. あってもコメントで補足されている
1.2.1.3. 手本となるコードを見つけやすい
1.2.2. このコードはどこに置くべきか迷わない
1.2.2.1. 適切な階層、グルーピングがされている
1.2.2.2. 階層やグルーピングが適切な名前付けがされている
1.2.2.3. 新しい概念のコードの場合にはどうすればよいかが分かる
1.2.3. 複数の書き方がある場合に自ずと一つを選択できる
1.2.3.1. 手本となるコードと同等
1.2.4. 書き方が混在していない
1.2.4.1. 手本となるコードと同等
1.2.5. ドキュメントが存在する
1.2.5.1. ルールを決めた背景を理解できる
1.2.5.2. 迷ったときに判断する基準を言語化している
1.3. チームメンバーが適切だと感じている状態
1.3.1. 感覚なので分からん
1.3.2. ただ感覚は感覚で聞きたい
1.3.2.1. これ以外で挙げている観点がすべてOKだとしてもここが駄目だと駄目
1.3.2.2. ここで挙げている観点以外のものがあるかもしれない
1.4. デプロイも怖くない
1.4.1. 変更の影響範囲が見えている
1.4.2. もし問題があっても対処手順が考えられている
1.5. テストを書くのが楽
1.5.1. 手本となるテストコードが存在する
1.5.2. すでに書いてあって一部変更するだけで良い
1.5.2.1. テストコードが無いという状態がそもそもない状態
1.5.2.2. テストコードを書くという文化が根づいている
1.5.3. コンポーネントをモックできる
1.5.3.1. DIが適切に使えている
1.5.3.2. 疎結合になっている
1.5.4. スタブできる
1.6. 新しく入ってきた人でも苦がない
1.6.1. 一般的に利用されているアーキテクチャである
1.6.2. あるいは一般的に利用されているアーキテクチャから大きくハズレていない
1.6.3. 世に知られたプラクティスを実践している
1.7. 公式が提唱しているベストプラクティスに則っている
1.8. ドキュメントを読まなくても自然と理解できる
1.8.1. コードがドキュメントとなっている
1.8.2. ドキュメントが膨大すぎない
1.9. 最新のライブラリやSDKを利用できる
1.9.1. アプリコードをメンテナンス出来ている
1.9.2. ライブラリやSDKのアップデートを適宜行っている
1.10. 何か機能を変更したいときにそのコードをすぐに見つけられる
1.10.1. 名付けが適切になっている
2. 悪い状態とは
2.1. 開発が大変
2.1.1. めちゃくちゃコード書かなきゃいけない
2.1.2. ボタン置くだけなのに1日かかった...
2.2. ルールが不明確
2.2.1. このコードここに置いて良いんだよね?
2.2.2. こういうやり方もあるんだけどどっちにすれば良いのか分からない
2.2.3. 毎回誰かに聞かなければいけない
2.2.4. PRのレビューで毎回議論になる
2.3. チームメンバーが微妙だなーって思ってる
2.4. デプロイ怖い
2.4.1. クラッシュするんじゃないかと不安になる
2.5. テスト書きづらい
2.5.1. モック作れない
2.5.2. スタブできない
2.5.3. spyしなきゃいけない
2.5.4. 手本となるテストコードがない