ソフトウェア開発における将来要件の扱い - 勘と経験と読経
ソフトウェア開発におけるムダ | Ryuzee.com の記事が面白かった。別にアジャイル開発プロセスに限らず、ソフトウェア開発にはいろいろな無駄がある。身近でときどき出てくる種類のムダとして「将来の再利用性などの要件を折り込む」ということがある（「使わない機能」の一種かもしれない）。「技術的負債」の逆バージョンについて。 ソフトウェア開発における将来要件の扱い よくあるのはこういった話。 将来の機能拡張を考慮したシステムを構築するという「要求」がある。 未来の要件変更を考慮した機能設計をすることが要求される。 未来の要件変更を考慮した汎用性が求められる、といった場合もこのパターンか。 機能拡張時のコスト削減のために、将来の再利用を想定したものづくりが要求される。 アーキテクチャレベルで将来の変更を想定したり、そもそも変更しやすい設計を行うことは可能だ。しかし、上記に上げた要求に対しては「
再利用の３の法則 - Strategic Choice
どういうこと？再利用には、２つの「３の法則」があります*1。その１「難易度３倍」再利用可能なコンポーネントを作るのは、単一のプログラムで使うモジュールを開発する場合に比べ、3倍難しい。その２「テスト３種類」再利用可能なコンポーネントは、ライブラリに取り込む前に、3つの異なるプログラムでテストする必要がある。どうして？「難易度３倍」再利用可能なコンポーネントを作るエンジニアは、まず、特定の問題を解決することを念頭に設計します。そのあと、類似のドメインヘ拡張することを考えます。さらに、一般化した問題の処理を考えなければなりません。コンポーネント自体を一般化するだけでなく、コンポーネントのテストも、一般的なケースで実施する必要があります。従って、再利用性の高いコンポーネントを作ろうとすると、複雑性が高くなり、最初から最後まで簡単には行かなくなります。設計段階で、「一般化した問題とは何か？」を考慮
技術的負債 - Wikipedia
技術的負債（英語: technical debt）、設計負債[1]、またはコード負債とは、ソフトウェア開発における概念であり、時間はかかるがより良いアプローチを選択する代わりに、簡単ではあるが限定的な解決策を選択することで生じる、将来的な手直しにかかる暗黙のコストを示すものである[2]。 金銭的な負債と同様[3]に、技術的負債も返済されなければ、「利子」が蓄積され、変更の実施が困難になる。技術的負債を処理しないと、ソフトウェアのエントロピーが増大する。金銭的負債と同様に、技術的負債も必ずしも悪いものではなく、プロジェクトを前進させるために（概念実証として）必要な場合もある。一方で、「技術的負債」というメタファーは、その影響を最小限に抑える傾向があり、その結果、修正するために必要な作業の優先順位付けが不十分になると主張する専門家もいる[4][5]。 コードベース上で変更が開始されると、コード
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
