サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
twop.agile.esm.co.jp
はじめに前回は、テスト自動化のゴール(達成・維持したい状態)についてxUnit Test Patternsを使って解説しました。第二回は、テスト自動化の落とし穴であるテストの不吉な臭い(Test Smells)の一部をご紹介します。テストの自動化に取り組んでいるチームでは、大抵不吉な臭いに出会すので、チームで読書会はオススメです。 不吉な臭いとは?不吉な臭いはもともとは、Kent Beck考案でリファクタリングの本で紹介されました。不吉な臭いは、プロダクションコードや設計に問題にあることに気づくサインで、リファクタリングをするきっかけとなります。 テスト自動化にとりくむ際も、同様にテストコードの現状の問題を察知し、原因を特定し、テストコードのリファクタリングを続けることで、オートメーションで達成や維持したい状態に近づける必要があります。放置した場合は、テスト自動化を続けることがメンテナンス
同僚と技術書典7で頒布します。川鯉さんが編集を取りまとめてくれた本は、『アジャイルコーチからのアドバイス』になります。よろしくお願いします。サークル名は「シン・オブジェクト倶楽部」、配置場所は「き25D」です。 「アジャイルコーチからのアドバイス」の魅力は豪華アジャイルコーチの執筆陣です!!。お忙しいなか、寄稿を了承していただき本当にありがとうございます!!掲載予定順で、短く解説しますね。私見が混ざった解説なので、詳しくはぜひ本を手にとってください。 角 征典:「この分野は素人なのですが」から始めよ新しい分野にチャレンジする際は、素人であることをつつみ隠さず、素人として堂々と周囲に質問することで、新たな知見や協力を得ることが物事を進展させるコツです。 家永 英治 :リファクタリングの練習をしよう市場ニーズに対して俊敏に適応し続けるには、コードの状態を読みやすく、修正しやすく、テストし
同僚と技術書典7で頒布します。私の主担当は、『リファクタリングから始めるチーム開発 はじめの一歩』になります。頒布は初チャレンジです。よろしくお願いします。サークル名は「シン・オブジェクト倶楽部」、配置場所は「き25D」です。 はじめの一歩本の概要紹介1章 リファクタリングとチーム開発 2章 リファクタリング はじめの一歩 3章 テスト駆動開発 はじめの一歩 4章 レガシーコード改善 はじめの一歩 5章 そしてチーム開発へ 付録 リファクタリング習慣の健康診断 本書の想定読者は、リファクタリング、テスト駆動開発、レガシーコード改善に興味関心がある人向けです。2,3,4章は、名著『リファクタリング』『テスト駆動開発』『レガシーコード改善ガイド』のエッセンスをチュートリアル形式で凝縮してさらに凝縮しました。もし、「リファクタリング」「テスト駆動開発」「レガシーコード改善」と名前を聞いたことがあ
アップデート記事は次をご覧ください。 https://www.agile-studio.jp/post/twop-refactor-now 前回までにリファクタリングのチュートリアルの例を示しました。TDDと同様にテストを頻繁に実行しながらステップバイステップで読みやすく変更しやすいコードに変換していくことがリファクタリングの基本です。 今回以降は、2章以降のリファクタリングを参考にサマリーを紹介します。今回は、リファクタリングをいつやるのか?を中心に解説します。リファクタリングの言葉は広まっていますが、マーティンファウラーが提示しているリファクタリングの内容を学び直すことで、新たなな発見があれば幸いです。 改めてリファクタリングとは?書籍によるとリファクタリングの定義は、次になります。 リファクタリング(名詞):外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウ
前回に引き続き、リファクタリングについて解説します。今回は リファクタリングパターン【Split Phase】で、計算ロジックと表示ロジックの分離を行います。分離ができれば、表示ロジックが別フォーマット(例えばHTML)に変わっても変更箇所が明確になって修正しやすくなります。 まずはスタートのGreen確認からグリーンでない状態で、修正してはリファクタリングしているとは呼べません。テスト結果がRedの場合はまずはGreenに戻します。 表示用のファンクションと計算用の分離レポート表示用の計算結果をまとめるファンクション(createReportData)と、結果を表示するためのファンクション(renderPlainText)を用意します。ただし、一気に移動するのではなく、ステップバイステップで移動できるように2つのファンクションを用意しただけです。createReportDataにはほとん
はじめに前回までは、『レガシーコード改善ガイド』を解説していました。今回からはリファクタリングについて解説していきます。1回目は、リファクタリングステップの例を示します。2018年に『Refactoring 2nd』が出ましたが、 本家も1章はサンプルチュートリアルになっています。 今回は、本家に似せたチュートリアルの序盤に相当する、Extract Functionを中心にした構造化のステップを示します。この例を通じてテストを頻繁に実行しながら小さなステップの連続でコードの構造変換を行うリファクタリングの妙技が伝われば幸いです。 リファクタリング前のスタート地点の確認generateReadedReportファンクションがリファクタリング対象です。インプットに2つパラメーター(readedList, recommendList)、アウトプットにテキスト文字列でレポート出力するようになってい
はじめに前回は、『レガシーコード改善ガイド』のキーポイントの1つである、テストしたい対象とテストを妨げる要素の密結合を【切断】し、【接合部】と【許容点】を作って、ユニットテストできるように変換する例を、JavaScriptのサンプルコードを使って解説しました。 今回は『レガシーコード改善ガイド』の全体感を、駆け足で解説します。レガシーコードを向き合う作戦を考えるときの頭出しの参考になれば幸いです。 難しい作業はペアプログラミング ペアでレガシーコードに対峙するレガシーコード改善は基本、難しい作業のため、ソロより【ペアプログラミング】で行うが望ましいです。難しい作業である外科手術は通常ソロでは行わないのと同様の考え方です。 長過ぎるメソッド、巨大クラス、依存関係が絡まった難しいコードを理解し、レガシーコード改善方針を立てて、ユニットテストができる構造へ変換し、テストを追加してリファクタリング
はじめにペアプロを始めてみたものの、熟練者と初心者の間で知識差-スキル差が大きいあまり、ペアのやりとりが噛み合わなかったり熟練者に依存し続けて初心者のままで成長しない、といったことを耳にすることがあります。では、どうすればその差を埋め、コラボレートできるペアプロになっていくのでしょうか?この記事では、指導役となる熟練者側向け中心に知識差-スキル差を埋めることを主目的としたペアプロの実施のコツを解説していきます。 大切にする価値 ペアの間では、基本ルールを守ってコミュニケーションを取ることが大前提です。書籍『Team Geek』で紹介された、HRT原則(1. 謙虚(Humility)、2. 尊敬(Respect)、3. 信頼(Trust))や、Hunter Industries 社の本家のモブの場合は、Kindness, Consideration, Respectの3つを基本ルールが参考に
はじめに前回から『レガシーコード改善ガイド』の解説しています。今回は、『レガシーコード改善ガイド』を理解する際の肝となる「接合部」について、改善のコード例を示しながら解説します。 接合部とは?『レガシーコード改善ガイド』によると、接合部、許容点の定義は次です。 「接合部(seam)とは、その場所を直接編集できなくても、プログラムの振る舞いを変えることができる場所である」 「どの接合部にも許容点(enabling point)を持つ。許容点では、どの振る舞いを使うかを決定できる」 接合部にはいくつか種類があり、オブジェクト指向言語を使っている場合はオブジェクト接合部がとても役立ちます。プロジェクトで採用しているのがオブジェクト指向中心ではなく、ファンクション中心の場合も接合部と許容点を作って、ユニットテストできるコードに変換することが可能です。 下記は JavaScript における接合部の
前回までは、『レガシーソフトウェア改善ガイド』を参考に、改善のゴールのすり合わせや設計改善の進む道のヒントとなるリファクタリング、リアーキテクティング、ビック・リライトを紹介しました。今回からは、『レガシーコード改善ガイド』を取り上げていきます。 テストがないコードはレガシーコード『レガシーコード改善ガイド』は、コードや設計の腐敗が始まったコードへの向き合い方を著者の経験をもとに整理されています。「テストがないコードはレガシーコード」の力強い言葉とても有名です。 テストコードがなければ、修正の際に期待通り動作するか否かや今までの振る舞いが壊れたのか否かの判断が難しくなります。日々の小さなリファクタリング活動も怖くて実施困難です。ユニットテストを考慮した設計となっていないためユニットテスストの実施が難しくなりがちです。その結果、機能修正や障害解析に苦痛と共に多くの時間を割く羽目になります。
Many teams miss opportunities for refactoring by not realizing the different ways refactoring can fit into their… 『レガシーソフトウェア改善ガイド』では、リファクタリングを実施する際に、安全なステップで行う規律の大切さを先に言及しています。規律あるリファクタリングは、例えば次です。 依存関係をグラフ化して修正の影響範囲を理解するカバレッジ結果を参考に安全にリファクタリングできるコードか否かの判断する書籍『リファクタリング』のように小さなリファクタリングの連続のステップで理想のコードに近づく活動をこまめに継続する(長時間に動作しない状態は避ける)テストを使って外部振る舞いが壊れていないことを頻繁に確認する壊れたらすぐに戻れるようにバージョン管理システムを活用するIDEのリファクタ
今回は、前回に引き続き『レガシーソフトウェア改善ガイド』を参考にしながら、チームでのレガシー改善のゴールのすり合わせについて解説します。 現状データを集め可視化する レガシーの現状を指差し確認できるように可視化する改善活動を基本としているScrumの3本柱、「透明性−検査−適応」が知られていますが、レガシーソフトウェアが引き起こす問題を解消する改善活動も透明性に取り組むは良いアプローチです。現状をだれでも指さして確認できるように可視化することで、現状を的確に把握し解くべき課題に合意して行動しやすくします。 例えば、静的コード解析や性能テストや監視モニタリングやテスト実施結果や作業にかかった時間やチケット情報などを集めて可視化します。静的コード解析の診断結果によっては、コーディング規約を守っていないことだけなく、バグを混入しているモジュールに気付くこともあるでしょう。ツールによって重複コード
ソフトウェア開発のコンテキストでレガシーと言えば、マイケル・C・フェザーズの『レガシーコード改善ガイド』が有名です。が、連載ではまず、もう一つ日本語訳されている、『レガシーソフトウェア改善ガイド』を参考にしながら、技術的負債との付き合い方を解説していきます。 『レガシーソフトウェア改善ガイド』は、『レガシーコード改善ガイド』と同様に、プログラマが今眼の前にしているソフトウェアに触れることの対する恐れやフラストレーションを乗り越えることを主テーマにしつつも、何にフォーカスしてレガシーソフトウェアの改善を行えばよいのか、どのように行えばよいのかについて順を追って解説しています。 レガシーとは?先にソフトウェア開発におけるレガシーの意味について揃えておきましょう。『レガシーコード改善ガイド』の「テストがないコードはレガシーコード」の言葉は有名です。が、レガシーソフトウェア改善ガイドの著者において
製品づくりの大きなリスクの1つは、顧客に売れないユーザに使われない製品をつくってしまうリスクが知られています。(このテーマは別途) 売れない製品リスクを乗り越え要望に応え続けコードを修正し続けると、今度は「レガシコード」「不吉な臭い」「泥団子のような密結合の作り」などの「技術的負債」の重みで、修正が困難になってしまう問題が知られています。 内部の質も含めた改善の活動が欠落したスクラムでは、ヘロヘロScurmのダークサイドに陥ってしまいます。 中小レベルの設計判断の場合、ファウラーのリファクタリングレベルの名前の変更、メソッドの抽出<ー>メソッドのインライン化、クラスの抽出<ー>クラスのインライン化等をどちらが良いか選択し続けることになります。ドメインエキスパートの対話を通じて、重要なモデル要素を後から発見するかもしれません。 大レベルの設計判断の場合、モノリシックなつくりで1つのスモールチ
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はテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発3部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。(本で確認してみてね) 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に1回だけパターンを使って
和田卓人氏と家永英治氏本記事は、2017年12月に行われた『テスト駆動開発』翻訳者の和田卓人氏と、本ブログ『時を超えたプログラミングの道』編集長/『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の全6回記事へのリンク集です。 お二人は、10年以上前に、当時はまだ珍しかったアジャイル(エクストリームプログラミング)プロジェクトにおいて、チームとして開発に取り組んだ仲間です。 対談を通じて、当時のプロジェクトの思い出を皮切りに、「1人のエンジニアとして腕を磨き本当にいきいきとお仕事を行えているのか」「プログラミングの技と魅力を次世代に伝承できているのか」そしてその結果としての「健全なビジネスの継続的成長のための健全なコード」という『時を超えたプログラミングの道』のメインテーマについて、存分に語っていただきました。
テスト書くのが当たり前、だけど・・・和田:次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
昨年12月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長/『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。
今回から書籍を数回に分けて辿りTDD再考を試みます。第1回は本の全体像を見てみます。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ(未視感)が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 書籍は3部+付録の構成1〜2部はTDDを体験するチュートリアル1部はJavaで多国通貨の計算、2部はPythonを使ってステップ・バイ・ステップでxUnitに近づいていくお題となっています。もしまだ1部、2部を利用してケント・ベックとペアプロするような感覚でTDDを追体験したことがないのであれば、一度ゆっくりと試してみることを強くお勧めします。1回と言わずプログラミング言語を変えて数回試して下さい。スポーツが練習を繰り返して本番に立つようにプログラミングも練習が欠かせません。TDDの練習の型と
前回は、スクラムでは語られていない「内部の質」について踏み込んで話が弾みました。そして今回は、いよいよ「エンジニアの生き生き」とは何かについて話が進みます。 エンジニアの「生き生き」とは何か?懸田:次の話題ですが、「エンジニアは生き生きしないと」「エンジニアで生き生きって何だよ」というところを少し聞きたいなと思うんですけれども。どうですかね?言い出しっぺの家永さん?(笑) 家永:言い出しっぺ(笑)僕の開発の現場で見たシーンで最初に思い出すのが、これは僕の(会社で)できるエンジニアでワタナベさんという人がいるんですけど、誰かと一緒にステップバイステップでリファクタリングをやってみせるというのをやったんです。その隣の人の感想がすごく印象に残っていて「心が浄化されました。」ということを、すごい笑顔で言っているシーンがあったんですね。それってコードと自分の距離感というか関係性に変化があったというこ
ヘロヘロスクラムを見かける話懸田:さて、次の話題がたぶんテーマの根幹だと思うんですけど、そこらへん少しお願いします。 和田:ブログエントリーで一個ずつタイトル並べたみたいな感じですね。じゃあトピック「スクラムは広まったがコードや設計がダメだとエンジニアは生き生きしないのではないか?」。 家永:これはいわゆるファウラーの所のヘロヘロスクラムとかっていうキーワードですね。 和田:角さんが訳したやつ。 家永:和訳があるので、知られてはいるんだけれども、実際僕がアジャイルコーチというポジションで入ると、期待されるところの最初はまずはプロセス面を見るというところがあって、コードまで見るという機会が逆に離れてしまっている。プロセス部分にもまずフォーカスが当たるんだけれども、実際にもう一歩踏み込んでコードを見てみると、「これ大丈夫か!?」とドキッとする機会が何度もある。例えば、僕は(Ruby on)Ra
時を超えたプログラミングの道時代を超えて受け継がれる、価値あるソフトウェアを生み出す、いきいきとしたプログラマの営みについて情報を発信していきます。
和田:そうですね。 家永:もうちょっと大きめのものをリファクタリングして、下手したらリライトぐらいの勢いのものを、みんなリファクタリングという。 和田:それリファクタリングという言葉の受容のされ方が何か変わってきたというか。 家永:だんだん変わっちゃって。 和田:単なる作り直しをリファクタリングと呼んでいる、それはある。 家永:ちょっと何だかなあという感じ。「えっ!?」と、ドキッとする事があります。 和田:それはありますね。テスト無しで変更するのをリファクタリングと呼んだりとか。 家永:全てテストのないのを、せめて全部とは言わないけど手動の動作確認をしないんだと。 和田:そうなっちゃうとただの書き直しですね。ファウラーのリファクタリングのステップというのは、だいぶ忘れられかけている。スモールステップみたいなやつがスキップされがちなのは、良い面と悪い面があるね。 和田:良い面というのはリファ
(左)和田氏、(右)家永氏はじめに今回から、数回に渡り、昨年12月に行われた『テスト駆動開発』翻訳者の和田卓人氏と『時を超えたプログラミングの道』編集長/『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談記事をお届けします。 お二人は、10年以上前に、当時はまだ珍しかったアジャイル(エクストリームプログラミング)プロジェクトで、同じチームで開発に取り組んだ仲間です。 お二人の対談を通じて、当時のプロジェクトの思い出を皮切りに、「1人のエンジニアとして腕を磨き本当にいきいきとお仕事を行えているのか」「プログラミングの技と魅力を次世代に伝承できているのか」そしてその結果としての「健全なビジネスの継続的成長のための健全なコード」という『時を超えたプログラミングの道』のテーマについて、存分に語っていただきます。 (司会進行/賑やかし:天野勝、懸田
次のページ
このページを最初にブックマークしてみませんか?
『時を超えたプログラミングの道』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く