レガシーコード改善ガイド : 小野和俊のブログ
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
TDDBCでの教えを胸に、巨大なC#レガシーコードと戦ってみた - hachiNote
目的 業務で現在、とても厄介なC#コードと戦っています。途方に暮れかけていましたが、TDDBC札幌で教えていただいたことから突破口が見えてきました。感謝の気持ちを表しつつ、ちょっとした現状メモです（それにしてはすごく長くてすみません）。 正確には「戦ってみた」じゃなくて、「戦い始めた」ですね。 敵のデータ どんなアプリケーションか C#で書かれた（一部C++もあるが）Windowsフォームアプリケーション。ドライバ的なところからビューアまで、かなり巨大。 とりあえず今自分が見ているところはビューアの改造とかのわりと表層的な部分。C#のみ Visual Studio 2008 Professional Edtionで開発 コードの状態 コードの質が悪すぎる。今までみたコードの中で最もひどい コピペコード多すぎ。とにかくところかまわずがんがんコピペ状態。 メソッド長過ぎ。クラスがでかすぎ。Cじ
既存システムでTDDするのが難しい理由 - くろまほうさいきょうでんせつ
TDDしたい、CIしたいと思ってもなかなか導入できない。何でだろう？ PHP製WebアプリケーションでのTDDを学び始めた現時点の気持ちまとめ。 Seleniumを使うような高いレイヤーのテスト どんなテストを書けばいいのかわからない 例えばDBから商品情報取ってページ生成する場合。 商品カテゴリごとに異なる趣きのページを作るのでそれぞれにviewのテストを書いたとする 各ページ内の商品詳細URLにパラメータが追加されることになった URL生成は共通のモデルで行っている 修正は一ヶ所で簡単なもの だったとしてもviewのテストはそうは行かない。 先に用意したテストケースを全部書き直さなきゃならない。 小さな変更にかかるコストが大きくなる 単純に時間がかかるというより めんどくさくなる → どうせやらなくなる という思い。 コントローラーとか中間くらいの層のテスト viewよりは下、ユニット
レガシーコードをライブで扱う際のポイント試案
twitter で TDDBC Hokuriku (2010) のレガシーコード改善を Coding Dojo で行った際の Ruby チームは比較的うまくいってたけど、あれって○○な流れだっけ的な話をしているうちに気になってることをまとめておこうと思い立ったので、できるだけ書き出してみる。 何かのきっかけになれば嬉しい。 素材（レガシーコード）のポイントまず動くこと触ったことがあること1ある程度でいいので機能別に書かれていること オブジェクト指向であるとなお良い（使える技が増える）小規模であること ただし完全に単機能だと余地が少ないのでテストを足しにくい外部 API 依存しまくりの場合は単なるレガシーコード改善とはまた別なテクニックの習得に繋がってよいかも自動実行できるテストがないこと :-)1 については「えっ」て思うかもしれないけど、放置してるものは依存ライブラリの関係や、そもそも動
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
