アジャイルサムライ読書会(湯島道場) 第五回　空の巻に参加してきた #agilesamurai #湯島道場

勉強会 読書会 Agile


(写真：湯島道場開催回全ての会場となった株式会社アルティネット様会議室入り口にて1枚。)

先月から計5回、約1ヶ月半を掛けて行われた『アジャイルサムライ読書会in湯島道場』の予定最終回となった第5回。月末や業務都合等で直前キャンセル等もありましたが、その分これまでの回よりも若干座席スペースに余裕を持たせた形で会が進みました。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)

The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)

『アジャイルサムライ』読書会公式＆ポータルサイトはこちら。1

また、『アジャイルサムライ』読書会湯島道場に関するページは以下。

読書会第5回の範囲は第5部(12章〜15章)。目次レベルの内容がこちら。

第V部 アジャイルなプログラミング
  第12章 ユニットテスト：動くことがわかる
    12.1 ラスベガスへようこそ！
    12.2 はじめてのユニットテスト
  第13章 リファクタリング：技術的負債の返済
    13.1 どうしてこうなった
    13.2 技術的負債
    13.3 リファクタリングで技術的負債を返済する
  第14章 テスト駆動開発
    14.1 テストを先に書く
    14.2 テストを使って複雑さに立ち向かう
  第15章 継続的インテグレーション：リリースに備える
    15.1 ショータイム
    15.2 リリースに備える文化
    15.3 継続的インテグレーションとは
    15.4 どうすればうまくいくのか？
    15.5 チェックイン手順を習慣づける
    15.6 ビルドを自動化する
    15.7 作業単位を小さくする
    15.8 この先どこへ向かえばいいのか？

アイスブレイク

今回も前回同様初参加者メンバーは無し。そのままLTに進みました。

LT：アジャイルなプログラミング

前回に引き続き、今回も湯島道場の師範代である@t_wadaさんがご参加。しかも今回の対象範囲(12〜15章)は和田さんが書籍レビューを担当されたというこの上ない組み合わせ！となりました。

以下LTメモ。

  • LT依頼は昨日言われました。
  • 読書会の本質は座談会・ワールドカフェ。
  • 質問を頂いて、それに対して喋る形で行きましょうか。
  • 『アジャイルなプログラミング』
    • 原文は『Creating agile software』。若干意訳的ではあるが、まぁ良いのでは。
    • 『アジャイルサムライ』レビューについて：角谷さんから後ろ4章(12〜15章)を読んでレビューして欲しい、と依頼を受ける。
  • ソフトウェア開発の3本柱
    • バージョン管理：この書籍では記述が無い！
      • バージョン管理は全ての開発の基盤であり、サムライは当然バージョン管理をするものである。
      • あまりにエッセンシャル(Essential:欠く事が出来ない要素)なので書いてない。当たり前過ぎる。
    • テスティング(第12章)
      • 本書では、TDDでは無くコードでテストを書こう、という意味合いに近い？
    • 自動化(第15章)
      • テスト・リファクタリングだけでは片手落ち。
      • 現在ではJenkinsが有名となっている。
      • 自動化の意義
        • (×)ツールを回す事
        • (○)人がやる事をどれだけ機械が肩代わり出来るか
  • Jenkins等のCIツールは、導入するまでの準備が必要な部分がある。
    • 和田さんが現在携わっている直近のプロジェクトでは、一番自動化されているものは"シェルスクリプト"。
  • 自動化：なだらかに進めて行くべき。
    • 日々の暮らしから連続していくところに自動化がある。
    • どこかに無駄、ミスが無いかを考え続ける事。
  • テストの再分類
  • TDD
    • 本書第13章、第14章で触れている。
      • 『動作する、綺麗なコードへ』
        • この言葉の原典は『ピンクのXP本』らしい。

XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)

XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)

    • TDDのサイクル
    • TDDと黄金の回転：ぐるぐる回す！回していく過程で…
      • 実装に集中する。
      • 綺麗にする事に集中する。
      • 汚いところから綺麗なところへ突破するのは『リファクタリング』のみ。
    • なぜTDDをするのか。その様々な理由。
      • 完璧なプログラマではない
      • 思い通りに掛けるほど賢くはない
      • 対象は単純ではない
      • ：
      • ：
    • テストは目的ではなく手段である。
    • プロとしてのたしなみ
      • 先にテストコードを書くのは難しい。思考の逆転が求められる
      • 段々に書けるようになっていく
      • 向かっていく意志が大事。
      • スモールスタートで始めよう
      • サムライならばテストコードを書こう。
    • 沢山本を読もう

達人プログラマー―システム開発の職人から名匠への道

達人プログラマー―システム開発の職人から名匠への道

  • 作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/11
  • メディア: 単行本
  • 購入: 42人 クリック: 1,099回
  • この商品を含むブログ (347件) を見る
Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

    • 世間で広まっている『技(パターン)の名前』はこういった書籍からの出典が多い。
    • これらの書籍を読み解いていく事で考えが繋がっていく。
    • 考えに名前をあたえて共有する：パターン
      • 名前が付くことで議論が出来る
    • パターン本を読もう!
    • 写経から始めよう
    • わからないので写すことからはじめる
      • 最近だとHaskell読書会…さっぱり分からないので写経を実践中。

テスト駆動開発入門

テスト駆動開発入門

    • リファクタリング(ファウラー本)
      • 『言いたい事が全部(ケントベックによって)書かれてあってガッカリする…』事多数。
        • 『ガッカリする』のニュアンスとしては"ケントベック"に対して。記載のあったのが「テスト駆動開発入門」で、リファクタリングでも書いてあったと見てみたらケントベックが書いた部分だったので…という感じのようです。(※ご指摘ありがとうございます！)
        • (※今回のLT/座談会の過程で3回位、『ガッカリした』とのコメントがあったような気が…それだけこの本はスゴイのでしょう。)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

  • 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/05
  • メディア: 単行本
  • 購入: 94人 クリック: 3,091回
  • この商品を含むブログ (312件) を見る

以上、画像はTDDBC福岡のものから拝借致しました。

贅沢過ぎる位のクオリティ・ボリュームなLTでした。いやぁ〜、ここを聞けただけでも道場に訪れた価値があるってもんです。(だがしかしサプライズはこれだけではありませんでした…。)

座談会

LTでの和田さんの提案もあり、最初に幾つかの質問を梶浦さんの方から出席者全員に対して投げ掛け、それらの中からチョイスしつつ場を進めて行く方向で座談会開始。

  • (質問)コードを書いている人、そうでない人は？
    • (回答)ほぼ半々で書いている人/そうでない人に分かれた。
  • (質問)コードを書いている人へ：言語は何を使っている？
  • (質問)リファクタリングとテスト駆動開発の関連について：どう思うか？
    • (回答一覧)
      • 『リファクタリングに汚名が着せられる』という記述が気になる。
      • リファクタリングは難しい。
      • リファクタリングをやらないと進めなかった。
      • 技術的負債はコードだけじゃない(設計書等)。その辺の調整度合いについて気になる。
      • リファクタリングを行ったらテストがコケた。難しい…。事前の設計が必要だ。
      • コードは書いてない、リファクタリングには後々の為に時間を掛けている
      • リファクタリングよりスクラップビルド派。常に荒海をかき分けて進んでいる。
      • リファクタリングの判断基準・止め時を知りたい。
      • コード自体、自社のものではない。リファクタリングするな！触るな！という現状。あまり変えたくても変えられない事が多かった。
      • 今の会社に来る前まではフリーだった。師匠と一緒にXP的開発、リファクタリング重要。最初は動くコード重要。リファクタリングはやる。でないと後々大変。
      • 期限が決められてないと続けてしまう。
      • レガシーコード：手遅れの状態が多い、こまめに対処が必要
      • 技術的腐敗＝アーキテクトの問題？苦手な分野ではある
      • クライアントアプリ：WindowsのGUIプログラムを触っている。全くテストコードが無い状態。GUIはテストが難しい？
      • リファクタリングについては、コードレビューを事前に行い、リファクタリングをする知識を得たかった。コストを割けているとは言い難い。
      • 今の現場でようやくリファクタリングという言葉が浸透。でもコピペ蔓延。→指摘するも『どうやっていいか分からない』。デザインパターンを押さえてないと難しい部分もある。

これらを受けて和田さんのコメント。

    • リファクタリング啓蒙＝シンプル、小さいコードから始める。
      • 開発の現場で聴いてくるのは1年後とかの話。
      • 一番大事だけど一発モノのイベントでリファクタリングを実感させる事に腐心。
    • (和田さん自身の)プログラミングのやり方を決定的に変えたのは、テストではなくリファクタリングの要素が多い。
      • 最初から正解が出なくてもいい。そこからシステマティックに治す方法がある。
      • 目の前の問題を解きつつ対処して行く方法がある。

自分自身先日参加したTDDBCでまさにこの辺りの状況(リファクタリングより課題優先)に陥っていた節もあるので、身を以てこのコメントに共感し、痛感していました…^^;

それにしても、和田さんから『リファクタリング重要！』という言葉が聞けたのは新たな感動でした。この流れでまずは一番多かった『リファクタリングに関する判断』というテーマで議論が進みます。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

  • 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/05
  • メディア: 単行本
  • 購入: 94人 クリック: 3,091回
  • この商品を含むブログ (312件) を見る

…と紹介をした時点で、和田さんが『あっ、これは朗読すれば良いんだね』と何と自ら書籍の該当箇所を朗読して頂けるというサプライズあり！

和田さん自身も以下の様に読書会終了後のつぶやきでコメントしておられます。


(※追記：写真は書籍『リファクタリング プログラミングの体質改善テクニック』該当15章の先頭ページ。自分もこの箇所を熟読したくて結局書籍を買っちゃいました。)

時間にすると5分程だったでしょうか。質問事項であった『リファクタリングの止め時』についての回答が得られると同時に、和田さんにその回答となる部分を読んで頂けるという何とも贅沢で貴重なひとときを今回湯島道場参加者は味わう事が出来ました☆

朗読内容は全て追う事が出来なかったので内容の全体像は割愛しますが、この箇所を読むためだけに書籍購入を検討しても良いかなと思ってます(まだ持ってない)。

  • あなたがプログラミング、対象に諦観(おちつき)を得た時が止め時。
  • 止める事はリファクタリングの中で最も難しい。
  • 確信が持てない時が辞め時。改善されていれば良い。改善されてない場合は全部捨てる。
  • リファクタリングは学習可能な技能。

以降、質疑応答を交えながら進んで行きます。

  • 大前提として『いつでも辞められる』事が大事。
    • 行っちゃったらやりきらないといけない…ルビコン川を渡るような状況が往々にしてある。
    • 中規模、大規模のモノは渡ったら渡りきらないと。

パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法

パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法

    • 和田さんの会社で開発しているフレームワーク：4年近く経っている。
      • データベースリファクタリングが必要なケースも。
        • 同期部分、非同期部分を切り分ける…『この辺で勘弁してやるか』
        • 結節点を作っておく。
        • 既存のものを（テストも含めて）残しつつ、考える。
        • リファクタリングで怖い部分…やることでこれまでの積み上げたテスト・信頼が崩れていく事。

      • 日々のプログラミングを守る＝ユニットテスト
        • テストは色々な粒度があるべき
        • 設計の原則に収束していく
        • 逃げ道を用意しておく。必ずブランチでやるとか。
        • データが絡むリファクタリングはかなりシビア。ダンプが取れるフックを仕込んでおき、何かあったら戻す。
  • 元々テストが無いところをスクラップ・ビルド。
    • 上のレイヤーに立って言うと
    • キャパシティはどうやって取るの？
    • 大きいリファクタリングの場合はユーザーストーリーで対応。
    • 時間がリファクタリングの辞め時として来るんじゃないか。
      • チャイムが鳴ったので辞めましょう。
      • リファクタリングを辞めるきっかけに大いになり得る。
      • 綺麗な設計には辞め時がない。
      • リファクタリングのサイズを小さくしておけば満足度は大きい。
      • 技術的負債・不安をなるべく溜めないこと。
    • きのこ本 No.7：ボーイスカウトルール
      • キャンプ場でのルール『来たときよりも美しく。』

プログラマが知るべき97のこと

プログラマが知るべき97のこと

        • プログラミングにも当てはまる。
        • 結構ラディカルな考え方かも。
        • リファクタリングを日々のプログラミングに細かくまぶす。
  • 自分アジャイルプロセスはいまいち。イメージが付かないけれども...
    • ストーリーをこなす。と決める。
      • その中でそのストーリーが出来た事が大事。
      • リファクタリングはプロセスのいつに入れるか。時間を取るべきか？中に混ぜるか。
        • リファクタリングを含めると、チームの生産性としては遅くなってしまう。
        • リファクタリングも含めてプログラミング。含めてベロシティで出すものでは。
        • リファクタリングしないとなかなか難しい事になってしまう。
          • コツはやっぱり『ちょっとずつ』。
          • リファクタリングをやった方がプログラミングが早くなる。
        • 直近のものになるとリファクタリングしないほうが早いけど、時間が経つと『調べる』ところから再開となってしまう。
          • デバッキングが必要。結局時間が掛かる
          • お釣りが来る(リファクタリングの恩恵を受ける)のは思ったより早い。
          • 基本的には整理整頓されているものを使った方が早い。
  • 技術的負債…対処しないと大変な事に。
    • リファクタリングが持っているコンテキスト
      • 1.作りながら行うもの
      • 2.あるものに対して（技術的負債）行うもの
    • 放置することでどれ位のリスク、コストが掛かるのか？その辺の天秤度合い。
  • 画面にテストが書けない。『詰んだ〜』というケース
    • レガシーコード改善ガイド『テストがないコードはレガシーコードだ!』

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

    • 一つは発生ベースで立ち向かう
      • 必要なければやらない
      • 必要が生じたら
        • 自分が手を入れるところ『だけ』は安全にしておく
        • テストが出来るようにしておく
          • カプセル化を緩める
          • 入れ替えられるようにすす
          • テストが勧誘して、進められるようにしていく
        • 熱い思いは大事だけど
          • 自分の手を入れる部分だけでも安全に…
          • フォーカスを絞って。
        • レガシーコード改善ガイド重要！
        • 『対レガシーコード』の議論は多い。
    • 今動いているモノに対してユニットテストから書いていくかどうか？→これが難しいから負債たり得ている。
      • 大外から攻める。
        • 中の構造は良いからブラックボックスレベルを担保して進める。
          • ここで『レガシーコード改善ガイド』の出番ですよ。
    • PHPでレガシー：かなり危うい。
      • レガシーコードは仕様書ないよね、あっても有害。
      • キャラクタライぜーション（仕様化）テスト
        • 仕様をテストコードに写し取っていこう。
          • 何が正しいか
          • どうあるべきか
          • それはそうと今どう動いているか
          • 『何が正しいか』が失われている…NULLを渡すと5が返る＝仕様として写し取っていく
          • 安全ゾーンを拡げて行きつつ、問題は置いておいて…仕様化を続ける。
        • モードの切替が重要。
      • 対レガシーは仕様化テストを書く事から始まる。
        • まずはまるっとバージョン管理
        • 仕様化テストを介入させる為の穴を開ける
          • ここが『ピンチポイント』だ、と全体が通る細い道を探し、要所を探しだし介入させていく
          • 安全ゾーンを増やしていく。陣取り合戦のように。
  • アーキテクチャの見直すタイミングが来る。既存のレガシーコードに対する戦い方。
    • いろいろ。
      • レガシーコード改善ブートキャンプ。
      • 囲い始めるとイノベーション（アーキテクトジャンプ）がおきにくくなる？
      • システム自体は動き続ける粘土・アメーバである。
        • 大きく変わる＝ジャンプ。
        • ジャンプしなきゃ行けない土台を作る事が大事。
          • コードの重複を直す事が大事
          • 色々な粒度のテストを用意しておく。
      • アーキテクチャジャンプは生き残っていくために必要。
      • 例えば既存のWebアプリを→Google Appsに置き換えるにしても…
        • データ構造生き残る/言語的なのはばっさり無くなる、など対処が必要
        • データ構造に関する部分は大きい。
    • 引き返し可能・不可能な決定を判別しておく
      • シンプルな設計＝善、という訳でもない
      • 『これに救われた』という知識を如何に含めていくか。※ログ、例外など
        • 例）テストで全部守られているのでログ出力はありません！→うごかない→ログが無い…
      • 経験に基づき、積めるものは積んでいく。
        • プログラミングは、迷ったらシンプルに。
        • データは、迷ったら分けておく。
  • TDD導入について
    • いきなりガッツリやるのは難しい。
      • 基盤面で色々やらないと行けない。
      • まずはバージョン管理から
      • 大きい変化→なだからかな変化へ。
  • TDDスキルのノウハウ蓄積・共有について。
    • 伝達にはやはりペアプログラミングが効果的。
    • ただし、ペアプロ中の会話や気付きは揮発してしまいがちである。
      • 設計の決定について、どうやって溜めていくか。
        • なぜ、どうしてこうなったのか。
        • 人は忘れる生き物である。
        • コードに書かれたもの、Wikiに書かれたものを資産として残していく。
        • ローカルなものは資産ではない。
    • どう動いているかはコードを見れば分かる。
    • なぜそうなったか、はコミットログに書く。
    • きのこ本 No.17：ソースに書けない事をコミットログに書く。

プログラマが知るべき97のこと

プログラマが知るべき97のこと

      • コードは人のものではなくチームのものである
      • ソフト依存のバグがある
        • コードにコメントとして書く。
        • コミットコメント見ても分からない。
  • GitやSvnのコマンドには差分、履歴、コメントを一覧して見る事の出来るものもある。(例:git blame)
    • 変更履歴を全てコメント化して残す…ツールを使えていない例の悪例。全て履歴を残さないと行けない、という恐怖から来る行動。
    • 現代ではツールを上手く使う事で対応。


…と、この辺りで時間となり座談会終了。今回は流れ的には

という様相を呈していましたが、個人的には良かったのでは、と思います。さながら『塾生がマスターセンセイである@t_wadaさんに教えを乞うている』というテイストで非常に有意義な話が聞けましたし、各人がリファクタリングに関するコメントを発した上で和田さんとの質疑応答を展開出来ていたので、皆さんの満足度はかなり高かったのではないでしょうか。自分も座談会最後の『TDDのノウハウ蓄積・共有について』の質問を投げかけ、上記のようなコメントを頂けたのでとても満足出来ました。

休憩：スイーツタイム

今回のスイーツはこちら。岡山から取り寄せた『どら焼き』です。一見すると小振りで可愛らしいサイズのどら焼きですが…

横から見ると結構な厚さ(高さ)！食べるときに注意しないとアンコがあふれてしまいそうな位です。

どら焼き単品ではサイズの感覚が掴めないかなと思いまして、毎度おなじみの『RedBull』と並べて比較してみました(笑)

並べたRedBullは250mm缶です。手元の定規で測ってみたところ高さは約14cm。どらやきを1ポイントとすると大体3ポイント位の高さなのでどら焼き自体の高さは4cmちょいと言ったところでしょうか。アジャイル風な見積もりをしてみました。

ちなみにRedBullとどら焼きの食い合わせは…あまりよろしくなかったです(笑) どら焼き自体はとても美味しかったですよ！2個頂いちゃいました☆


また、休憩中にはアルティネット様の会社内にある関連本がズラリと持ち寄られて来たりも。こういう風に会社が理解があって良書を会社で揃えてくれる所は羨ましいですね〜。良書はえてしてボリュームも大きくなり、値段も高くなりがちですから。

ワールドカフェ開催前に、今回キャンセルで空きが出た事を受けてアルティネット様の社員の方が1名参戦されており、今回が初参戦という事でこのタイミングで自己紹介。

ワールドカフェ

上述のように、今回も座談会では『リファクタリング』に議論が集中した感もあったので、ワールドカフェではそれ以外のテーマで語り合う形になりました。
(お題としては12〜15章(ユニットテスティング/リファクタリング/TDD/CI)の中から1つ選ぶ)という形)

結果がこちら。今回は前回のようなツイート形式では無く、各チーム30秒程度での口頭発表でした。(テーマはCI×2、TDD×1でした)



お知らせ等

以上を持ちまして、アジャイルサムライ読書会in湯島道場も終了！と思いきやまだ続きがある模様で…

まず来週には、これまでの5回(第一回 地の巻/第二回 水の巻/第三回 火の巻/第四回 風の巻/第五回 空の巻)に続く第6回のイベントとして『かっぱ巻き』なるものが開催予定。こちらは湯島道場の全5回の振り返り、また9/18に行われる他流試合に向けての湯島道場参加メンバーの交流が主となる模様です。

9/18(日)の他流試合についても、大枠で内容は決まりつつあるようです。オラクル青山センターでの開催なので数多くの参加者が期待出来そうですね。楽しいイベントになりそうです。

また、これは確定では無いのですが湯島道場『2週目』もやるようなやらないような…。内容が気になるところですが、開催が決まれば、そして都合が合えば是非とも参加してみたいところですね。

(追記)前回8/24の話になってしまうのですが、以前TDDBC1.6(2011/07/31開催)の時に誓っていた『きのこ本に和田さんのサインを頂く』というタスクを先週晴れて完了出来ました！これで和田さんのサインは2つ目です☆(^o^) ありがとうございます！


懇親会


この日も懇親会に参加。都合、これまでの全5回全ての読書会＆懇親会に参加した事になってしまいました。(^_^*)

前回のように夏休み期間中では無かったので11時過ぎにはおいとましましたが、今回も楽しいひと時を過ごすことが出来ました。

今回の『アジャイルサムライ』読書会はどの回も内容が濃かったですが、今回第5回の内容も濃かったですね。振り返りつつ情報を展開しつつ書き留めて行ったらあっという間に時間が過ぎてしまいました。今回第5回の内容は一際皆さんの心に刺さるものがあったようで(TLの熱さにそれが見て取れる)、内容についても皆さんと意見のやり取りが出来るとまた盛り上がりそうな気がします。