SlideShare a Scribd company logo
よしおかひろたか
      テスト勉強会


楽天株式会社 開発部 アーキテクトGよしおかひろたか |
2010年3月12日                     1
よしおか   本日のメッセージ


開発者の皆さん、
テストを書こう
テストを書く=テストコード+入力データ+期待する出力デー
   タ
Excelでテストケースを作ることではない。




                               2
アジェンダ

• 大規模ソフトウェア開発におけるディ
  リービルド&リグレッションテスト




                      3
自己紹介

• 開発部、ACT課アーキテクトG、技術理事
  よしおかひろたか
• 2009年8月入社
• カーネル読書会の主宰者、DEBUG HACKS共著
  ISBN978-4-87311-404-0
• twitter @hyoshiok http://
  d.hatena.ne.jp/hyoshiok




                                 4
わたしの経験から

• 大規模ソフトウェア開発の現場の経験をお
  話する。
 – ソフトウェア製品開発は受託開発とは相当異な
   る。
• 事例:
 –   Oracle8の開発現場
 –   DEC Rdbの日本語化、国際化
 –   日本語COBOL
 –   Samba3.0国際化対応(オープンソースの場合)



                                 5
Oracleの場合

•   開発環境
•   開発プロセス
•   プログラマの日常
•   リズム
•   チェックアウト、チェックイン
•   ディリービルド
•   リグレッションテスト
•   学んだこと


                      6
Oracle 8の場合

• わたしが参加した時期、1995年~2000年
• Oracle8/8iあたりのころ
• 開発環境:Sun Workstation、SunOSから
  Solaris
• Clearcaseベースの開発環境。
  – ファイルの仮想化。一人で複数のブランチを同
    時に持てる。
    • 例えば、Oracle 7.3用、Oracle 8用、Oracle 8.1用。バグ
      修正、機能ごと、ちょっとした確認用などなど
    • check-outしたものはcheck-inするまで他の人には見え
      ない。

                                                 7
開発プロセス(Oracleの場合)

•   要求仕様作り(開発者)
    –   外部API、UIなどを決定する。
         •   例:SQLのシンタックス、セマンティックスを定義する。
    –   リファレンスマニュアルのベースになる。
•   設計(開発者)
    –   APIなどを決定したら、設計&実装になる。
•   実装(開発者)
    –   コードを書く、テストを書く、テストをする
•   ディリービルド&リグレッションテスト(自動)
    –   チェックインされた最新のコードをスクラッチからビルドして、リグレッションテ
        ストを実行。
         •   チェックインしたコードの概要と、テスト結果の概要が日々担当者にメールで送られる
         •   常に動くコードが毎日ある。
•   安定化プロセス
    –   フィーチャーフリーズ(機能追加を凍結する)
    –   コードフリーズ(重大なバグフィックス以外のチェックインを認めない)




                                                       8
ソフトウェア製品開発のプログ
        ラマ

• 設計者が実装者でテストも書く
• 一つの機能については、すべて知って
  いる。
• コーダーという人がいるわけではない
  。




                      9
プログラマの一日

•   朝会社に来る。
•   コーヒーでも飲みながら、メールをチェックする。
    –   担当のテストを確認する。
        •   自分が昨日チェックインしたコードがリグレッションテストを壊していないか。
        •   他の人のチェックインが、担当テストを壊していないか。
        •   壊れている場合は、調査する。あるいは調査を依頼する。
•   仕掛の作業を行う。
    –   コードを書いたり、テストを流したり、あれやこれや。
    –   全テストを流すと時間がかかるので、サブセットを流す
    –   コードが安定したら当該ブランチの最新版にマージする
•   自分の環境で動作確認ができたら、
    –   同僚にレビュー依頼をして、コメントをもらう。特に問題がなさそうの場合、リリ
        ースマネージャーにチェックインの許可をもらう。
•   許可が出たら、チェックインする。
    –   次の日はどきどきしながらリグレッションテストの結果を見る
•   休暇の前に確認しないでチェックインをするな、という不文律
    – http://d.hatena.ne.jp/hyoshiok/20040516#p1




                                                   10
リズム

• チェックアウトして
• コードをいじって、テストを書いて、
• テストを実行して、OKになるまで繰
  り返して、
• 同僚にレビューしてもらって、
• リリースマネージャに許可をもらって
  、
• チェックイン

                      11
チェックアウト、チェックイン

• 複数のブランチを同時にいじっている
• バージョンがいくつか
• それぞれについて、バグフィックス、
  機能変更、機能追加、機能ごとに別々
  のブランチを切っておく。
• 最新のバージョンでバグフィックスし
  たものを昔のバージョンに適用するこ
  ともある。(バックポート)


                      12
ディリービルド

• 毎日大量のチェックインがある。数十
  ~
• 最新のソースからビルドする。
 – コンパイルエラーが出るチェックインは
   無条件にロールバックされる。
 – 複数のビルドマシンで分散ビルド
• 安定性に差こそあれ常に動くものがあ
  る。
 – Oracle8の最初のビルドは前バージョン
   (Oracle 7.3)と同一。ここから始まる。

                              13
リグレッションテスト

• ディリービルドされた最新の実行イメージ
  でリグレッションテスト(数千)を実行す
  る
 – 10数台(?)のサーバーマシンで何時間もかか
   る。
 – テストコード、入力データを与えて、期待する
   出力と実際の出力の差分を見る
 – diff(差分)が出たらそれを目視確認する。期待
   する結果なのか、いなか。
 – 新機能追加、バグフィックスの場合は対応する
   テストの追加、修正などを行う。
 – リグレッションテストがあるので、既存の機能
   の予期しない影響がすぐにわかる。リグレッシ
   ョンの発見。

                              14
安定化プロセス

• あるクライテリアで、安定化プロセスに入
  る。
 – 新機能の追加を凍結する(feature freeze)期間に
   入る
 – バグ修正だけを行う
 – リグレッションテストのdiffの数を減少させる
 – テストの追加、実行だけをやって、製品の安定
   化を図る。
 – あるクライテリアで、重大なバグ修正以外は一
   切変更を認めない(code freeze)期間に入る。
 – バグ(不具合)はリリースノート等に記載し出
   荷する

                                    15
学んだこと

• ディリービルドによって、常に動作が確認されてい
  るものがある。
  – どの機能が実装されていて、どの機能が実装されていない
    かが一目でわかる
  – 実装すべき機能のプライオリティが変更になったとしても
    、すぐに対処可能
  – スケジュールが遅延した場合、どの機能を落とすかの判断
    が容易に可能。(どれが動いているかいないかを把握でき
    ているので)
• 大規模ソフトウェア開発において俊敏性を高めるベ
  ストプラクティスで、ソフトウェア製品開発では広
  く利用されている。(例:マイクロソフトのOS開
  発など)
• 闘うプログラマー
  http://books.rakuten.co.jp/rb/6130084/

                                           16
DEC Rdbの日本語化、国際化

• ソフトウェアの日本語化プロセス
• ビルド環境って
• インターネット以前のソフトウェア開
  発
• 学んだこと




                      17
DEC Rdbの場合

• ソフトウェアの日本語化プロセス
 – 米国本社で開発されたソフトウェアを日本で日
   本語化した。(別のバイナリーになる)
  • 1980年代後半のころ
  • 参加人員:日本側開発者3名~。US側は100名前後
  • 開発環境の入手
    – ソースコードの入手
    – ビルドスクリプト
    – テスト環境
  • 開発環境構築
    – VAX/VMS、OSの違い、コンパイラの違い、その他ツールの違
      いなどなどで一筋縄では行かない場合も
  • 実際の開発
    – ビルド&リグレッションテスト




                                        18
ビルド環境

• 開発環境を日米で完璧に一致させることは
  難しい
 – もちろん仮想化環境などはない。ツール、コン
   パイラ、OSのバージョン
• 社内ネットワークはあったが回線が細い
 – 100MBをコピーするのに足掛け3日とか
• リグレッションテストの結果を確認するの
  が難しい。(開発環境が微妙に異なるので
  )
 – 安定化させるのに2~3ヶ月かかることも。

                           19
インターネット以前のソフトウ
          ェア開発
• 大規模分散開発だったのだけど、
  – 社内ネットワークの帯域は細かった
  – コミュニケーションは、メール、電子掲示板(VAX
    Notes)
• 最終的には、本社に乗り込んで、ソースコードをマ
  ージした(1990年ごろ)
• DECはOS(VMS)、ハードウェア(VAX)、ミドルウ
  ェア(Rdb)、コンパイラ、ツール、その他すべて内
  製品。垂直統合型企業
• SQA (Software Quality Assurance)という部隊があっ
  た。
  – OS/HW/ミドル:各レイヤーの互換性をリグレッションテ
    ストで確認


                                             20
学んだこと

• 米国本社のエンジニアと一緒に働いた
• すごいエンジニアがいっぱいいた
• ソフトウェア国際化のあるべき姿につ
  いてとことん議論できた
• 大規模広域分散ソフトウェア開発のイ
  メージが持てた




                      21
日本語COBOLの場合

• 非力なマシンでのソフトウェア開発
• コード管理システム、モジュール管理
  システム、テスト管理システムなどの
  お話
• バグ管理
• エンジニアのイロハを教えてもらった
• 学んだこと


                      22
プロジェクト概要

• 日本語COBOLの開発
 –   1984年~
 –   3人(自分は新卒プログラマ)
 –   開発環境、VAX/VMS
 –   言語:BLISS、SCAN(独自の言語)
• コード管理システム、モジュール管理
  システム、コンパイラ、テスト管理シ
  ステム、バグ管理システム、すべて自
  社製

                            23
• 夜中の0時に、ビルドのバッチが動き出し、
  その後テストを実行する。
 – チェックインしたファイルのdiffをメールするよ
   うにした。
 – 見よう見まねで、makeファイルを書いた。
 – テストスクリプトもテスト管理システムを利用
   して書いた。テスト結果もメールした。
• チェックインの数、発見したバグの数、修
  正したバグの数などをグラフにすると、週
  単位での進捗が見えた。



                              24
バグ管理

• テストプログラムは、自分以外が実装
  した分について書いた。(他人のコー
  ドをテストする)
• 発見したすべてのバグはバグデータベ
  ース(自作)に登録した。
 – 110件くらいバグを発見したと思う。
 – バグの分析などもした。3割くらいが未実
   装。


                         25
エンジニアのイロハを教えても
           らった

•   マニュアルを読むこと
•   テストを書くこと
•   デバッグの仕方
•   質問の仕方




                      26
学んだこと

•   社内にはすごい人がいっぱいいる
•   自分もそうなりたい
•   ソフトウェア開発プロセスのイロハ
•   大規模分散開発のイメージ(未来像)
•   ソフトウェア国際化のイメージ(未来
    像)



                        27
Samba3.0国際化対応の場合

•   オープンソースとコミュニティの対応
•   新参者がコミュニティに入るには
•   プロジェクトの流れ
•   オープンソースの都市伝説
•   プログラマの日常
•   リズム
•   学んだこと


                         28
Samba3.0国際化

• プロジェクト概要
 – Samba2.xは日本人コミュニティが開発した日本
   語パッチがあったが、Samba3.0になって、内部
   コードがUnicodeになったため当該パッチが利用
   できなくなりShiftJIS関連の問題が発生した。
 – Unicode対応、テストの追加など
 – 2003年ごろ
 – http://www.miraclelinux.com/technet/samba30/index.html
 – http://d.hatena.ne.jp/hyoshiok/20041022




                                                      29
オープンソースとコミュニティ

• 高い技術力とdisciplineを持ったハッカーによ
  って構成されている
 – 企業の開発者は企業の利益拡大
 – 企業の開発者とコミュニティのハッカーの利害
   が一致するとは限らない。しばしば相反する。
• パッチを送ったからといって受け入れられ
  るとは限らない。
 – 技術的な問題というより、しばしばコミュニケ
   ーションの問題だったりする



                               30
新参者がコミュニティに受け入れら
      れるには
• 何の実績もない人が受け入れられるには
 – 技術の問題ではなくコミュニケーションの問題だと認識し
   た
   • Samba-jp(日本のコミュニティ)とSambaのコミュニティの
     関係。両方に受け入れられる必要がある。
 – テストをどんどん作って、発見した問題をバグデータベー
   スにどんどん登録した。チームのメンバーは個人名で登録
   。
 – ついでにパッチなども投稿した。個人名で投稿。
 – 直接会って話したり、メール、チャット、電話会議などで
   、プロジェクトの紹介などを行った。
 – コミュニティにデビューするには、自分たちの技術力を理
   解してもらう必要がある。バグフィックスは最初の一歩。
 – 大きなパッチをいきなり送るのではなく、小さいバグフィ
   ックスの積み重ねで、徐々に信頼を得ていく。

                                         31
プロジェクトの流れ

• ディリービルド、リグレッションテストの開発環境を準備し
  た。
• Sambaのテストフレームワークを利用し
 –   テストケースの作成
 –   テストコードの作成
 –   テストの実施
 –   不具合をbugzillaに登録
 –   修正パッチを投稿
• 機能追加、修正などのパッチを適宜投稿。本家にマージして
  もらう。
• 英語のホームページ、ドキュメントなども用意した
• フェースツーフェースの会議、メール、チャット、電話など
  様々な方法をとった




                                32
オープンソースの都市伝説

• ハッカーは無法者?
 – 極めて高い技術力とdiscipline(規律)を
   持つ
 – コミュニティの価値を大切にする
 – プロフェッショナルである




                              33
プログラマの日常

•   やることリストの確認
•   Bugzillaのチェック
•   テストの追加
•   パッチの作成
    – リグレッションが起こっていないことを
      確認
    – 新機能が実装されていることを確認
• コミュニティへ投稿
    – メーリングリスト、電話、チャット、な
      どなど
                           34
リズム

• 作成したテスト数が見える
• バグの数が既知
 – 最初にテストがあるので、そのテストで
   発見した数が初期値になる
 – Samba3.0は今ここにあるが国際化の機能
   がない。(バグの数=実装すべき機能)
• バグの数を減らしていくのがリズム



                            35
学んだこと

• OSSもテストファーストできた
• 何をやりたいかをテストで表現した
  WHAT
• テストを作ることによってオリジナル
  製品の挙動を深く理解した
• プロジェクトマネージャーとして、プ
  ロジェクトの進捗が、テストの進捗、
  残バグ数によって見える化されている
  ので、安心。

                      36
ちょっとした思い

• プロフェッショナルって
• 変化を許容すること
• プログラマに必要な3つのチカラ




                    37
プロフェッショナルについて

• ソフトウェアは人が作る
 – 自分がプロフェッショナルになるしかな
   い…
 – アスリートが毎日トレーニングしている
   ようにわれわれはトレーニングをしてい
   るだろうか




                        38
変化を許容することについて

• 環境は変化する
• 自分は変化しているだろうか
• 成長しているだろうか




                   39
プログラマに必要な3つのチカ
         ラ

• ソースコードリーディング
• テスト
• デバッグ



• ワークショップや勉強会を開催してい
  きたい~~~


                      40
経験則

• テストを書かない
  プロフェッショナルはいない
  (プログラマ的な意味で)
• テストのないコードは
  レガシーコードだ。
• 読書会しましょう~

レガシーコード改善ガイド
  保守開発のためのリファクタリング、翔
  泳社
http://books.rakuten.co.jp/rb/6121689/
                                         41
• 公理1:すべてのプログラムは
  テストをしなければいけない。
• では、どうテストをするか
 – A:人がやる
 – B:テストコードを書いて、それを実行す
   る
 – 正解:B
 – 証明:自明。


                         42
テストを作ると

• システムの振る舞い(WHAT)を
  記したことになる
 – テストを作ることによって、システムの
   深い理解を得られる
 – 安心感を得られる(心の平静を保てる)




                        43
テストがあると

• 変更の影響が即座にわかる
 – 影響範囲がわからなくて、
   塩漬けではなく、
   どんどん積極的に変更できる
   >変更容易性、アジリティ向上
 – 安心である。(心の平静が保てる)




                      44
テストがあると

• 機能を確実に実装したことを
  確認できる。
 – 手作業による確認は、もれやミスが発生
   する。コストが高いし、なにより楽しく
   ない。
 – 機械が実行してくれるので、楽である。
 – 安心である。 (心の平静が保てる)




                        45
テストがあると

• 変更容易性があがり、
  運用コストが下がる
 – OSやHWなどシステムを変更したときも
   、その影響がすぐにわかる
 – 安心である。 (心の平静が保てる)




                         46
レガシーコード改善ガイド読書
          会
• レガシーコード改善ガイドを読む
• 世話役:アーキテクトGよしおかひろたか
• 日程:木曜日、19時~20時30分ころ
• やり方:分担で、説明して、参加者による
  議論
• ペース:一回あたり60ページくらい進みた
  い。7回程度で全部を網羅したい
• レガシーコードを改善して楽をしよう

              ご参加
             おまちしてます
                         47
開発者の皆さん、
テストを書こう
テストを書いてプロフェッショナルにな
 ろう
世界へ


                     48
49

More Related Content

What's hot (18)

Jenkinsを使った初めての継続的インテグレーション by dcubeio, has 38 slides with 4265 views.
Jenkinsを使った初めての継続的インテグレーションJenkinsを使った初めての継続的インテグレーション
Jenkinsを使った初めての継続的インテグレーション
dcubeio
38 slides•4.3K views
バイオインフォマティクスのための開発基礎知識 by 丈 宮本, has 38 slides with 1911 views.
バイオインフォマティクスのための開発基礎知識バイオインフォマティクスのための開発基礎知識
バイオインフォマティクスのための開発基礎知識
丈 宮本
38 slides•1.9K views
Jenkins+Play!で気軽にCI by Takafumi Ikeda, has 65 slides with 6780 views.
Jenkins+Play!で気軽にCIJenkins+Play!で気軽にCI
Jenkins+Play!で気軽にCI
Takafumi Ikeda
65 slides•6.8K views
【19-B-4】 そろそろ俺たちの本気を見せてやるぜ!~ マイクロソフトとOSSごった煮 DevOps 衝撃デモシリーズ! by Developers Summit, has 29 slides with 1155 views.
【19-B-4】 そろそろ俺たちの本気を見せてやるぜ!~ マイクロソフトとOSSごった煮 DevOps 衝撃デモシリーズ!【19-B-4】 そろそろ俺たちの本気を見せてやるぜ!~ マイクロソフトとOSSごった煮 DevOps 衝撃デモシリーズ!
【19-B-4】 そろそろ俺たちの本気を見せてやるぜ!~ マイクロソフトとOSSごった煮 DevOps 衝撃デモシリーズ!
Developers Summit
29 slides•1.2K views
提案:Qaも実装に踏み込んでみよう by Kosuke Fujisawa, has 21 slides with 830 views.
提案:Qaも実装に踏み込んでみよう提案:Qaも実装に踏み込んでみよう
提案:Qaも実装に踏み込んでみよう
Kosuke Fujisawa
21 slides•830 views
CodeZineAcademy TDD実践講座PR資料 by Yasui Tsutomu, has 41 slides with 2338 views.
CodeZineAcademy TDD実践講座PR資料CodeZineAcademy TDD実践講座PR資料
CodeZineAcademy TDD実践講座PR資料
Yasui Tsutomu
41 slides•2.3K views
デプロイメントパイプラインって何? by ke-m kamekoopa, has 26 slides with 11802 views.
デプロイメントパイプラインって何?デプロイメントパイプラインって何?
デプロイメントパイプラインって何?
ke-m kamekoopa
26 slides•11.8K views
Dockerとdev ops by Hiroshi Maekawa, has 61 slides with 598 views.
Dockerとdev opsDockerとdev ops
Dockerとdev ops
Hiroshi Maekawa
61 slides•598 views
Jenkinsを使った初めての継続的インテグレーション by dcubeio, has 38 slides with 4265 views.
Jenkinsを使った初めての継続的インテグレーションJenkinsを使った初めての継続的インテグレーション
Jenkinsを使った初めての継続的インテグレーション
dcubeio
38 slides•4.3K views
バイオインフォマティクスのための開発基礎知識 by 丈 宮本, has 38 slides with 1911 views.
バイオインフォマティクスのための開発基礎知識バイオインフォマティクスのための開発基礎知識
バイオインフォマティクスのための開発基礎知識
丈 宮本
38 slides•1.9K views
【19-B-4】 そろそろ俺たちの本気を見せてやるぜ!~ マイクロソフトとOSSごった煮 DevOps 衝撃デモシリーズ! by Developers Summit, has 29 slides with 1155 views.
【19-B-4】 そろそろ俺たちの本気を見せてやるぜ!~ マイクロソフトとOSSごった煮 DevOps 衝撃デモシリーズ!【19-B-4】 そろそろ俺たちの本気を見せてやるぜ!~ マイクロソフトとOSSごった煮 DevOps 衝撃デモシリーズ!
【19-B-4】 そろそろ俺たちの本気を見せてやるぜ!~ マイクロソフトとOSSごった煮 DevOps 衝撃デモシリーズ!
Developers Summit
29 slides•1.2K views
提案:Qaも実装に踏み込んでみよう by Kosuke Fujisawa, has 21 slides with 830 views.
提案:Qaも実装に踏み込んでみよう提案:Qaも実装に踏み込んでみよう
提案:Qaも実装に踏み込んでみよう
Kosuke Fujisawa
21 slides•830 views
CodeZineAcademy TDD実践講座PR資料 by Yasui Tsutomu, has 41 slides with 2338 views.
CodeZineAcademy TDD実践講座PR資料CodeZineAcademy TDD実践講座PR資料
CodeZineAcademy TDD実践講座PR資料
Yasui Tsutomu
41 slides•2.3K views
デプロイメントパイプラインって何? by ke-m kamekoopa, has 26 slides with 11802 views.
デプロイメントパイプラインって何?デプロイメントパイプラインって何?
デプロイメントパイプラインって何?
ke-m kamekoopa
26 slides•11.8K views

Viewers also liked (15)

DevLOVE LT: Do you know axes of software testing? by Toshiyuki Kawanishi, has 44 slides with 1404 views.
DevLOVE LT: Do you know axes of software testing?DevLOVE LT: Do you know axes of software testing?
DevLOVE LT: Do you know axes of software testing?
Toshiyuki Kawanishi
44 slides•1.4K views
探索的テストから考える現場の工夫(Slideshare) by Masao Tsuzuki, has 34 slides with 3216 views.
探索的テストから考える現場の工夫(Slideshare)探索的テストから考える現場の工夫(Slideshare)
探索的テストから考える現場の工夫(Slideshare)
Masao Tsuzuki
34 slides•3.2K views
探索的テストを探索する by Masao Tsuzuki, has 30 slides with 7448 views.
探索的テストを探索する探索的テストを探索する
探索的テストを探索する
Masao Tsuzuki
30 slides•7.4K views
Agile Software Development advanced course (PBL) at AIIT, 2015 by Hiro Yoshioka, has 22 slides with 7588 views.
Agile Software Development advanced course (PBL) at AIIT, 2015Agile Software Development advanced course (PBL) at AIIT, 2015
Agile Software Development advanced course (PBL) at AIIT, 2015
Hiro Yoshioka
22 slides•7.6K views
記事タイトルづくりで学ぶオモシロイ企画のつくり方(ワークショップ) by Nobuhiro Kawaharasaki, has 30 slides with 107525 views.
記事タイトルづくりで学ぶオモシロイ企画のつくり方(ワークショップ)記事タイトルづくりで学ぶオモシロイ企画のつくり方(ワークショップ)
記事タイトルづくりで学ぶオモシロイ企画のつくり方(ワークショップ)
Nobuhiro Kawaharasaki
30 slides•107.5K views
プレゼン初心者にありがちなアンチパターン by 真俊 横田, has 27 slides with 300072 views.
プレゼン初心者にありがちなアンチパターンプレゼン初心者にありがちなアンチパターン
プレゼン初心者にありがちなアンチパターン
真俊 横田
27 slides•300.1K views
探索的テスト入門 by H Iseri, has 40 slides with 32245 views.
探索的テスト入門探索的テスト入門
探索的テスト入門
H Iseri
40 slides•32.2K views
概説 テスト分析 by 崇 山﨑, has 51 slides with 32062 views.
概説 テスト分析概説 テスト分析
概説 テスト分析
崇 山﨑
51 slides•32.1K views
探索的テストから考える現場の工夫(Slideshare) by Masao Tsuzuki, has 34 slides with 3216 views.
探索的テストから考える現場の工夫(Slideshare)探索的テストから考える現場の工夫(Slideshare)
探索的テストから考える現場の工夫(Slideshare)
Masao Tsuzuki
34 slides•3.2K views
探索的テストを探索する by Masao Tsuzuki, has 30 slides with 7448 views.
探索的テストを探索する探索的テストを探索する
探索的テストを探索する
Masao Tsuzuki
30 slides•7.4K views
Agile Software Development advanced course (PBL) at AIIT, 2015 by Hiro Yoshioka, has 22 slides with 7588 views.
Agile Software Development advanced course (PBL) at AIIT, 2015Agile Software Development advanced course (PBL) at AIIT, 2015
Agile Software Development advanced course (PBL) at AIIT, 2015
Hiro Yoshioka
22 slides•7.6K views
記事タイトルづくりで学ぶオモシロイ企画のつくり方(ワークショップ) by Nobuhiro Kawaharasaki, has 30 slides with 107525 views.
記事タイトルづくりで学ぶオモシロイ企画のつくり方(ワークショップ)記事タイトルづくりで学ぶオモシロイ企画のつくり方(ワークショップ)
記事タイトルづくりで学ぶオモシロイ企画のつくり方(ワークショップ)
Nobuhiro Kawaharasaki
30 slides•107.5K views
プレゼン初心者にありがちなアンチパターン by 真俊 横田, has 27 slides with 300072 views.
プレゼン初心者にありがちなアンチパターンプレゼン初心者にありがちなアンチパターン
プレゼン初心者にありがちなアンチパターン
真俊 横田
27 slides•300.1K views
探索的テスト入門 by H Iseri, has 40 slides with 32245 views.
探索的テスト入門探索的テスト入門
探索的テスト入門
H Iseri
40 slides•32.2K views

Similar to テスト勉強会よしおか100311 1 (20)

大規模ソフトウェア開発とテストの経験について by Rakuten Group, Inc., has 48 slides with 4883 views.
大規模ソフトウェア開発とテストの経験について大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
Rakuten Group, Inc.
48 slides•4.9K views
Bringing Continuous Agile to Japan by Andy Singleton, has 111 slides with 312 views.
Bringing Continuous Agile to JapanBringing Continuous Agile to Japan
Bringing Continuous Agile to Japan
Andy Singleton
111 slides•312 views
作る人から作りながら運用する人になっていく by Ryo Mitoma, has 56 slides with 1064 views.
作る人から作りながら運用する人になっていく作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
Ryo Mitoma
56 slides•1.1K views
Gamedevenvstudy1 by Takashi Kokawa, has 179 slides with 1489 views.
Gamedevenvstudy1Gamedevenvstudy1
Gamedevenvstudy1
Takashi Kokawa
179 slides•1.5K views
継続的インテグレーション3分クッキング by Takayuki Kondou, has 28 slides with 5717 views.
継続的インテグレーション3分クッキング継続的インテグレーション3分クッキング
継続的インテグレーション3分クッキング
Takayuki Kondou
28 slides•5.7K views
Firefoxの開発プロセス by Makoto Kato, has 51 slides with 1192 views.
Firefoxの開発プロセスFirefoxの開発プロセス
Firefoxの開発プロセス
Makoto Kato
51 slides•1.2K views
博士論文公聴会 by Makoto SAKAI, has 43 slides with 4012 views.
博士論文公聴会博士論文公聴会
博士論文公聴会
Makoto SAKAI
43 slides•4K views
継続的デリバリー読書会資料 #1 by Yusuke HIDESHIMA, has 50 slides with 1695 views.
継続的デリバリー読書会資料 #1継続的デリバリー読書会資料 #1
継続的デリバリー読書会資料 #1
Yusuke HIDESHIMA
50 slides•1.7K views
大規模ソフトウェア開発とテストの経験について by Rakuten Group, Inc., has 48 slides with 4883 views.
大規模ソフトウェア開発とテストの経験について大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
Rakuten Group, Inc.
48 slides•4.9K views
作る人から作りながら運用する人になっていく by Ryo Mitoma, has 56 slides with 1064 views.
作る人から作りながら運用する人になっていく作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
Ryo Mitoma
56 slides•1.1K views
継続的インテグレーション3分クッキング by Takayuki Kondou, has 28 slides with 5717 views.
継続的インテグレーション3分クッキング継続的インテグレーション3分クッキング
継続的インテグレーション3分クッキング
Takayuki Kondou
28 slides•5.7K views
Firefoxの開発プロセス by Makoto Kato, has 51 slides with 1192 views.
Firefoxの開発プロセスFirefoxの開発プロセス
Firefoxの開発プロセス
Makoto Kato
51 slides•1.2K views
博士論文公聴会 by Makoto SAKAI, has 43 slides with 4012 views.
博士論文公聴会博士論文公聴会
博士論文公聴会
Makoto SAKAI
43 slides•4K views
継続的デリバリー読書会資料 #1 by Yusuke HIDESHIMA, has 50 slides with 1695 views.
継続的デリバリー読書会資料 #1継続的デリバリー読書会資料 #1
継続的デリバリー読書会資料 #1
Yusuke HIDESHIMA
50 slides•1.7K views

More from Hiro Yoshioka (20)

Infra study 2nd #1 人生100年時代の学び方,定年後の大学院生活 by Hiro Yoshioka, has 51 slides with 2312 views.
Infra study 2nd #1 人生100年時代の学び方,定年後の大学院生活Infra study 2nd #1 人生100年時代の学び方,定年後の大学院生活
Infra study 2nd #1 人生100年時代の学び方,定年後の大学院生活
Hiro Yoshioka
51 slides•2.3K views
Infra study 2nd #1「インフラ技術者・研究者としてのキャリア」 by Hiro Yoshioka, has 50 slides with 1065 views.
Infra study 2nd #1「インフラ技術者・研究者としてのキャリア」Infra study 2nd #1「インフラ技術者・研究者としてのキャリア」
Infra study 2nd #1「インフラ技術者・研究者としてのキャリア」
Hiro Yoshioka
50 slides•1.1K views
不揮発性メモリ(NVM)とはなにか by Hiro Yoshioka, has 22 slides with 1018 views.
不揮発性メモリ(NVM)とはなにか不揮発性メモリ(NVM)とはなにか
不揮発性メモリ(NVM)とはなにか
Hiro Yoshioka
22 slides•1K views
続・人生100年時代の学び方 by Hiro Yoshioka, has 53 slides with 1738 views.
続・人生100年時代の学び方続・人生100年時代の学び方
続・人生100年時代の学び方
Hiro Yoshioka
53 slides•1.7K views
人生100年時代における学び方 定年後の学生生活 by Hiro Yoshioka, has 47 slides with 433 views.
人生100年時代における学び方 定年後の学生生活人生100年時代における学び方 定年後の学生生活
人生100年時代における学び方 定年後の学生生活
Hiro Yoshioka
47 slides•433 views
Thesis introduction "RECIPE : Converting Concurrent DRAM Indexes to Persisten... by Hiro Yoshioka, has 24 slides with 198 views.
Thesis introduction "RECIPE : Converting Concurrent DRAM Indexes to Persisten...Thesis introduction "RECIPE : Converting Concurrent DRAM Indexes to Persisten...
Thesis introduction "RECIPE : Converting Concurrent DRAM Indexes to Persisten...
Hiro Yoshioka
24 slides•198 views
人生100年時代の学び方、脳には可塑性がある by Hiro Yoshioka, has 46 slides with 544 views.
人生100年時代の学び方、脳には可塑性がある人生100年時代の学び方、脳には可塑性がある
人生100年時代の学び方、脳には可塑性がある
Hiro Yoshioka
46 slides•544 views
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方、「私のような仕事につく方法」、2019/06/23 DevLOVE X Day 1 D-7 by Hiro Yoshioka, has 53 slides with 10055 views.
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方、「私のような仕事につく方法」、2019/06/23 DevLOVE X Day 1 D-7エンジニア人生と定年退職、人生100年時代のエンジニアの生き方、「私のような仕事につく方法」、2019/06/23 DevLOVE X Day 1 D-7
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方、「私のような仕事につく方法」、2019/06/23 DevLOVE X Day 1 D-7
Hiro Yoshioka
53 slides•10.1K views
Infra study 2nd #1 人生100年時代の学び方,定年後の大学院生活 by Hiro Yoshioka, has 51 slides with 2312 views.
Infra study 2nd #1 人生100年時代の学び方,定年後の大学院生活Infra study 2nd #1 人生100年時代の学び方,定年後の大学院生活
Infra study 2nd #1 人生100年時代の学び方,定年後の大学院生活
Hiro Yoshioka
51 slides•2.3K views
Infra study 2nd #1「インフラ技術者・研究者としてのキャリア」 by Hiro Yoshioka, has 50 slides with 1065 views.
Infra study 2nd #1「インフラ技術者・研究者としてのキャリア」Infra study 2nd #1「インフラ技術者・研究者としてのキャリア」
Infra study 2nd #1「インフラ技術者・研究者としてのキャリア」
Hiro Yoshioka
50 slides•1.1K views
不揮発性メモリ(NVM)とはなにか by Hiro Yoshioka, has 22 slides with 1018 views.
不揮発性メモリ(NVM)とはなにか不揮発性メモリ(NVM)とはなにか
不揮発性メモリ(NVM)とはなにか
Hiro Yoshioka
22 slides•1K views
続・人生100年時代の学び方 by Hiro Yoshioka, has 53 slides with 1738 views.
続・人生100年時代の学び方続・人生100年時代の学び方
続・人生100年時代の学び方
Hiro Yoshioka
53 slides•1.7K views
人生100年時代における学び方 定年後の学生生活 by Hiro Yoshioka, has 47 slides with 433 views.
人生100年時代における学び方 定年後の学生生活人生100年時代における学び方 定年後の学生生活
人生100年時代における学び方 定年後の学生生活
Hiro Yoshioka
47 slides•433 views
Thesis introduction "RECIPE : Converting Concurrent DRAM Indexes to Persisten... by Hiro Yoshioka, has 24 slides with 198 views.
Thesis introduction "RECIPE : Converting Concurrent DRAM Indexes to Persisten...Thesis introduction "RECIPE : Converting Concurrent DRAM Indexes to Persisten...
Thesis introduction "RECIPE : Converting Concurrent DRAM Indexes to Persisten...
Hiro Yoshioka
24 slides•198 views
人生100年時代の学び方、脳には可塑性がある by Hiro Yoshioka, has 46 slides with 544 views.
人生100年時代の学び方、脳には可塑性がある人生100年時代の学び方、脳には可塑性がある
人生100年時代の学び方、脳には可塑性がある
Hiro Yoshioka
46 slides•544 views
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方、「私のような仕事につく方法」、2019/06/23 DevLOVE X Day 1 D-7 by Hiro Yoshioka, has 53 slides with 10055 views.
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方、「私のような仕事につく方法」、2019/06/23 DevLOVE X Day 1 D-7エンジニア人生と定年退職、人生100年時代のエンジニアの生き方、「私のような仕事につく方法」、2019/06/23 DevLOVE X Day 1 D-7
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方、「私のような仕事につく方法」、2019/06/23 DevLOVE X Day 1 D-7
Hiro Yoshioka
53 slides•10.1K views

テスト勉強会よしおか100311 1

  • 1. よしおかひろたか テスト勉強会 楽天株式会社 開発部 アーキテクトGよしおかひろたか | 2010年3月12日 1
  • 2. よしおか 本日のメッセージ 開発者の皆さん、 テストを書こう テストを書く=テストコード+入力データ+期待する出力デー タ Excelでテストケースを作ることではない。 2
  • 3. アジェンダ • 大規模ソフトウェア開発におけるディ リービルド&リグレッションテスト 3
  • 4. 自己紹介 • 開発部、ACT課アーキテクトG、技術理事 よしおかひろたか • 2009年8月入社 • カーネル読書会の主宰者、DEBUG HACKS共著 ISBN978-4-87311-404-0 • twitter @hyoshiok http:// d.hatena.ne.jp/hyoshiok 4
  • 5. わたしの経験から • 大規模ソフトウェア開発の現場の経験をお 話する。 – ソフトウェア製品開発は受託開発とは相当異な る。 • 事例: – Oracle8の開発現場 – DEC Rdbの日本語化、国際化 – 日本語COBOL – Samba3.0国際化対応(オープンソースの場合) 5
  • 6. Oracleの場合 • 開発環境 • 開発プロセス • プログラマの日常 • リズム • チェックアウト、チェックイン • ディリービルド • リグレッションテスト • 学んだこと 6
  • 7. Oracle 8の場合 • わたしが参加した時期、1995年~2000年 • Oracle8/8iあたりのころ • 開発環境:Sun Workstation、SunOSから Solaris • Clearcaseベースの開発環境。 – ファイルの仮想化。一人で複数のブランチを同 時に持てる。 • 例えば、Oracle 7.3用、Oracle 8用、Oracle 8.1用。バグ 修正、機能ごと、ちょっとした確認用などなど • check-outしたものはcheck-inするまで他の人には見え ない。 7
  • 8. 開発プロセス(Oracleの場合) • 要求仕様作り(開発者) – 外部API、UIなどを決定する。 • 例:SQLのシンタックス、セマンティックスを定義する。 – リファレンスマニュアルのベースになる。 • 設計(開発者) – APIなどを決定したら、設計&実装になる。 • 実装(開発者) – コードを書く、テストを書く、テストをする • ディリービルド&リグレッションテスト(自動) – チェックインされた最新のコードをスクラッチからビルドして、リグレッションテ ストを実行。 • チェックインしたコードの概要と、テスト結果の概要が日々担当者にメールで送られる • 常に動くコードが毎日ある。 • 安定化プロセス – フィーチャーフリーズ(機能追加を凍結する) – コードフリーズ(重大なバグフィックス以外のチェックインを認めない) 8
  • 9. ソフトウェア製品開発のプログ ラマ • 設計者が実装者でテストも書く • 一つの機能については、すべて知って いる。 • コーダーという人がいるわけではない 。 9
  • 10. プログラマの一日 • 朝会社に来る。 • コーヒーでも飲みながら、メールをチェックする。 – 担当のテストを確認する。 • 自分が昨日チェックインしたコードがリグレッションテストを壊していないか。 • 他の人のチェックインが、担当テストを壊していないか。 • 壊れている場合は、調査する。あるいは調査を依頼する。 • 仕掛の作業を行う。 – コードを書いたり、テストを流したり、あれやこれや。 – 全テストを流すと時間がかかるので、サブセットを流す – コードが安定したら当該ブランチの最新版にマージする • 自分の環境で動作確認ができたら、 – 同僚にレビュー依頼をして、コメントをもらう。特に問題がなさそうの場合、リリ ースマネージャーにチェックインの許可をもらう。 • 許可が出たら、チェックインする。 – 次の日はどきどきしながらリグレッションテストの結果を見る • 休暇の前に確認しないでチェックインをするな、という不文律 – http://d.hatena.ne.jp/hyoshiok/20040516#p1 10
  • 11. リズム • チェックアウトして • コードをいじって、テストを書いて、 • テストを実行して、OKになるまで繰 り返して、 • 同僚にレビューしてもらって、 • リリースマネージャに許可をもらって 、 • チェックイン 11
  • 12. チェックアウト、チェックイン • 複数のブランチを同時にいじっている • バージョンがいくつか • それぞれについて、バグフィックス、 機能変更、機能追加、機能ごとに別々 のブランチを切っておく。 • 最新のバージョンでバグフィックスし たものを昔のバージョンに適用するこ ともある。(バックポート) 12
  • 13. ディリービルド • 毎日大量のチェックインがある。数十 ~ • 最新のソースからビルドする。 – コンパイルエラーが出るチェックインは 無条件にロールバックされる。 – 複数のビルドマシンで分散ビルド • 安定性に差こそあれ常に動くものがあ る。 – Oracle8の最初のビルドは前バージョン (Oracle 7.3)と同一。ここから始まる。 13
  • 14. リグレッションテスト • ディリービルドされた最新の実行イメージ でリグレッションテスト(数千)を実行す る – 10数台(?)のサーバーマシンで何時間もかか る。 – テストコード、入力データを与えて、期待する 出力と実際の出力の差分を見る – diff(差分)が出たらそれを目視確認する。期待 する結果なのか、いなか。 – 新機能追加、バグフィックスの場合は対応する テストの追加、修正などを行う。 – リグレッションテストがあるので、既存の機能 の予期しない影響がすぐにわかる。リグレッシ ョンの発見。 14
  • 15. 安定化プロセス • あるクライテリアで、安定化プロセスに入 る。 – 新機能の追加を凍結する(feature freeze)期間に 入る – バグ修正だけを行う – リグレッションテストのdiffの数を減少させる – テストの追加、実行だけをやって、製品の安定 化を図る。 – あるクライテリアで、重大なバグ修正以外は一 切変更を認めない(code freeze)期間に入る。 – バグ(不具合)はリリースノート等に記載し出 荷する 15
  • 16. 学んだこと • ディリービルドによって、常に動作が確認されてい るものがある。 – どの機能が実装されていて、どの機能が実装されていない かが一目でわかる – 実装すべき機能のプライオリティが変更になったとしても 、すぐに対処可能 – スケジュールが遅延した場合、どの機能を落とすかの判断 が容易に可能。(どれが動いているかいないかを把握でき ているので) • 大規模ソフトウェア開発において俊敏性を高めるベ ストプラクティスで、ソフトウェア製品開発では広 く利用されている。(例:マイクロソフトのOS開 発など) • 闘うプログラマー http://books.rakuten.co.jp/rb/6130084/ 16
  • 17. DEC Rdbの日本語化、国際化 • ソフトウェアの日本語化プロセス • ビルド環境って • インターネット以前のソフトウェア開 発 • 学んだこと 17
  • 18. DEC Rdbの場合 • ソフトウェアの日本語化プロセス – 米国本社で開発されたソフトウェアを日本で日 本語化した。(別のバイナリーになる) • 1980年代後半のころ • 参加人員:日本側開発者3名~。US側は100名前後 • 開発環境の入手 – ソースコードの入手 – ビルドスクリプト – テスト環境 • 開発環境構築 – VAX/VMS、OSの違い、コンパイラの違い、その他ツールの違 いなどなどで一筋縄では行かない場合も • 実際の開発 – ビルド&リグレッションテスト 18
  • 19. ビルド環境 • 開発環境を日米で完璧に一致させることは 難しい – もちろん仮想化環境などはない。ツール、コン パイラ、OSのバージョン • 社内ネットワークはあったが回線が細い – 100MBをコピーするのに足掛け3日とか • リグレッションテストの結果を確認するの が難しい。(開発環境が微妙に異なるので ) – 安定化させるのに2~3ヶ月かかることも。 19
  • 20. インターネット以前のソフトウ ェア開発 • 大規模分散開発だったのだけど、 – 社内ネットワークの帯域は細かった – コミュニケーションは、メール、電子掲示板(VAX Notes) • 最終的には、本社に乗り込んで、ソースコードをマ ージした(1990年ごろ) • DECはOS(VMS)、ハードウェア(VAX)、ミドルウ ェア(Rdb)、コンパイラ、ツール、その他すべて内 製品。垂直統合型企業 • SQA (Software Quality Assurance)という部隊があっ た。 – OS/HW/ミドル:各レイヤーの互換性をリグレッションテ ストで確認 20
  • 21. 学んだこと • 米国本社のエンジニアと一緒に働いた • すごいエンジニアがいっぱいいた • ソフトウェア国際化のあるべき姿につ いてとことん議論できた • 大規模広域分散ソフトウェア開発のイ メージが持てた 21
  • 22. 日本語COBOLの場合 • 非力なマシンでのソフトウェア開発 • コード管理システム、モジュール管理 システム、テスト管理システムなどの お話 • バグ管理 • エンジニアのイロハを教えてもらった • 学んだこと 22
  • 23. プロジェクト概要 • 日本語COBOLの開発 – 1984年~ – 3人(自分は新卒プログラマ) – 開発環境、VAX/VMS – 言語:BLISS、SCAN(独自の言語) • コード管理システム、モジュール管理 システム、コンパイラ、テスト管理シ ステム、バグ管理システム、すべて自 社製 23
  • 24. • 夜中の0時に、ビルドのバッチが動き出し、 その後テストを実行する。 – チェックインしたファイルのdiffをメールするよ うにした。 – 見よう見まねで、makeファイルを書いた。 – テストスクリプトもテスト管理システムを利用 して書いた。テスト結果もメールした。 • チェックインの数、発見したバグの数、修 正したバグの数などをグラフにすると、週 単位での進捗が見えた。 24
  • 25. バグ管理 • テストプログラムは、自分以外が実装 した分について書いた。(他人のコー ドをテストする) • 発見したすべてのバグはバグデータベ ース(自作)に登録した。 – 110件くらいバグを発見したと思う。 – バグの分析などもした。3割くらいが未実 装。 25
  • 26. エンジニアのイロハを教えても らった • マニュアルを読むこと • テストを書くこと • デバッグの仕方 • 質問の仕方 26
  • 27. 学んだこと • 社内にはすごい人がいっぱいいる • 自分もそうなりたい • ソフトウェア開発プロセスのイロハ • 大規模分散開発のイメージ(未来像) • ソフトウェア国際化のイメージ(未来 像) 27
  • 28. Samba3.0国際化対応の場合 • オープンソースとコミュニティの対応 • 新参者がコミュニティに入るには • プロジェクトの流れ • オープンソースの都市伝説 • プログラマの日常 • リズム • 学んだこと 28
  • 29. Samba3.0国際化 • プロジェクト概要 – Samba2.xは日本人コミュニティが開発した日本 語パッチがあったが、Samba3.0になって、内部 コードがUnicodeになったため当該パッチが利用 できなくなりShiftJIS関連の問題が発生した。 – Unicode対応、テストの追加など – 2003年ごろ – http://www.miraclelinux.com/technet/samba30/index.html – http://d.hatena.ne.jp/hyoshiok/20041022 29
  • 30. オープンソースとコミュニティ • 高い技術力とdisciplineを持ったハッカーによ って構成されている – 企業の開発者は企業の利益拡大 – 企業の開発者とコミュニティのハッカーの利害 が一致するとは限らない。しばしば相反する。 • パッチを送ったからといって受け入れられ るとは限らない。 – 技術的な問題というより、しばしばコミュニケ ーションの問題だったりする 30
  • 31. 新参者がコミュニティに受け入れら れるには • 何の実績もない人が受け入れられるには – 技術の問題ではなくコミュニケーションの問題だと認識し た • Samba-jp(日本のコミュニティ)とSambaのコミュニティの 関係。両方に受け入れられる必要がある。 – テストをどんどん作って、発見した問題をバグデータベー スにどんどん登録した。チームのメンバーは個人名で登録 。 – ついでにパッチなども投稿した。個人名で投稿。 – 直接会って話したり、メール、チャット、電話会議などで 、プロジェクトの紹介などを行った。 – コミュニティにデビューするには、自分たちの技術力を理 解してもらう必要がある。バグフィックスは最初の一歩。 – 大きなパッチをいきなり送るのではなく、小さいバグフィ ックスの積み重ねで、徐々に信頼を得ていく。 31
  • 32. プロジェクトの流れ • ディリービルド、リグレッションテストの開発環境を準備し た。 • Sambaのテストフレームワークを利用し – テストケースの作成 – テストコードの作成 – テストの実施 – 不具合をbugzillaに登録 – 修正パッチを投稿 • 機能追加、修正などのパッチを適宜投稿。本家にマージして もらう。 • 英語のホームページ、ドキュメントなども用意した • フェースツーフェースの会議、メール、チャット、電話など 様々な方法をとった 32
  • 33. オープンソースの都市伝説 • ハッカーは無法者? – 極めて高い技術力とdiscipline(規律)を 持つ – コミュニティの価値を大切にする – プロフェッショナルである 33
  • 34. プログラマの日常 • やることリストの確認 • Bugzillaのチェック • テストの追加 • パッチの作成 – リグレッションが起こっていないことを 確認 – 新機能が実装されていることを確認 • コミュニティへ投稿 – メーリングリスト、電話、チャット、な どなど 34
  • 35. リズム • 作成したテスト数が見える • バグの数が既知 – 最初にテストがあるので、そのテストで 発見した数が初期値になる – Samba3.0は今ここにあるが国際化の機能 がない。(バグの数=実装すべき機能) • バグの数を減らしていくのがリズム 35
  • 36. 学んだこと • OSSもテストファーストできた • 何をやりたいかをテストで表現した WHAT • テストを作ることによってオリジナル 製品の挙動を深く理解した • プロジェクトマネージャーとして、プ ロジェクトの進捗が、テストの進捗、 残バグ数によって見える化されている ので、安心。 36
  • 37. ちょっとした思い • プロフェッショナルって • 変化を許容すること • プログラマに必要な3つのチカラ 37
  • 38. プロフェッショナルについて • ソフトウェアは人が作る – 自分がプロフェッショナルになるしかな い… – アスリートが毎日トレーニングしている ようにわれわれはトレーニングをしてい るだろうか 38
  • 39. 変化を許容することについて • 環境は変化する • 自分は変化しているだろうか • 成長しているだろうか 39
  • 40. プログラマに必要な3つのチカ ラ • ソースコードリーディング • テスト • デバッグ • ワークショップや勉強会を開催してい きたい~~~ 40
  • 41. 経験則 • テストを書かない プロフェッショナルはいない (プログラマ的な意味で) • テストのないコードは レガシーコードだ。 • 読書会しましょう~ レガシーコード改善ガイド 保守開発のためのリファクタリング、翔 泳社 http://books.rakuten.co.jp/rb/6121689/ 41
  • 42. • 公理1:すべてのプログラムは テストをしなければいけない。 • では、どうテストをするか – A:人がやる – B:テストコードを書いて、それを実行す る – 正解:B – 証明:自明。 42
  • 43. テストを作ると • システムの振る舞い(WHAT)を 記したことになる – テストを作ることによって、システムの 深い理解を得られる – 安心感を得られる(心の平静を保てる) 43
  • 44. テストがあると • 変更の影響が即座にわかる – 影響範囲がわからなくて、 塩漬けではなく、 どんどん積極的に変更できる >変更容易性、アジリティ向上 – 安心である。(心の平静が保てる) 44
  • 45. テストがあると • 機能を確実に実装したことを 確認できる。 – 手作業による確認は、もれやミスが発生 する。コストが高いし、なにより楽しく ない。 – 機械が実行してくれるので、楽である。 – 安心である。 (心の平静が保てる) 45
  • 46. テストがあると • 変更容易性があがり、 運用コストが下がる – OSやHWなどシステムを変更したときも 、その影響がすぐにわかる – 安心である。 (心の平静が保てる) 46
  • 47. レガシーコード改善ガイド読書 会 • レガシーコード改善ガイドを読む • 世話役:アーキテクトGよしおかひろたか • 日程:木曜日、19時~20時30分ころ • やり方:分担で、説明して、参加者による 議論 • ペース:一回あたり60ページくらい進みた い。7回程度で全部を網羅したい • レガシーコードを改善して楽をしよう  ご参加 おまちしてます 47
  • 48. 開発者の皆さん、 テストを書こう テストを書いてプロフェッショナルにな ろう 世界へ 48
  • 49. 49