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

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

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

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

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

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

ヘロヘロスクラムを見かける話懸田：さて、次の話題がたぶんテーマの根幹だと思うんですけど、そこらへん少しお願いします。 和田：ブログエントリーで一個ずつタイトル並べたみたいな感じですね。じゃあトピック「スクラムは広まったがコードや設計がダメだとエンジニアは生き生きしないのではないか？」。 家永：これはいわゆるファウラーの所のヘロヘロスクラムとかっていうキーワードですね。 和田：角さんが訳したやつ。 家永：和訳があるので、知られてはいるんだけれども、実際僕がアジャイルコーチというポジションで入ると、期待されるところの最初はまずはプロセス面を見るというところがあって、コードまで見るという機会が逆に離れてしまっている。プロセス部分にもまずフォーカスが当たるんだけれども、実際にもう一歩踏み込んでコードを見てみると、「これ大丈夫か！？」とドキッとする機会が何度もある。例えば、僕は（Ruby on）Ra

和田：そうですね。 家永：もうちょっと大きめのものをリファクタリングして、下手したらリライトぐらいの勢いのものを、みんなリファクタリングという。 和田：それリファクタリングという言葉の受容のされ方が何か変わってきたというか。 家永：だんだん変わっちゃって。 和田：単なる作り直しをリファクタリングと呼んでいる、それはある。 家永：ちょっと何だかなあという感じ。「えっ！？」と、ドキッとする事があります。 和田：それはありますね。テスト無しで変更するのをリファクタリングと呼んだりとか。 家永：全てテストのないのを、せめて全部とは言わないけど手動の動作確認をしないんだと。 和田：そうなっちゃうとただの書き直しですね。ファウラーのリファクタリングのステップというのは、だいぶ忘れられかけている。スモールステップみたいなやつがスキップされがちなのは、良い面と悪い面があるね。 和田：良い面というのはリファ

はじめに前回は、外側のテストループについて何を作ればよいかの探求について解説しました。今回は、実際に「どう作ればよいか」について、コードや設計の内側の秩序の探求について解説します。 TDDの肝は、動作するきれいなコードを目標に、テスト書いて、 実装して、学んで、リファクタリングして… を小さく繰り返し、内なるコードや設計の秩序化するステップを踏み続けることにあります。では、「動作するきれいなコード」と呼ばれる目指すべき場所は何を頼りに向かえば良いのでしょうか？ プログラミングにはコードや設計の秩序化を図るための定石が幾つか知られています。例えば、UNIXの設計判断（例：一つのプログラムには一つのことをうまくやらせる）、メタファ、名前重要、DRY原則、SOLID原則、KISSの法則、コマンドクエリの分離原則、契約による設計、オブジェクト指向のイディオム、関数型のイディオム、各種の言語やフレー

http://dic.nicovideo.jp/oekaki/351821.pngを改変はじめに DHHの”TDD is Dead. Long live testing”の記事で、「モックを使った短時間でのユニットテストはフィードバックが早く常に良いことだ、ユニットテストから導かれる設計は常に良いことだ」というドグマ的な態度は、Railsアプリのコンテキストでは、過度に複雑な構造を入れ、費用対効果が低く修正に弱い脆いテストを大量に作ってしまう。それよりも「UIからDBまで含めて機能性を担保しつづけているかを確認できるテストに比重を置くべき」と過激に指摘したのは有名です。

技術詳細は外側へ寄せるポイントは、中心となる対象ドメインは何か？中心から排除したい要素は何か？を考慮して区分けすることです。中心のドメインから排除したい項目の代表例が、データベースアクセスや外部Webシステムやメッセージングといった詳細の技術要素です。ドメイン駆動設計の設計判断を取り入れている場合は、オブジェクトへのアクセスするためのRepositoryのインタフェースのみを中心ドメインに入れ込み、Repositoryの実装（特定のデータベース種類やSQLなど実装詳細）は外側に追いやります。同様に、インタフェースのみを中心にいれてメッセージングや他のWebシステムのアクセス等の実装の詳細は外部に追いやります。 うまく区分けできれば、中央に残った純粋なビジネスについてのルールや状態遷移についてをユニットテストやリファクタリングを継続することができます。リファクタリングによる設計改善を継続する

http://studiototoro.com/musukarakka-471より改変前回、スタブ・モックの使いどころの再考について触れました。そのなかで、ユニットテストのみに頼るのは、盲点が生まれるという点を指摘しました。「群盲象を評す」という寓話があります。各々の盲目の人が象の一部を触って象を語るだけでは部分でしかありませんし、盲点も消えません。 象の部分を統合して初めて全体を語れるように、一つの視点では盲点ができてしまいますが、複数の視点があればそれを防ぐことができます。 今回は、アジャイルテストの４象限を使って、テスト観点の全体像をお伝えし、次回では多重のフィードバックループについて盲点を少なくする仕組みについて解説します。 テスト駆動開発のスタイルをやめたとしても、自分たちが作り続けているプロダクトが期待通り動き続け、プロダクトがユーザや市場によりフィットしていくようにするには、

前回、テストの４象限を紹介しました。今回からフィードバックについては、複数に分けて解説します。1回目は、フィードバックの基本のキから解説します。次回に実戦テスト駆動を参考に多重のフィードバックを解説する予定です。 フィードバックのおさらい”フィードバック”という言葉は、意味が多義的に使われており、誤解を生じやすいです。Wikipediaのフィードバックを下記に引用します。 フィードバック（feedback）とは、もともと「帰還」と訳され、ある系の出力（結果）を入力（原因）側に戻す操作のこと。古くは調速機（ガバナ）の仕組み[1]が、意識的な利用は1927年のw:Harold Stephen Blackによる負帰還増幅回路の発明に始まり、サイバネティックスによって広められた。https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A3%E3%83%BC%E3