借金コードを
残すな！

～あなたが(会社|部署)を去る時
後ろ指を指されないために～

プラットフォーム開発第一
西田 和史

お疲れ様です

そろそろお腹減ってきました。

ピザ、パスタ、等のご飯とお酒は
17時解禁らしいです。

もうすこし我慢しましょう

借金コードとは？

以下のようなコード

 

• コピペ（ほぼ同じコードが複数含まれてる）
   
• 不要な機能（クラスやメソッド）
   
• リファクタリング0（コードの整理がされてない）

なぜ借金？

将来のコストになるから

• コピペ
  • 機能がメソッドやクラスに集約されてないため
    改修範囲の特定・改修そのもののコスト増
• 不要なクラス階層
  • 不要なのにコード量を増やすので改修・把握のコスト増
• リファクタリング0
  • 構造が整理されておらず特にコードを初めて見る人のコストが増える。また日常的な修正でも知らず知らずのうちにコストを払っている

借金コードが増えると
どうなるか

• 新規メンバーの学習コストが増加
  • → 初期開発メンバーしかシステムを見れなくなる
    • → もっと進むと保守・改修そのものが不可能
      ​
• 機能追加・修正が非常に難しい
   
• 何をやってるかが整理できてないので
  新システムへの置き換えすら困難

パターン① コードのコピペ

• 説明：
  • ほぼ同じ処理なのにクラス・メソッドへ集約せず
    コードをコピペする
     
• どういうときに起こりがち？
  • コピペが悪いと思っていない
  • 時間がないという言い訳
    ​
• 対策
  • コピペ検出ツールをCIサイクルへ導入
  • レビューでコピペを許さない

パターン② 不要なクラス階層

• 説明：
  • 冗長なクラス階層や、切り出し方の不適切なクラス
     
• どういうときに起こりがち？
  • DDDやMVCなどの背景思想を理解せず、コードで表現することに傾倒しすぎる
  • 将来使う、と思ってコードを書く
    （実際には90%の確率で使われない: YAGNIの法則)
  • オブジェクト指向をよく理解してない
     
• 対策
  • 基本であるYAGNIの法則・KISSの法則を周知

パターン③ リファクタリング0

• 説明：
  • 機能追加や改修が行われた・設計上のまずい構造が見つかったにもかかわらずリファクタリングがされない
     
• どういうときに起こりがち？
  • リファクタリングをそもそも知らない
  • リファクタリングのメリットが理解されてない
  • 開発体制上リファクタリングが認められてない
     
• 対策
  • リファクタリングを開発サイクルに取り込む
  • （バッドノウハウ）：機能改修と合わせてリファクタリング

立つ鳥跡を濁さず、
借金コードを残したまま
（会社｜部署）を去らないように
しましょう

おわり

参考

• エンタープライズアプリケーションアーキテクチャパターン
  • トランザクションスクリプトパターンとドメインモデルの章
• YAGNIの法則
• KISSの法則
• Java言語で学ぶリファクタリング入門