『テスト駆動開発をやめて、なお残すべき習慣とは』連載が完結しましたので、ここまでの記事を今一度まとめてみました。是非連載を通して読んで、TDDという名前やプラクティスに囚われない、残すべき習慣、やるべき振る舞いを今一度学び、確認してみてください。 見落とした回があるかもしれません。是非チェックしてください!!
技術詳細は外側へ寄せるポイントは、中心となる対象ドメインは何か?中心から排除したい要素は何か?を考慮して区分けすることです。中心のドメインから排除したい項目の代表例が、データベースアクセスや外部Webシステムやメッセージングといった詳細の技術要素です。ドメイン駆動設計の設計判断を取り入れている場合は、オブジェクトへのアクセスするためのRepositoryのインタフェースのみを中心ドメインに入れ込み、Repositoryの実装(特定のデータベース種類やSQLなど実装詳細)は外側に追いやります。同様に、インタフェースのみを中心にいれてメッセージングや他のWebシステムのアクセス等の実装の詳細は外部に追いやります。 うまく区分けできれば、中央に残った純粋なビジネスについてのルールや状態遷移についてをユニットテストやリファクタリングを継続することができます。リファクタリングによる設計改善を継続する
テスト書くのが当たり前、だけど・・・和田:次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
チームでプログラミングをする際、幾つかのスタイルが存在します。どの場面でどのスタイルを使うかについて経験を元にご紹介します。 https://commons.wikimedia.org/wiki/File:Pair_programming_1.jpg一人が黙々とプログラミングするソロのスタイル、ソロでプログラミングしつつも「(WIP)プルリクエスト」のオンライン上「コードの共同所有」で集団で洗練させていくスタイル、2人が同じタスクを同じディスプレイを共有し対話しながら難しい問題を解いていく「ペアプログラミング」スタイル、複数人がホワイトボードと巨大なディスプレイに集まって寄ってたかって、議論しながら開発する「モブプログラミング」スタイル、などがプログラミングスタイルとしてよく知られています。 しかし、実際の開発の現場では、「ソロプログラミング」「プルリクエスト」「コードの共同所有」「ペアプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く