みんなのPython勉強会#37で『「テスト駆動開発」を通じてプログラマがコードと向き合う活動を改めて学び直す』のタイトルで講演させていただきました。
i-like-tdd-16d9ce2c2201
みんなのPython勉強会#37で『「テスト駆動開発」を通じてプログラマがコードと向き合う活動を改めて学び直す』のタイトルで講演させていただきました。
希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）
テスト書くのが当たり前、だけど・・・和田：次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
マニアが潰したテスト駆動開発〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （５）
昨年１２月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。
粘土のように設計して外側のフィードバックループを回す 〜 『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （２）
和田：そうですね。 家永：もうちょっと大きめのものをリファクタリングして、下手したらリライトぐらいの勢いのものを、みんなリファクタリングという。 和田：それリファクタリングという言葉の受容のされ方が何か変わってきたというか。 家永：だんだん変わっちゃって。 和田：単なる作り直しをリファクタリングと呼んでいる、それはある。 家永：ちょっと何だかなあという感じ。「えっ！？」と、ドキッとする事があります。 和田：それはありますね。テスト無しで変更するのをリファクタリングと呼んだりとか。 家永：全てテストのないのを、せめて全部とは言わないけど手動の動作確認をしないんだと。 和田：そうなっちゃうとただの書き直しですね。ファウラーのリファクタリングのステップというのは、だいぶ忘れられかけている。スモールステップみたいなやつがスキップされがちなのは、良い面と悪い面があるね。 和田：良い面というのはリファ
燃えろスリーアミーゴス！作れGWT！回せフィードバックループ！〜テスト駆動開発をやめて、なお残すべき習慣とは(6)
実践テスト駆動開発の図1–2を参考にいろいろ追記スリーアミーゴスが協力するシステムで具体的に何をつくったらOKなのか（何を作らなくてもよいのか）は、１人のロールで纏めるのは難しく、スリーアミーゴス（ビジネス、開発者、テスター）の３者の協力が必要です。 ビジネス：対象ドメインに詳しい。ユーザストーリーのWhyに詳しい。ビジネス観点で何がシステム必要で不要かを判断できる。開発者：ユーザストーリー実現の技術的手段のHowに詳しい。問題に対するシンプルな解き方の代案を提示できる。対象ドメインをコードで言語化し、理解を深めることができる。テスター：テストシナリオのパターン出し、特に顧客やユーザに損害を与えるであろう盲点の発見が得意。テストシナリオをリスクベースに評価し順序付けを提示できる。早期に何を作り（何を作らないか）のシステムの理解をすり合わせることで、手待ちや手戻りや抜け漏れや不要な作り込みを
最初からクライマックス！デプロイから始めよう〜テスト駆動開発をやめて、なお残すべき習慣とは(5)
AmazonでSteve Freeman, Nat Pryce, 和智 右桂, 高木 正弘の実践テスト駆動開発 (Object Oriented SELECTION)。アマゾンならポイント還元本が多数。Steve Freeman, Nat… １．プロジェクト開始直後に本番に近い環境にデプロイする”プロジェクト開始直後からデプロイとテストを行うことで、チームはシステム全体をどうやって実際の世界に適合させていくか理解しなければならなくなる。 プロジェクト初期段階に、会議室や机上だけでの何を何故つくるべきかどうやってつくるべきかの判断は、たいてい間違いや抜け漏れが含まれています。大事なことを知らないことすら気付いていないこともあります。ソフトウェア開発において、その間違いや知らないことに手っ取り早く、具体的に気付く方法は、早期に小さくつくってデプロイし動かしてみることです。動かそうとすれば仕事の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
