Download to read offline
Dev love関西 レガシーコードへの取り組み 20140325
- 1.
- 2. 自己紹介 菅原 誠一 •京都にある精密機器製造会社勤務 •生産技術 – 社内工場のソフト開発、保守、運用など – 工場からの問い合わせ対応 •入社10年目
- 3.
- 4. 青年海外協力隊 • JICA（独立行政法人国際協力機構）が支援する、 発展途上国でのボランティア活動。 • 派遣期間：2年 • 派遣国：70カ国 • 派遣人数：1758名（男757名、女1,001名） （2014年1月） • 職種：200種以上（農業、土木、教師など多数） • 対象年齢：２０～３９歳 • 派遣期間中は、現地生活費と積立金が支給
- 5. モザンビーク基礎情報 • 面積:80.2万平方キロメートル（日本の約2.1倍） • 人口:2,137万人（2007年） • 独立：1975年 • 内戦：1982年～1992年 • 首都:マプト（人口約107万人、2005年） • 民族:マクア・ロムウェ族など43部族 • 公用語:ポルトガル語 • 現地語：民族語との土着語（マクア、シャンガネ） • 宗教:キリスト教（41％）、イスラム教（17.8％）、原始宗教 • 気候：温暖（沖縄に近い）
- 6. モザンビークはどこ？ ① ② ③ ①ガーナ ②ソマリア ③モザンビーク
- 7. CDT（CENTRO DE DESENVOLVIMENTOTECNOLÓGICO）
- 8. 授業の風景 • 授業 – プログラミングI、プログラミングII • JAVA基礎、応用 – オブジェクト指向プログラミング • UML – WebプログラミングI、 WebプログラミングII • PHP、MySQL基礎、応用 • 学校の機器のメンテナンス – PCの修理、ウィルス除去
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19. まだ、道の半ば 今日はみなさんと一緒に レガシーコードについて考えたいと思います よろしくお願いします
- 20. 本日の内容 • 私の現場のレガシーコードの紹介 • TDDの導入（2012/10～） – テストのないコード増加に歯止め – レガシーコードでのTDD作業 • 受け入れテストの自動化（2014/2～） – 大きくテストで保護 • この一年の振り返り • 今年したいこと
- 21. レガシーコードとは？ 『何年も前に誰かが作り、 内容が複雑で何をしているのかよく分からず、 まともな仕様書もない』 http://codezine.jp/article/detail/4103 『単にテストのないコード』 テストのないコードは悪いコードである。どれだけうまく書かれているかは関係ない。 どれだけ美しいか、オブジェクト指向か、きちんとカプセル化されているかは関係ない。 テストがあれば、検証しながらコードの動きを素早く変更することが出来る。 テストがなければ、コードが良くなっているのか悪くなっているのか本当に分からない （レガシーコード改善ガイド はじめにより）
- 22. 現場のレガシーコード • 言語 – C++ • クラス数 – 1446個 • コード – 642131行 • 生産技術のノウハウの塊 • 生まれから10年はたってる？（不明） • 今も日々成長している
- 23. なぜ、レガシーコードに こだわるのか？ •捨てられない – 生産技術のノウハウの塊 – 誰も仕様を知らない、ドキュメントなし • 人が育たない – レガシーコードをお手本にしている現実 – 動けばいいんじゃないの？ – 自分も書いてきた・・・ • モチベーション – 仕事をすればレガシーコードが増える – 新規に作り直したとしても、また、レガシーコード
- 24. 現場で困っていること • 新規機能追加 – 既存の振舞いを変えずに、新しい振舞いを追加する • 新しい振舞いを追加 – みんな興味ある⇒お金、時間、人 • 既存の振舞いを変えず！ – ほとんど考慮されない⇒保証して当然だと思わる – 変更の規模に関わらずコストはかかる – どんどん負荷は増えていく 細々した 変更が多い 追加コスト ＜＜＜＜ 既存の振舞いの保証コスト
- 25. 目指している事 • 既存の振る舞いを保証するための工数を減らす • 改造規模に見合った工数を実現したい • 手段 – テストの自動化 • テストの無いコードを減らしたい ＝レガシーコードを減らしたい！
- 26.
- 27. TDD技術取得 • TDDBoot Camp – 短期間でテスト駆動を体験 – ペアプロ体験 • 2013年6月 Agile Academy 版 • 2013年8月 岡山開催 – チーム員 4名で参加 • 2013年8～12月 – 社内で読書会 – 遊び感覚でペアプロ TDDのこころ（和田卓人） • 一番ひどいコードをテストフレームに入れる
- 28. レガシーコードでTDDで実践 • テストフレーム内に入らない – 激しい依存関係 – そもそも構造がない – GUIコントロールと設備の制御が混ざっている・・・ やたら時間がかかる！ • 仕事は待ってくれない・・・ • 時間がないから、TDD出来ない・・・ • TDDしたりしなかったり・・・ • どうやったら出来るかな？
- 29. 当時困っていたこと 新しい人の戦力化 経験による 知識 ソフトの 知識 ベテラン 新しい人 工場内ソフト ソフトの内容は 分かったけど・・・ ノウハウの塊 実物を 知らない人への 説明が難しい
- 30. OJT（On-the-Job Training） と組み合わせる • 2014/1～ • 教育を口実にペアプロとTDDの工数を確保 • Win-Win – 自分 • コーディングしながら説明 • 社内文書作成、手動テストを任せる⇒時間 • コードの内容を知っているので安心 – 新しい人 • 意味不明なコードを触ることの不安の解消 • 知らないと分からないことで費やす無駄な時間の短縮
- 31. ペアプロの効果 • 集中出来る • 思い込みによる間違いを防ぐ • 妥協できなくなる • 冷静になれる • 学習効果（予習⇒実習⇒復習） – テストフレームに入れる⇒TDD⇒書類作成
- 32.
- 33. 仕事の流れ こんなのしたいのだけど 変更内容を検討 プログラム 社内書類作成（仕様書） テスト⇒社内審議 工場にリリース 現場責任者
- 34. 出荷製品の確認ソフト このソフトの機能 •工場のオペレーター用 •注文情報の参照 •製品内部情報を取得 •注文情報と製品内部情報を比較 •オペレーターに結果を表示 •確認結果を保存 製品 注文情報 間違いなく 製品が 作られていることを 確認する
- 35. 新製品でも この確認ソフトを使いたい 従来製品製品C 製品A 製品B 新製品D 現場責任者
- 36. 調査結果 • 変更箇所 – クラス：FormMain – メソッド：CheckGas • 変更内容 – 確認するパラメータ数が従来製品と違う • 従来1～4個⇒5個 • パラメータを持っていない
- 37. レガシーコードでTDD 0. 変更したいクラスをテストで保護 1. 失敗するテストケースを記述 2. コンパイル 3. テストを通過させる 4. 重複を取り除く 5. 繰り返す ココ レガシーコード改善ガイド P104 TDDのこころ（和田卓人）
- 38. まず、テストフレーム内で TFormMainの実体化に挑戦 •クラス：FormMain • 2000行 • メソッド：CheckGas • 171行 • メソッドの機能 • 製品情報を取得 – 製品との通信機能 • 注文情報と内部情報を比較 • オペレーターに結果を表示 – GUI操作
- 39.
- 40. 方針を変える • テストフレームに入れる対象を小さくする • メソッドオブジェクトの取り出し（P345） – 大きなメソッドをクラスとして取り出す – 対象行数：2000行⇒171行 • コンパイル任せ(p331) – 変数がない→メンバー変数追加 – メソッドがない→インターフェースの抽出(p377)
- 41.
- 42. 既存機能の保護 • 仕様化テスト(p200) – 製品A、B、Cに対する機能の保護 製品A 製品B 製品C • 偽装オブジェクトの作成(p27) – 製品との通信 – 画面とのインターフェース • テストを書く – 製品A、B、Cに対して仕様化テスト
- 43.
- 44. TDDで機能追加 • 追加したい機能のテスト書く • テストが失敗することを確認 • テストを通過 • リファクタリング • 『メソッドオブジェクトの取り出し』で取り出したクラスを、 元のクラス（FormMain）に戻す • 作業時間3時間
- 45. ふりかえり • TDDで変更 – 実体化失敗 2時間 – メソッドオブジェクトの抽出 1.5時間 – 仕様化テスト 5時間 – 機能追加 3時間 • 合計工数 11.5時間×２人 =23時間 • 従来のやり方 – 変更3時間くらい（推測） 純粋にコーディングの 工数だけを見ると ７倍以上
- 46. 23時間の工数は妥当か？ • 従来のやり方で、誰がしても3時間？ • プログラム以外の工数11時間は新しい人に任せることが出来た • 教育には結構時間がかかる • 過去の負債はいつかえすの？ 調査 プログラミング データ更新 テスト 書類作成 リリース 従来のやりかたを 続けている限り 永遠にレガシーコード はなくならい 作業の割合
- 47.
- 48. レガシーコードのジレンマ コードを変更するためには、テストを整備する必 要がある。多くの場合、テストを整備するために は、コードを変更する必要がある レガシーコード改善ガイド Ｐ19 • 対策 ペアプロ レガシーコード改善ガイド Ｐ333
- 49. もっと大きな網が欲しい • 思い切ったコードの変更をしないとテストフ レームに入らないコード • 手動テストの負荷がどんどん増えている • 手動テストのミスが多くなっている 受け入れテストの自動化 がしたい！
- 50. GUIのテストは 一般的に難しいと言われているが •工場内アプリの環境はかなり特殊 – 操作画面は変わらない – 操作画面はシンプル • 自動化出来ない要因 – 工場でないと接続できないハードウェア – 計測器の出力が必要 – 工夫すれば回避可能 • コストに見合わない？ – 毎回、同じテストをしている – 手作業によるミスを頻発 • 一番知っているのは自分
- 51. じゃあ、なんでやらない？ • 自分が今の業務を続けている限り、今の業務は回るから • 自動化するには、自分が今の業務から抜ける必要がある 誰か変わってくれ～
- 52. 自分の時間を確保 • 人を育てる – OJT：ペアプロ、TDD • 一応、筋は通す – 上司にお願い ⇒OK – 社内の報告会でテスト自動化による工数削減を説明 ⇒なんでやらないのかと言われる • 日常の業務は次から次へとやってくる 日常業務を断つ
- 53. 育児時短勤務 • 2014/4/1スタート • 8：30～15：15 • 1日6時間勤務 • 圧倒的に時間がない • 家族の事情です • 2012/10に会社に報告 吉と出るか？ 凶と出るか？
- 54. GUI自動化ツール • Codeer.Friendly（コーディア・フレンドリー） – 株式会社Codeer(コーディア) • http://www.codeer.co.jp/home • 特徴 – プロダクトプロセスを、「プログラムレベル」で、テ ストプロセスから操作することができます – 小規模な結合テスト～GUIテストまで対応します • 選んだ理由 – C#でプログラム出来る – 工場内でしか使えない計測器の疑似入力を内部 メソッドを呼ぶことで実現したい
- 55. この一年間の振り返り • TDD技術の取得（TDDBC、読書会） • OJTとしてペアプロを導入、TDDを実践 • 人を育て自分の仕事を引き継ぎ • テスト自動化の準備 • 日常業務を断つ • 自分の時間を確保
- 56. レガシーコード改善自体は楽しい • フレームワークに入れたときの達成感 • パズルゲームのような楽しさ • 仕様化テストを書いた後の征圧感 • 過去の作業者の思考に思いを巡らす • 劇的にコード量が減る爽快感 • コードが綺麗になっていく • コードが本来の姿を取り戻す
- 57. この1年、悩んできたこと • TDDが良いと分っていても、TDD出来ない • 自動テストにした方が良いと分っていても、自 動化出来ない • どうやったら、現場で実践できるか？ • 現場特有の問題と組み合わせることで上手く 行くこともあった（OJT） • 自分の状況を利用してみたりした（時短勤務）
- 58. 今、感じている事 • マネージメントの問題ではないのか？ – 時間、人 • 混乱した現場⇒レガシーコードが生まれる？ • 自らのマネージメントする – 自らの強みを知る • 工場、生産工程、知識 • リファクタリングが好き – 時間を管理する • 何に時間を取られているのか？ – もっとも重要なことに集中する • 手作業⇒自動化
- 59. 参考になった本 自分の強みは何か？ 時間を管理する ストレングス・ファインダー 才能とは、無意識に繰り返される思考、感情、行動のパターン 7つの習慣実践例 今抱えている仕事を 全部吐き出す 一日の初めにスケジュール を立てる
- 60. 思い込みを解くゲーム あなたが今解決したいことを思い浮かべてください Step1出来ない理由を上げてみてください （多ければ多いほどいい） Step2 文章を反転して、出来るに変えてみてください 例） 自信がないから、勉強会が出来ない ↓ 自信がないから、勉強会が出来る 自信があるから、勉強会が出来る P228 ①どの文章に自分の感情が反応しますか？ そこに気づきがあるかもしれない ②無理やりにでも出来る理由を並べると、出来る気がしてくる
- 61. 今年の目標 • 片付けには2種類ある – 祭りの片付け • コツ：一気に、短期間に、完璧に片付ける – 日常片付け 祭りの片付け 受け入れテストの自動化 CI環境の導入 新しい開発環境へ移行
- 62.
- 63.