糞コードの直し方メモ

傾向

• 不明確さ
  • 関数名が実装と合ってない
  • 何のための処理なのかサッパリ読み取れない
  • なぜか意味不明な空行が目立つ
• 依存関係
  • 関数が別の関数に依存しまくっている場合が多い
  • 処理をいくつかの関数に分けるのはいいが、単体で動かない関数は修正しにくく保守性最悪
  • バッサリカットしたいが依存しまくってる故に影響範囲が大きく修正が捗らない
• 泥沼テスト
  • 単体テストを書いておけばリファクタリングしてもバグらなくて安心
  • というのはテストの実装次第であり、単体テストが別の単体テストに依存し（DB保存処理が絡むケース）単体じゃなくなってるパターンが多い
  • さらにテスト用モックデータに固執しているテストも多く、テストの意図を読み解くためにまずはモックデータの解析をする必要がある
  • 実装の修正をしたいのにテストの修正がまず必要でそのためにはモックデータを見直す必要があり、実装修正の数倍かかることがほとんど

対策

• ここまでひどいケースは結局のところすべて書き直すしかない（時間の無駄だから）
• テストも無視するしかない
• 処理の流れを tree 形式でテキストにおこす
• その中で行われている必要な処理（仕様・要件）を箇条書きにする
• 最終的なアウトプット（APIならクライアントへのレスポンス）形式を把握する
  • これさえ正しければクライアントはバグらない
• 糞テストの解読（しかも超複雑）は時間の無駄になることがほとんど
• 糞コードも糞テストもそのまま触らず、新しい関数で新規実装しなおす
  • 関数間の依存関係の強い糞コードの場合は、別ファイルで一から書き直す

素早く修正するために

• 実装しなおしたコードはすぐにテストケースを書き、とにかく細かい単位で動かしてみる
• 最初の検討時間はできる限り短くし、動かした中で理解を深めていく