SlideShare a Scribd company logo
1 of 63
Download to read offline
レガシーコードへの取り組み 
事例紹介 
菅原 誠一
自己紹介 
菅原 誠一 
•京都にある精密機器製造会社勤務 
•生産技術 
– 社内工場のソフト開発、保守、運用など 
– 工場からの問い合わせ対応 
•入社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
仕事の流れ 
こんなのしたいのだけど 
変更内容を検討 
プログラム 
社内書類作成(仕様書) 
テスト⇒社内審議 
工場にリリース 
現場責任者
出荷製品の確認ソフト 
このソフトの機能 
•工場のオペレーター用 
•注文情報の参照 
•製品内部情報を取得 
•注文情報と製品内部情報を比較 
•オペレーターに結果を表示 
•確認結果を保存 
製品 
注文情報 
間違いなく 
製品が 
作られていることを 
確認する
新製品でも 
この確認ソフトを使いたい 
従来製品 製品C 
製品A 製品B 
新製品D 
現場責任者
調査結果 
• 変更箇所 
– クラス:FormMain 
– メソッド:CheckGas 
• 変更内容 
– 確認するパラメータ数が従来製品と違う 
• 従来1~4個⇒5個 
• パラメータを持っていない
レガシーコードでTDD 
0. 変更したいクラスをテストで保護 
1. 失敗するテストケースを記述 
2. コンパイル 
3. テストを通過させる 
4. 重複を取り除く 
5. 繰り返す 
ココ 
レガシーコード改善ガイド P104 
TDDのこころ(和田卓人)
まず、テストフレーム内で 
TFormMainの実体化に挑戦 
• クラス:FormMain 
• 2000行 
• メソッド:CheckGas 
• 171行 
• メソッドの機能 
• 製品情報を取得 
– 製品との通信機能 
• 注文情報と内部情報を比較 
• オペレーターに結果を表示 
– GUI操作
格闘2時間 
依存関係激しすぎる・・・ 
コンパイル出来ない 
断念
方針を変える 
• テストフレームに入れる対象を小さくする 
• メソッドオブジェクトの取り出し(P345) 
– 大きなメソッドをクラスとして取り出す 
– 対象行数:2000行⇒171行 
• コンパイル任せ(p331) 
– 変数がない→メンバー変数追加 
– メソッドがない→インターフェースの抽出(p377)
1.5時間後 捕獲成功!
既存機能の保護 
• 仕様化テスト(p200) 
– 製品A、B、Cに対する機能の保護 
製品A 製品B 製品C 
• 偽装オブジェクトの作成(p27) 
– 製品との通信 
– 画面とのインターフェース 
• テストを書く 
– 製品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環境の導入 
新しい開発環境へ移行
ようやく自分の強みで戦える
ご清聴ありがとうございました

More Related Content

What's hot

AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけてAgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけてShuji Morisaki
 
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるかTest Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるかTakuto Wada
 
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編Noriyuki Mizuno
 
テストを分類してみよう!
テストを分類してみよう!テストを分類してみよう!
テストを分類してみよう!Kenji Okumura
 
How to let them in house of quality
How to let them in house of qualityHow to let them in house of quality
How to let them in house of qualityTakahiro Toku
 
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年verソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年verKosuke Fujisawa
 
Sta introduction in_kyoto #devkan
Sta introduction in_kyoto #devkanSta introduction in_kyoto #devkan
Sta introduction in_kyoto #devkankyon mm
 
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04Makoto Nonaka
 
DeNA QA night #2 presentation
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentationYasuharu Nishi
 
ソフトウェアテスト入門
ソフトウェアテスト入門ソフトウェアテスト入門
ソフトウェアテスト入門Preferred Networks
 
Hey It's Not My TDD!
Hey It's Not My TDD!Hey It's Not My TDD!
Hey It's Not My TDD!Yasui Tsutomu
 
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
サーバーフレームワークに潜んでる脆弱性検知ツール紹介サーバーフレームワークに潜んでる脆弱性検知ツール紹介
サーバーフレームワークに潜んでる脆弱性検知ツール紹介gree_tech
 

What's hot (13)

AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけてAgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
 
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるかTest Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
 
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編
 
品質基礎知識
品質基礎知識品質基礎知識
品質基礎知識
 
テストを分類してみよう!
テストを分類してみよう!テストを分類してみよう!
テストを分類してみよう!
 
How to let them in house of quality
How to let them in house of qualityHow to let them in house of quality
How to let them in house of quality
 
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年verソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
 
Sta introduction in_kyoto #devkan
Sta introduction in_kyoto #devkanSta introduction in_kyoto #devkan
Sta introduction in_kyoto #devkan
 
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04
 
DeNA QA night #2 presentation
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentation
 
ソフトウェアテスト入門
ソフトウェアテスト入門ソフトウェアテスト入門
ソフトウェアテスト入門
 
Hey It's Not My TDD!
Hey It's Not My TDD!Hey It's Not My TDD!
Hey It's Not My TDD!
 
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
サーバーフレームワークに潜んでる脆弱性検知ツール紹介サーバーフレームワークに潜んでる脆弱性検知ツール紹介
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
 

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

nseg第5回勉強会
nseg第5回勉強会nseg第5回勉強会
nseg第5回勉強会ko ty
 
企業と勉強会 @nifty エンジニアサポート
企業と勉強会 @nifty エンジニアサポート企業と勉強会 @nifty エンジニアサポート
企業と勉強会 @nifty エンジニアサポートDaichi Morifuji
 
テスト駆動開発入門 - C4K Meetup#2
テスト駆動開発入門 - C4K Meetup#2テスト駆動開発入門 - C4K Meetup#2
テスト駆動開発入門 - C4K Meetup#2Masashi Shibata
 
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~Tomomi Kajita
 
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書Osamu Kawachi
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進めDai FUJIHARA
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進めRakuten Group, Inc.
 
ソフトウェア開発の現場風景
ソフトウェア開発の現場風景ソフトウェア開発の現場風景
ソフトウェア開発の現場風景Koichi ITO
 
レガシーコードでTDD力を高めよう #agilesamurai
レガシーコードでTDD力を高めよう #agilesamuraiレガシーコードでTDD力を高めよう #agilesamurai
レガシーコードでTDD力を高めよう #agilesamuraiYoutarou TAKAHASHI
 
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするためにCEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするためにTakafumi Ikeda
 
KDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フローKDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フローques_staff
 
TDDはじめる前に
TDDはじめる前にTDDはじめる前に
TDDはじめる前にYasui Tsutomu
 
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カット「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カットRakuten Group, Inc.
 
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-nishio
 
「Agileごっこ」で終わらせないために(仮)
「Agileごっこ」で終わらせないために(仮) 「Agileごっこ」で終わらせないために(仮)
「Agileごっこ」で終わらせないために(仮) Taku Yajima
 
cedec 2015 techinical artist bootcamp vol.1
cedec 2015 techinical artist bootcamp vol.1cedec 2015 techinical artist bootcamp vol.1
cedec 2015 techinical artist bootcamp vol.1DigitalFrontier
 
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていくRyo Mitoma
 
テストコードの DRY と DAMP
テストコードの DRY と DAMPテストコードの DRY と DAMP
テストコードの DRY と DAMPYusuke Kagata
 
5年しかもたない最高のシステムとの向き合い方
5年しかもたない最高のシステムとの向き合い方5年しかもたない最高のシステムとの向き合い方
5年しかもたない最高のシステムとの向き合い方Jumpei iwamura
 

Similar to Dev love関西 レガシーコードへの取り組み 20140325 (20)

nseg第5回勉強会
nseg第5回勉強会nseg第5回勉強会
nseg第5回勉強会
 
私とインクス
私とインクス私とインクス
私とインクス
 
企業と勉強会 @nifty エンジニアサポート
企業と勉強会 @nifty エンジニアサポート企業と勉強会 @nifty エンジニアサポート
企業と勉強会 @nifty エンジニアサポート
 
テスト駆動開発入門 - C4K Meetup#2
テスト駆動開発入門 - C4K Meetup#2テスト駆動開発入門 - C4K Meetup#2
テスト駆動開発入門 - C4K Meetup#2
 
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
 
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
 
ソフトウェア開発の現場風景
ソフトウェア開発の現場風景ソフトウェア開発の現場風景
ソフトウェア開発の現場風景
 
レガシーコードでTDD力を高めよう #agilesamurai
レガシーコードでTDD力を高めよう #agilesamuraiレガシーコードでTDD力を高めよう #agilesamurai
レガシーコードでTDD力を高めよう #agilesamurai
 
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするためにCEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするために
 
KDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フローKDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フロー
 
TDDはじめる前に
TDDはじめる前にTDDはじめる前に
TDDはじめる前に
 
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カット「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
 
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-
 
「Agileごっこ」で終わらせないために(仮)
「Agileごっこ」で終わらせないために(仮) 「Agileごっこ」で終わらせないために(仮)
「Agileごっこ」で終わらせないために(仮)
 
cedec 2015 techinical artist bootcamp vol.1
cedec 2015 techinical artist bootcamp vol.1cedec 2015 techinical artist bootcamp vol.1
cedec 2015 techinical artist bootcamp vol.1
 
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
 
テストコードの DRY と DAMP
テストコードの DRY と DAMPテストコードの DRY と DAMP
テストコードの DRY と DAMP
 
5年しかもたない最高のシステムとの向き合い方
5年しかもたない最高のシステムとの向き合い方5年しかもたない最高のシステムとの向き合い方
5年しかもたない最高のシステムとの向き合い方
 

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