63
レガシーコードへの取り組み 事例紹介 菅原 誠一

Dev love関西 レガシーコードへの取り組み 20140325

Embed Size (px)

DESCRIPTION

at dev love kannsai

Citation preview

レガシーコードへの取り組み 事例紹介

菅原 誠一

自己紹介

菅原 誠一 •京都にある精密機器製造会社勤務 •生産技術

– 社内工場のソフト開発、保守、運用など – 工場からの問い合わせ対応

•入社10年目

2007~2009年 海外ボランティア

青年海外協力隊

• JICA(独立行政法人 国際協力機構)が支援する、発展途上国でのボランティア活動。

• 派遣期間:2年

• 派遣国:70カ国

• 派遣人数:1758名(男757名、女1,001名)

(2014年1月)

• 職種:200種以上(農業、土木、教師など多数)

• 対象年齢:20~39歳

• 派遣期間中は、現地生活費と積立金が支給

モザンビーク基礎情報

• 面積:80.2万平方キロメートル(日本の約2.1倍)

• 人口:2,137万人(2007年)

• 独立:1975年

• 内戦:1982年~1992年

• 首都:マプト(人口約107万人、2005年)

• 民族:マクア・ロムウェ族など43部族

• 公用語:ポルトガル語

• 現地語:民族語との土着語(マクア、シャンガネ)

• 宗教:キリスト教(41%)、イスラム教(17.8%)、原始宗教

• 気候:温暖(沖縄に近い)

モザンビークはどこ?

① ②

①ガーナ

②ソマリア

③モザンビーク

CDT(CENTRO DE DESENVOLVIMENTO TECNOLÓGICO)

授業の風景 • 授業

– プログラミングI、プログラミングII • JAVA基礎、応用

– オブジェクト指向プログラミング • UML

– WebプログラミングI、 WebプログラミングII • PHP、MySQL基礎、応用

• 学校の機器のメンテナンス – PCの修理、ウィルス除去

生徒達(1)

生徒達(2)

モザンビークと レガシーコードの共通点

混沌

レガシーコード勉強会 20140321. pptx

昔ながらのやり方

駄目なところを探し出すときりが無い

伝えたいこと

良いところを探す

信じる

そのうち素晴らしい 景色が見えてくるはず

まだ、道の半ば

今日はみなさんと一緒に

レガシーコードについて考えたいと思います

よろしくお願いします

本日の内容

• 私の現場のレガシーコードの紹介

• TDDの導入(2012/10~)

– テストのないコード増加に歯止め

– レガシーコードでのTDD作業

• 受け入れテストの自動化(2014/2~)

– 大きくテストで保護

• この一年の振り返り

• 今年したいこと

レガシーコードとは?

テストのないコードは悪いコードである。どれだけうまく書かれているかは関係ない。

どれだけ美しいか、オブジェクト指向か、きちんとカプセル化されているかは関係ない。

テストがあれば、検証しながらコードの動きを素早く変更することが出来る。

テストがなければ、コードが良くなっているのか悪くなっているのか本当に分からない

(レガシーコード改善ガイド はじめにより)

『単にテストのないコード』

『何年も前に誰かが作り、

内容が複雑で何をしているのかよく分からず、

まともな仕様書もない』 http://codezine.jp/article/detail/4103

現場のレガシーコード

• 言語

– C++

• クラス数

– 1446個

• コード

– 642131行

• 生産技術のノウハウの塊

• 生まれから10年はたってる?(不明)

• 今も日々成長している

なぜ、レガシーコードに こだわるのか?

• 捨てられない – 生産技術のノウハウの塊 – 誰も仕様を知らない、ドキュメントなし

• 人が育たない

– レガシーコードをお手本にしている現実 – 動けばいいんじゃないの? – 自分も書いてきた・・・

• モチベーション – 仕事をすればレガシーコードが増える – 新規に作り直したとしても、また、レガシーコード

現場で困っていること • 新規機能追加

– 既存の振舞いを変えずに、新しい振舞いを追加する

• 新しい振舞いを追加

– みんな興味ある⇒お金、時間、人

• 既存の振舞いを変えず! – ほとんど考慮されない⇒保証して当然だと思わる – 変更の規模に関わらずコストはかかる – どんどん負荷は増えていく

追加コスト <<<< 既存の振舞いの保証コスト

細々した 変更が多い

目指している事

• 既存の振る舞いを保証するための工数を減らす

• 改造規模に見合った工数を実現したい

• 手段 – テストの自動化

• テストの無いコードを減らしたい

=レガシーコードを減らしたい!

TDDの導入

2012/10~

TDD技術取得

• TDD Boot Camp – 短期間でテスト駆動を体験

– ペアプロ体験

• 2013年6月 Agile Academy 版

• 2013年8月 岡山開催 – チーム員 4名で参加

• 2013年8~12月 – 社内で読書会

– 遊び感覚でペアプロ • 一番ひどいコードをテストフレームに入れる

TDDのこころ(和田卓人)

レガシーコードでTDDで実践

• テストフレーム内に入らない – 激しい依存関係 – そもそも構造がない – GUIコントロールと設備の制御が混ざっている・・・

• 仕事は待ってくれない・・・ • 時間がないから、TDD出来ない・・・ • TDDしたりしなかったり・・・

• どうやったら出来るかな?

やたら時間がかかる!

当時困っていたこと 新しい人の戦力化

経験による

知識

ソフトの

知識

ベテラン

新しい人

工場内ソフト

ソフトの内容は 分かったけど・・・

ノウハウの塊

実物を 知らない人への 説明が難しい

OJT(On-the-Job Training) と組み合わせる

• 2014/1~

• 教育を口実にペアプロとTDDの工数を確保

• Win-Win – 自分

• コーディングしながら説明

• 社内文書作成、手動テストを任せる⇒時間

• コードの内容を知っているので安心

– 新しい人 • 意味不明なコードを触ることの不安の解消

• 知らないと分からないことで費やす無駄な時間の短縮

ペアプロの効果

• 集中出来る

• 思い込みによる間違いを防ぐ

• 妥協できなくなる

• 冷静になれる

• 学習効果(予習⇒実習⇒復習)

– テストフレームに入れる⇒TDD⇒書類作成

実際のレガシーコードで TDD作業実録

2014/3/13~3/20

仕事の流れ

変更内容を検討

プログラム

社内書類作成(仕様書)

テスト⇒社内審議

工場にリリース

こんなのしたいのだけど

現場責任者

出荷製品の確認ソフト

このソフトの機能 •工場のオペレーター用 •注文情報の参照 •製品内部情報を取得 •注文情報と製品内部情報を比較 •オペレーターに結果を表示 •確認結果を保存

製品

注文情報

間違いなく 製品が

作られていることを 確認する

製品A 製品B

新製品D

従来製品 製品C

新製品でも

この確認ソフトを使いたい

現場責任者

調査結果

• 変更箇所

– クラス:FormMain

– メソッド:CheckGas

• 変更内容

– 確認するパラメータ数が従来製品と違う

• 従来1~4個⇒5個

• パラメータを持っていない

レガシーコードでTDD

1. 失敗するテストケースを記述

2. コンパイル

3. テストを通過させる

4. 重複を取り除く

5. 繰り返す

ココ

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

0. 変更したいクラスをテストで保護

TDDのこころ(和田卓人)

まず、テストフレーム内で TFormMainの実体化に挑戦

• クラス:FormMain

• 2000行

• メソッド:CheckGas • 171行

• メソッドの機能 • 製品情報を取得

– 製品との通信機能

• 注文情報と内部情報を比較

• オペレーターに結果を表示 – GUI操作

格闘2時間

依存関係激しすぎる・・・

コンパイル出来ない

断念

方針を変える

• テストフレームに入れる対象を小さくする

• メソッドオブジェクトの取り出し(P345)

– 大きなメソッドをクラスとして取り出す

– 対象行数:2000行⇒171行

• コンパイル任せ(p331)

– 変数がない→メンバー変数追加

– メソッドがない→インターフェースの抽出(p377)

1.5時間後 捕獲成功!

既存機能の保護

• 仕様化テスト(p200) – 製品A、B、Cに対する機能の保護

• 偽装オブジェクトの作成(p27) – 製品との通信 – 画面とのインターフェース

• テストを書く – 製品A、B、Cに対して仕様化テスト

製品A 製品B 製品C

仕様化テスト終了

作業時間5時間

TDDで機能追加

• 追加したい機能のテスト書く

• テストが失敗することを確認

• テストを通過

• リファクタリング

• 『メソッドオブジェクトの取り出し』で取り出したクラスを、元のクラス(FormMain)に戻す

• 作業時間3時間

ふりかえり

• TDDで変更 – 実体化失敗 2時間 – メソッドオブジェクトの抽出 1.5時間 – 仕様化テスト 5時間 – 機能追加 3時間

• 合計工数 11.5時間×2人 =23時間

• 従来のやり方

– 変更3時間くらい(推測)

純粋にコーディングの 工数だけを見ると

7倍以上

23時間の工数は妥当か? • 従来のやり方で、誰がしても3時間? • プログラム以外の工数11時間は新しい人に任せることが出来た • 教育には結構時間がかかる • 過去の負債はいつかえすの?

調査

プログラミング

データ更新

テスト

書類作成

リリース

従来のやりかたを 続けている限り

永遠にレガシーコードはなくならい

作業の割合

Windowsアプリ 受け入れテストの自動化

2014/2~

レガシーコードのジレンマ

コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある

• 対策 ペアプロ

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

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

もっと大きな網が欲しい

• 思い切ったコードの変更をしないとテストフレームに入らないコード

• 手動テストの負荷がどんどん増えている

• 手動テストのミスが多くなっている

受け入れテストの自動化 がしたい!

GUIのテストは 一般的に難しいと言われているが

• 工場内アプリの環境はかなり特殊 – 操作画面は変わらない – 操作画面はシンプル

• 自動化出来ない要因

– 工場でないと接続できないハードウェア – 計測器の出力が必要 – 工夫すれば回避可能

• コストに見合わない?

– 毎回、同じテストをしている – 手作業によるミスを頻発

• 一番知っているのは自分

じゃあ、なんでやらない?

• 自分が今の業務を続けている限り、今の業務は回るから

• 自動化するには、自分が今の業務から抜ける必要がある

誰か変わってくれ~

自分の時間を確保 • 人を育てる

– OJT:ペアプロ、TDD • 一応、筋は通す

– 上司にお願い ⇒OK – 社内の報告会でテスト自動化による工数削減を説明 ⇒なんでやらないのかと言われる

• 日常の業務は次から次へとやってくる

日常業務を断つ

育児時短勤務

• 2014/4/1スタート

• 8:30~15:15

• 1日6時間勤務

• 圧倒的に時間がない

• 家族の事情です

• 2012/10に会社に報告

吉と出るか? 凶と出るか?

GUI自動化ツール • Codeer.Friendly(コーディア・フレンドリー)

– 株式会社Codeer(コーディア) • http://www.codeer.co.jp/home

• 特徴

– プロダクトプロセスを、「プログラムレベル」で、テストプロセスから操作することができます

– 小規模な結合テスト~GUIテストまで対応します

• 選んだ理由 – C#でプログラム出来る

– 工場内でしか使えない計測器の疑似入力を内部メソッドを呼ぶことで実現したい

この一年間の振り返り

• TDD技術の取得(TDDBC、読書会)

• OJTとしてペアプロを導入、TDDを実践

• 人を育て自分の仕事を引き継ぎ

• テスト自動化の準備

• 日常業務を断つ

• 自分の時間を確保

レガシーコード改善自体は楽しい

• フレームワークに入れたときの達成感

• パズルゲームのような楽しさ

• 仕様化テストを書いた後の征圧感

• 過去の作業者の思考に思いを巡らす

• 劇的にコード量が減る爽快感

• コードが綺麗になっていく

• コードが本来の姿を取り戻す

この1年、悩んできたこと

• TDDが良いと分っていても、TDD出来ない

• 自動テストにした方が良いと分っていても、自動化出来ない

• どうやったら、現場で実践できるか?

• 現場特有の問題と組み合わせることで上手く行くこともあった(OJT)

• 自分の状況を利用してみたりした(時短勤務)

今、感じている事

• マネージメントの問題ではないのか? – 時間、人

• 混乱した現場⇒レガシーコードが生まれる?

• 自らのマネージメントする – 自らの強みを知る

• 工場、生産工程、知識

• リファクタリングが好き

– 時間を管理する • 何に時間を取られているのか?

– もっとも重要なことに集中する • 手作業⇒自動化

参考になった本 自分の強みは何か?

時間を管理する

ストレングス・ファインダー

才能とは、無意識に繰り返される思考、感情、行動のパターン

7つの習慣実践例 今抱えている仕事を

全部吐き出す

一日の初めにスケジュール

を立てる

思い込みを解くゲーム

あなたが今解決したいことを思い浮かべてください

Step1 出来ない理由を上げてみてください

(多ければ多いほどいい)

Step2 文章を反転して、出来るに変えてみてください

例)

自信がないから、勉強会が出来ない

自信がないから、勉強会が出来る

自信があるから、勉強会が出来る

P228 ①どの文章に自分の感情が反応しますか?

そこに気づきがあるかもしれない

②無理やりにでも出来る理由を並べると、出来る気がしてくる

今年の目標

• 片付けには2種類ある – 祭りの片付け

• コツ:一気に、短期間に、完璧に片付ける

– 日常片付け

祭りの片付け

受け入れテストの自動化 CI環境の導入

新しい開発環境へ移行

ようやく自分の強みで戦える

ご清聴ありがとうございました