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

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

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

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

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

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

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