Agile Studio プロデューサー の木下です。弊社の研修である「アジャイル開発の基礎知識」を動画で一挙 22本、公開しました。アジャイル動画のサイトでご覧になれます（以下のURLをクリック）。...

前回に引き続き、リファクタリングについて解説します。今回は リファクタリングパターン【Split Phase】で、計算ロジックと表示ロジックの分離を行います。分離ができれば、表示ロジックが別フォーマット（例えばHTML）に変わっても変更箇所が明確になって修正しやすくなります。 まずはスタートのGreen確認からグリーンでない状態で、修正してはリファクタリングしているとは呼べません。テスト結果がRedの場合はまずはGreenに戻します。 表示用のファンクションと計算用の分離レポート表示用の計算結果をまとめるファンクション(createReportData)と、結果を表示するためのファンクション(renderPlainText)を用意します。ただし、一気に移動するのではなく、ステップバイステップで移動できるように２つのファンクションを用意しただけです。createReportDataにはほとん

はじめに前回までは、『レガシーコード改善ガイド』を解説していました。今回からはリファクタリングについて解説していきます。１回目は、リファクタリングステップの例を示します。2018年に『Refactoring 2nd』が出ましたが、 本家も１章はサンプルチュートリアルになっています。 今回は、本家に似せたチュートリアルの序盤に相当する、Extract Functionを中心にした構造化のステップを示します。この例を通じてテストを頻繁に実行しながら小さなステップの連続でコードの構造変換を行うリファクタリングの妙技が伝われば幸いです。 リファクタリング前のスタート地点の確認generateReadedReportファンクションがリファクタリング対象です。インプットに２つパラメーター(readedList, recommendList)、アウトプットにテキスト文字列でレポート出力するようになってい

はじめにペアプロを始めてみたものの、熟練者と初心者の間で知識差-スキル差が大きいあまり、ペアのやりとりが噛み合わなかったり熟練者に依存し続けて初心者のままで成長しない、といったことを耳にすることがあります。では、どうすればその差を埋め、コラボレートできるペアプロになっていくのでしょうか？この記事では、指導役となる熟練者側向け中心に知識差-スキル差を埋めることを主目的としたペアプロの実施のコツを解説していきます。 大切にする価値 ペアの間では、基本ルールを守ってコミュニケーションを取ることが大前提です。書籍『Team Geek』で紹介された、HRT原則（1. 謙虚(Humility)、2. 尊敬(Respect)、3. 信頼(Trust)）や、Hunter Industries 社の本家のモブの場合は、Kindness, Consideration, Respectの３つを基本ルールが参考に

はじめに前回から『レガシーコード改善ガイド』の解説しています。今回は、『レガシーコード改善ガイド』を理解する際の肝となる「接合部」について、改善のコード例を示しながら解説します。 接合部とは？『レガシーコード改善ガイド』によると、接合部、許容点の定義は次です。 「接合部(seam)とは、その場所を直接編集できなくても、プログラムの振る舞いを変えることができる場所である」 「どの接合部にも許容点(enabling point)を持つ。許容点では、どの振る舞いを使うかを決定できる」 接合部にはいくつか種類があり、オブジェクト指向言語を使っている場合はオブジェクト接合部がとても役立ちます。プロジェクトで採用しているのがオブジェクト指向中心ではなく、ファンクション中心の場合も接合部と許容点を作って、ユニットテストできるコードに変換することが可能です。 下記は JavaScript における接合部の

前回までは、『レガシーソフトウェア改善ガイド』を参考に、改善のゴールのすり合わせや設計改善の進む道のヒントとなるリファクタリング、リアーキテクティング、ビック・リライトを紹介しました。今回からは、『レガシーコード改善ガイド』を取り上げていきます。 テストがないコードはレガシーコード『レガシーコード改善ガイド』は、コードや設計の腐敗が始まったコードへの向き合い方を著者の経験をもとに整理されています。「テストがないコードはレガシーコード」の力強い言葉とても有名です。 テストコードがなければ、修正の際に期待通り動作するか否かや今までの振る舞いが壊れたのか否かの判断が難しくなります。日々の小さなリファクタリング活動も怖くて実施困難です。ユニットテストを考慮した設計となっていないためユニットテスストの実施が難しくなりがちです。その結果、機能修正や障害解析に苦痛と共に多くの時間を割く羽目になります。

Many teams miss opportunities for refactoring by not realizing the different ways refactoring can fit into their… 『レガシーソフトウェア改善ガイド』では、リファクタリングを実施する際に、安全なステップで行う規律の大切さを先に言及しています。規律あるリファクタリングは、例えば次です。 依存関係をグラフ化して修正の影響範囲を理解するカバレッジ結果を参考に安全にリファクタリングできるコードか否かの判断する書籍『リファクタリング』のように小さなリファクタリングの連続のステップで理想のコードに近づく活動をこまめに継続する（長時間に動作しない状態は避ける）テストを使って外部振る舞いが壊れていないことを頻繁に確認する壊れたらすぐに戻れるようにバージョン管理システムを活用するIDEのリファクタ

今回は、前回に引き続き『レガシーソフトウェア改善ガイド』を参考にしながら、チームでのレガシー改善のゴールのすり合わせについて解説します。 現状データを集め可視化する レガシーの現状を指差し確認できるように可視化する改善活動を基本としているScrumの３本柱、「透明性−検査−適応」が知られていますが、レガシーソフトウェアが引き起こす問題を解消する改善活動も透明性に取り組むは良いアプローチです。現状をだれでも指さして確認できるように可視化することで、現状を的確に把握し解くべき課題に合意して行動しやすくします。 例えば、静的コード解析や性能テストや監視モニタリングやテスト実施結果や作業にかかった時間やチケット情報などを集めて可視化します。静的コード解析の診断結果によっては、コーディング規約を守っていないことだけなく、バグを混入しているモジュールに気付くこともあるでしょう。ツールによって重複コード

ソフトウェア開発のコンテキストでレガシーと言えば、マイケル・C・フェザーズの『レガシーコード改善ガイド』が有名です。が、連載ではまず、もう一つ日本語訳されている、『レガシーソフトウェア改善ガイド』を参考にしながら、技術的負債との付き合い方を解説していきます。 『レガシーソフトウェア改善ガイド』は、『レガシーコード改善ガイド』と同様に、プログラマが今眼の前にしているソフトウェアに触れることの対する恐れやフラストレーションを乗り越えることを主テーマにしつつも、何にフォーカスしてレガシーソフトウェアの改善を行えばよいのか、どのように行えばよいのかについて順を追って解説しています。 レガシーとは？先にソフトウェア開発におけるレガシーの意味について揃えておきましょう。『レガシーコード改善ガイド』の「テストがないコードはレガシーコード」の言葉は有名です。が、レガシーソフトウェア改善ガイドの著者において

製品づくりの大きなリスクの１つは、顧客に売れないユーザに使われない製品をつくってしまうリスクが知られています。（このテーマは別途） 売れない製品リスクを乗り越え要望に応え続けコードを修正し続けると、今度は「レガシコード」「不吉な臭い」「泥団子のような密結合の作り」などの「技術的負債」の重みで、修正が困難になってしまう問題が知られています。 内部の質も含めた改善の活動が欠落したスクラムでは、ヘロヘロScurmのダークサイドに陥ってしまいます。 中小レベルの設計判断の場合、ファウラーのリファクタリングレベルの名前の変更、メソッドの抽出＜ー＞メソッドのインライン化、クラスの抽出＜ー＞クラスのインライン化等をどちらが良いか選択し続けることになります。ドメインエキスパートの対話を通じて、重要なモデル要素を後から発見するかもしれません。 大レベルの設計判断の場合、モノリシックなつくりで１つのスモールチ

Agile Japan 2018 高知サテライトで「バランス型ループのフィードバックを中心にソフトウェア開発を再考しましょう」のタイトルで講演させていただきました。ワインバーグ先生の視座の一部を借りて、資料を作りながら改めて自分もソフトウェア開発の活動が一体何なのか学び直していました。 ソフトウェア開発においては、People(私たち)とマシンの暖かい関係性のなかで、ExpectedとActual を明らかにし、ステップバイステップで 舵取りし続け、誰かにとっての嬉しさを生み出し続けるが、バランス型のフィードバックのキーアクティビティになります。詳しくは資料を御覧ください。

『テスト駆動開発をやめて、なお残すべき習慣とは』連載が完結しましたので、ここまでの記事を今一度まとめてみました。是非連載を通して読んで、TDDという名前やプラクティスに囚われない、残すべき習慣、やるべき振る舞いを今一度学び、確認してみてください。 見落とした回があるかもしれません。是非チェックしてください！！

みんなのPython勉強会#37で『「テスト駆動開発」を通じて​プログラマが​コードと向き合う活動を​改めて学び直す』のタイトルで講演させていただきました。

https://www.flickr.com/photos/visualpunch/7477997812「問題対私たち」のチームになっていくには？チーム立ち上げのころは相互参加−相互貢献−相互尊重−相互信頼がまだチーム内で醸成されていない状態であることが普通です。このタイミングでは、チームメンバーは些細な困りごとを安心して話すこともできず、仮に本丸の取り組むべき問題をチームで見つけても、チームメンバーが協力して前向きに取り組むことできないことがあります。チーム内の人と人とのコラボレーションの質が低い状態の場合は、ふりかえりの場が、無関心、他責、厄介事の押し付け、一方的な説得、ディベート（言論で打ち負かす）の言動を取りがちで、機能不全に陥ります。 では、どうやって、本丸の重要なテーマの問題にも「問題対私たち」で取り組める相互信頼のあるCool&Sexyなチームになっていくのでしょうか？ KP

前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっても、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。 付録AにはTDDの狙いが含まれる著者のケント・ベック氏は、そもそも、プログラミング中にどんなフラストレーションを感じて、テストファーストやTDDを編み出し解消を試みたのでしょうか？ 彼が解きたかった問題の説明は、書籍の三部で記載されたパターンの問題記述や25章の「テスト」に出てくる因果ループ図、付録Aに記載された因果ループ図が参考になります。 新訳『テスト駆動開発』が出版されたときは、和田さん書き下ろしの付録Cに注目が集まりましたが、実は付録Aの因果ループ図も「著者が取り組みたかったテーマがいったい何だったのか？」を的確に把握する上で欠かせません。 今回は、付録Aに記載された因果ループ図を参考に、「ケント・ベックが解消し

前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 忘れないで、テスト駆動開発にもデザインパターンの話が出てくるよTDDはテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発３部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。（本で確認してみてね） 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に１回だけパターンを使って

テスト書くのが当たり前、だけど・・・和田：次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし

昨年１２月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。

今回から書籍を数回に分けて辿りTDD再考を試みます。第1回は本の全体像を見てみます。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 書籍は３部＋付録の構成１〜２部はTDDを体験するチュートリアル１部はJavaで多国通貨の計算、２部はPythonを使ってステップ・バイ・ステップでxUnitに近づいていくお題となっています。もしまだ１部、２部を利用してケント・ベックとペアプロするような感覚でTDDを追体験したことがないのであれば、一度ゆっくりと試してみることを強くお勧めします。１回と言わずプログラミング言語を変えて数回試して下さい。スポーツが練習を繰り返して本番に立つようにプログラミングも練習が欠かせません。TDDの練習の型と

前回は、スクラムでは語られていない「内部の質」について踏み込んで話が弾みました。そして今回は、いよいよ「エンジニアの生き生き」とは何かについて話が進みます。 エンジニアの「生き生き」とは何か？懸田：次の話題ですが、「エンジニアは生き生きしないと」「エンジニアで生き生きって何だよ」というところを少し聞きたいなと思うんですけれども。どうですかね？言い出しっぺの家永さん？（笑） 家永：言い出しっぺ（笑）僕の開発の現場で見たシーンで最初に思い出すのが、これは僕の（会社で）できるエンジニアでワタナベさんという人がいるんですけど、誰かと一緒にステップバイステップでリファクタリングをやってみせるというのをやったんです。その隣の人の感想がすごく印象に残っていて「心が浄化されました。」ということを、すごい笑顔で言っているシーンがあったんですね。それってコードと自分の距離感というか関係性に変化があったというこ