Post on 24-May-2015
description
青年海外協力隊
• 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%)、原始宗教
• 気候:温暖(沖縄に近い)
授業の風景 • 授業
– プログラミングI、プログラミングII • JAVA基礎、応用
– オブジェクト指向プログラミング • UML
– WebプログラミングI、 WebプログラミングII • PHP、MySQL基礎、応用
• 学校の機器のメンテナンス – PCの修理、ウィルス除去
本日の内容
• 私の現場のレガシーコードの紹介
• TDDの導入(2012/10~)
– テストのないコード増加に歯止め
– レガシーコードでのTDD作業
• 受け入れテストの自動化(2014/2~)
– 大きくテストで保護
• この一年の振り返り
• 今年したいこと
レガシーコードとは?
テストのないコードは悪いコードである。どれだけうまく書かれているかは関係ない。
どれだけ美しいか、オブジェクト指向か、きちんとカプセル化されているかは関係ない。
テストがあれば、検証しながらコードの動きを素早く変更することが出来る。
テストがなければ、コードが良くなっているのか悪くなっているのか本当に分からない
(レガシーコード改善ガイド はじめにより)
『単にテストのないコード』
『何年も前に誰かが作り、
内容が複雑で何をしているのかよく分からず、
まともな仕様書もない』 http://codezine.jp/article/detail/4103
現場のレガシーコード
• 言語
– C++
• クラス数
– 1446個
• コード
– 642131行
• 生産技術のノウハウの塊
• 生まれから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
1. 失敗するテストケースを記述
2. コンパイル
3. テストを通過させる
4. 重複を取り除く
5. 繰り返す
ココ
レガシーコード改善ガイド P104
0. 変更したいクラスをテストで保護
TDDのこころ(和田卓人)
まず、テストフレーム内で TFormMainの実体化に挑戦
• クラス:FormMain
• 2000行
• メソッド:CheckGas • 171行
• メソッドの機能 • 製品情報を取得
– 製品との通信機能
• 注文情報と内部情報を比較
• オペレーターに結果を表示 – GUI操作
方針を変える
• テストフレームに入れる対象を小さくする
• メソッドオブジェクトの取り出し(P345)
– 大きなメソッドをクラスとして取り出す
– 対象行数:2000行⇒171行
• コンパイル任せ(p331)
– 変数がない→メンバー変数追加
– メソッドがない→インターフェースの抽出(p377)
既存機能の保護
• 仕様化テスト(p200) – 製品A、B、Cに対する機能の保護
• 偽装オブジェクトの作成(p27) – 製品との通信 – 画面とのインターフェース
• テストを書く – 製品A、B、Cに対して仕様化テスト
製品A 製品B 製品C
TDDで機能追加
• 追加したい機能のテスト書く
• テストが失敗することを確認
• テストを通過
• リファクタリング
• 『メソッドオブジェクトの取り出し』で取り出したクラスを、元のクラス(FormMain)に戻す
• 作業時間3時間
ふりかえり
• TDDで変更 – 実体化失敗 2時間 – メソッドオブジェクトの抽出 1.5時間 – 仕様化テスト 5時間 – 機能追加 3時間
• 合計工数 11.5時間×2人 =23時間
• 従来のやり方
– 変更3時間くらい(推測)
純粋にコーディングの 工数だけを見ると
7倍以上
23時間の工数は妥当か? • 従来のやり方で、誰がしても3時間? • プログラム以外の工数11時間は新しい人に任せることが出来た • 教育には結構時間がかかる • 過去の負債はいつかえすの?
調査
プログラミング
データ更新
テスト
書類作成
リリース
従来のやりかたを 続けている限り
永遠にレガシーコードはなくならい
作業の割合
レガシーコードのジレンマ
コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある
• 対策 ペアプロ
レガシーコード改善ガイド P19
レガシーコード改善ガイド P333
もっと大きな網が欲しい
• 思い切ったコードの変更をしないとテストフレームに入らないコード
• 手動テストの負荷がどんどん増えている
• 手動テストのミスが多くなっている
受け入れテストの自動化 がしたい!
GUIのテストは 一般的に難しいと言われているが
• 工場内アプリの環境はかなり特殊 – 操作画面は変わらない – 操作画面はシンプル
• 自動化出来ない要因
– 工場でないと接続できないハードウェア – 計測器の出力が必要 – 工夫すれば回避可能
• コストに見合わない?
– 毎回、同じテストをしている – 手作業によるミスを頻発
• 一番知っているのは自分
自分の時間を確保 • 人を育てる
– OJT:ペアプロ、TDD • 一応、筋は通す
– 上司にお願い ⇒OK – 社内の報告会でテスト自動化による工数削減を説明 ⇒なんでやらないのかと言われる
• 日常の業務は次から次へとやってくる
日常業務を断つ
GUI自動化ツール • Codeer.Friendly(コーディア・フレンドリー)
– 株式会社Codeer(コーディア) • http://www.codeer.co.jp/home
• 特徴
– プロダクトプロセスを、「プログラムレベル」で、テストプロセスから操作することができます
– 小規模な結合テスト~GUIテストまで対応します
• 選んだ理由 – C#でプログラム出来る
– 工場内でしか使えない計測器の疑似入力を内部メソッドを呼ぶことで実現したい
この一年間の振り返り
• TDD技術の取得(TDDBC、読書会)
• OJTとしてペアプロを導入、TDDを実践
• 人を育て自分の仕事を引き継ぎ
• テスト自動化の準備
• 日常業務を断つ
• 自分の時間を確保
レガシーコード改善自体は楽しい
• フレームワークに入れたときの達成感
• パズルゲームのような楽しさ
• 仕様化テストを書いた後の征圧感
• 過去の作業者の思考に思いを巡らす
• 劇的にコード量が減る爽快感
• コードが綺麗になっていく
• コードが本来の姿を取り戻す
この1年、悩んできたこと
• TDDが良いと分っていても、TDD出来ない
• 自動テストにした方が良いと分っていても、自動化出来ない
• どうやったら、現場で実践できるか?
• 現場特有の問題と組み合わせることで上手く行くこともあった(OJT)
• 自分の状況を利用してみたりした(時短勤務)
今、感じている事
• マネージメントの問題ではないのか? – 時間、人
• 混乱した現場⇒レガシーコードが生まれる?
• 自らのマネージメントする – 自らの強みを知る
• 工場、生産工程、知識
• リファクタリングが好き
– 時間を管理する • 何に時間を取られているのか?
– もっとも重要なことに集中する • 手作業⇒自動化
参考になった本 自分の強みは何か?
時間を管理する
ストレングス・ファインダー
才能とは、無意識に繰り返される思考、感情、行動のパターン
7つの習慣実践例 今抱えている仕事を
全部吐き出す
一日の初めにスケジュール
を立てる
思い込みを解くゲーム
あなたが今解決したいことを思い浮かべてください
Step1 出来ない理由を上げてみてください
(多ければ多いほどいい)
Step2 文章を反転して、出来るに変えてみてください
例)
自信がないから、勉強会が出来ない
↓
自信がないから、勉強会が出来る
自信があるから、勉強会が出来る
P228 ①どの文章に自分の感情が反応しますか?
そこに気づきがあるかもしれない
②無理やりにでも出来る理由を並べると、出来る気がしてくる