TDDが失敗する時 - Kazzz's diary
TDD(Test-Driven Development)は良い開発手法だが、以下の場合に合致するシステムの開発では使わない事を薦めている。なぜならば破綻する可能性が極めて高いからだ。 設計が不完全で仕様に抜けがあることが明らかな場合 これは自明だろう。インタフェースさえ決まればテストが書けるTDDでも、抜けてしまった仕様はテストとして書けない。TDDは仕様の変更には強いが、だからといって仕様の抜けにも強いとは言えない。 仕様とソースコードのレビュー時間が取れない場合 レビュー時間が取れない? そんなバカなと思うが、そういうシステムを見ることは結構多い。仕様のレビューやすり合わせは結合テストをしながら行うのが当たり前と考えているような現場ではTDDは上手く回転しない。 既にスケジュールが大幅に遅れている場合 スケジュールがタイトな開発の現場では、一度取り戻せない規模の遅れが出てしまうとその後
私的ITアーキテクト考：3.ITアーキテクトの仕事 (arclamp.jp アークランプ)
先日、デブサミの「ITアーキテクト大解剖」でご一緒させていただくマイクロソフトの萩原さん、建築家の大川さんとミーティング。いろいろと話をしてきました。デブサミでは、ここで書かれていることを中心に話題を広げていきたいと思います。 技術や知識は最低限のこと まず全員が一致したのは「工学的な知識や技術を知っているというのは最低限のこと」である点。同じような知識としては、先人の知恵という意味でパターンや実績・実例をあげることもできます。 建築業界で技術の親分というのは構造エンジニアや現場の大工で、アーキテクトとは明確に分離されています。もちろんアーキテクトが設計図を描くために知識は必要になるので、知っている範囲であればその中で、新しい技術を試すのであれば設計段階からエンジニアに入ってもらうそうです。 一方のIT業界で、アーキテクトとエンジニアに分離は見えていません。これはITの歴史が浅いからでし
Papilio-バグトラッキングシステム-
- Eclipseプラグインで実現するバグトラッキングシステム(BTS) - 特徴 サーバ構築不要。接続している各端末がお互いに同期してデータを共有する。 インストールは簡単。Eclipseにプラグインを追加するだけ。 信頼度成長曲線などの充実したレポート出力機能 Eclipseを採用することで直感的操作が可能なインタフェースを実現。 完全フリー、オープンソース。 完全日本語対応 Eclipseのプラグインとして、多様な機能を搭載したBTSを実現。 従来のBTSと違い、Eclipseプラグインとして使用できるため導入・操作が非常に簡単です。 従来のBTSとの違い 主な機能 動作環境 スクリーンショット ダウンロード インストール・設定 リリース情報 従来のBTSとの違い 主な機能 基本的なBTSの機能 - バグ票の起票〜Closeまでのステータス管理 - 更新履歴の記録・閲覧 - メールに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【テスト文書】誰でもできるWindows手品・メモ帳にてメニューにもCtrl+Vにも触れずに不思議貼り付け!! 【▲→川俣晶の縁側→PCホビイズム】
