20140927_レガシーコード改善勉強会のメモと感想

概要

• 2014/9/27(土) 11:50～2014/9/27(土) 18:30
• レガシーコード改善勉強会

セッション1 「レガシーコード改善のススメ」

• 平澤 章さん
• レガシーコード改善ガイドの内容について翻訳者自ら紹介
• 翻訳当時のこぼれ話など
• レガシーコード改善ガイド読まずに潜り込んでいたので、ありがたかった

セッション2「テスト、リファクタリングに関する深い方法論」

• きょんさん

テストとリファクタリングに関する深い方法論 #wewlc_jp from Kyon Mm

• アーキテクトのための方法論の話が中心だった気がする。深かった
• タスクマネジメントの方法として「Mikado Graph」が紹介されていた
• レガシーコードに対してMikado Methodを適用することにより、
  実際にコードを書きながら、そして捨てながら仕様を安全に把握できる
• 心配事を洗い出せる。可視化できる。可視化できるので共有できる

セッション3 「レガシーコードとの付き合い方と、そのテストでの話」

• goyokiさん

レガシーコードとの付き合い方とテストでの話 from H Iseri

• レガシーコードと対峙するに当たって
  • 前任者、マネージャとのコミュニケーション
    • ストレートに言うだけでなく工夫が必要
    • 状況を理解してもらう。フィードバックを得る
    • なんでレガシーコードになったのか？要因を知る
    • 要因を分析することで、コミュニケーション材料になる
    • 根拠の蓄積、共有（メトリクス->露骨な異常値になる、アンケート・意見、類似プロジェクト理想状態との比較）
    • 共有大事（計画書、コミットログ等に含めて根回しする）
    • 協力を得ながら進める
      • レガシーコードになった原因は、制約のせいに、自分を含めたチームのせいにする
      • 相談、嘆願でなく改善の提案、チームで改善、問題共有
    • 三種の神器
      • バージョン管理、自動テスト（CI、品質を評価、テストの妥当性）、自動化（ビルドやデプロイ）
      • テストの自動生成
    • 品質リスクに備えてからコードに手を付ける
      • ミスの流出の防止 cover&modify（テストを書いてから修正）
      • アプローチの妥当性を確保
      • 変更ミスを防ぐ作り込み
      • ボーイスカウトルール等

セッション４ 「納品のない受託開発を支える、レガシーコードを作らない仕組み」

• 西見 公宏さん

納品のない受託開発を支える レガシーコードを作らない仕組み from Masahiro Nishimi

• インフラも含めてコード
  • コードもインフラも変更できるように保つ必要がある
• レガシーコードを作らない仕組み
  • 納品のない受託開発
    • 継続して開発するビジネスモデル
    • 変更すること前提（変更コストを最小化する）
    • 変更しやすい良いコードは利益につながる
    • ビジネスモデル自体がレガシー化抑止につながる
  • 技術の共通化でアップデートを容易に
    • 全サービスで同じ言語、フレームワーク、インフラを使う
    • 選択した技術の問題ではなく、システムの複雑化の問題
    • LCCに学ぶコスト戦略を応用
    • LL言語の特性
      • バージョンアップが活発
    • バージョンアップには追随する必要あり（言語、フレームワーク、OS、ミドルウェア）
      • セキュリティ
      • 少しずつ追従しないと後にコスト大
    • 共通化でバージョンアップのコスト削減できる
    • 共通環境のエンジニアによるレビュー
      • 共通知識が無いとレビューできない
      • レビューしない -> 読めないコード -> レガシー化
  • テクニックではなく、仕組みでレガシー化を防ぐ

つい言語とかフレームワークを統一せずに自由にやりたくなるが、
戦略的に技術を統一することも重要だなあ、と思った。
LCCに学ぶとかも面白かった。

セッション5 「レガシーコードを改善した先にあるもの、それは継続的インテグレーション」

• 佐藤 聖規(さとうまさのり)さん

レガシーコードを改善した先にあるもの、それは継続的インテグレーション from Masanori(Lino) Satoh

（この辺から疲れてきた）

• VCS使ってない人ー？
  • いなかった。よかった
• CIツール
  • jenkinsが好き
  • jenkins以外にもあります
• ツールを入れて終わりにしない

セッション6 「PHP版レガシーコード改善に役立つ新パターン」

• 佐藤　裕司さん
• PHP版レガシーコード改善
  • テストを書けるように
    • 関数オーバーライド
      • 名前空間を利用して上書き
    • ラップ関数
      • 変数の参照等を関数経由で
    • 環境の分離
      • テスト対象とテストコードで名前空間を宣言
    • スーパーグローバル変数の間接参照
  • テストで保護
  • リファクタリング

PHPのレガシーコードに悩まされる人は多いと思うが、
なんとなく、PHPで書かれたレガシーコードは少しずつ改善するよりも、
一気にWAFに載せたり、別言語で実装し直したりすることが多い気がする。
逆にこういう方法論が共有されて助かる人は多いと思った

セッション7 「レガシーコード改善の戦略と戦術」

• 和田 卓人さん

• 【悲報】銀の弾丸はない

• テストを目的化してはいけない

• ストレスと手動テストはネガティブフィードバックの関係

  • ストレス -> 手動テスト（ストレスが大、手動テスト小）
  • 自動テスト -> ストレス（自動テスト大、ストレスが小）
  • テストを書かないから時間がない

• 文化を変える

  • 年単位
  • 「動くコードに触れるな」触れなければコードは緩やかに死んでいく
    （言語、フレームワーク、ミドルウェアのバージョンは上がっていく）
  • 「イマココ、将来こうなりたくない」から始める
  • 人は自分の速度でしか成長できない
  • 人を知る
    • 行動原理が人によって違う
      • 快、不快で動く人
      • メトリクスが好き人
      • ビジネス価値を重視する人
  • リファクタリングしたいというとリファクタリングできない呪い
  • Grace Hopper "事前許可より、事後承認のが楽"

• すべては変化する

  • 仕様、開発、理解、スキル、技術

• 技術的負債の四象限

• テストは品質をあげない、品質がわかるだけ

• 体重計に乗るだけでは痩せない

• テストで支えられた再設計、リファクタリングで質があがる

• どこからやるか

  • やばいところから、困っていることろから（ビジネス上クリティカルな部分等）
  • 状況による

• だれとやるか

  • 教えられる人を増やす
  • ペアプロ
  • 状況による

• こだわらないこと

  • 最初から全部やろうとしない
  • TDD、テストファーストにこだわるな
  • TDDやってるから偉いってわけじゃない
  • 目の前の問題に自分で自分のやり方で自身を持って取り組めること、手応えが大事

• こだわること

  • 再現できる、繰り返し可能
    誰のところでも同じように繰り返し実行可能なテスト
  • 独立性
    テストの順序関係、依存関係は無くす（ランダムにテスト実行する）

• レガシーコード改善ガイド

  • 仕様化テストのススメ
  • 絞り込み点を探す

• 見える化

  • レガシーコードは膨大であることがある、頭の中だけでは把握し切れない
  • 割れ窓理論
  • メトリクス（カバレッジ低いときは効果的）
  • 時系列変化（傾き）に注目

• 静的解析を使いこなす

  • 動かさずに良さ、悪さを検証

• 設計の可動域を確保する

  • テストが無いのは既に設計が悪い
  • 設計・実装を変えるのが前提
  • 今ある実装に密接なテストは書かない
  • テスト範囲が広い -> 設計の可動域が広い
  • E2Eテスト

• コードレビュー

  • レビューのインフラを整備
  • 見られる意識重要

• コードの重要な性質

  • 迷ったらシンプルな方を
  • simpleとeasyは異なる
    • http://eed3si9n.com/ja/simplicity-matters
    • easyはコンテキストに依存する
  • モジュール化
    • simpleなものを組み合わせてcomplexなものを作る
    • unix思想

• 背中を見せること

  • サンプル、デモ
  • サンプルコピペからでもいい、体験してもらうこと大事
  • 次はテストコードのメンテ
  • 自分がテストを書く
    • 自分書かなければ周りも書けるようにならない
  • コードを毎日commit Write Code Every Day

他の方のちゃんとしたまとめ

レガシーコード改善勉強会 2014/09/27 #wewlc_jp