技術的負債がプロジェクトに組み込まれる方法は (少なくとも) 2 つあります。1つ目は、意識的な決定によるものです。一部の問題は、事前に取り組む価値がないため、意識的に技術的負債として蓄積することが許可されています。2つ目は、無知によるものです。プロジェクトに取り組んでいる人々は、技術的負債を負っていることを知らないか、認識していません。この質問は2番目を扱います。プロジェクトに取り入れた技術的負債は、無視するのは些細なことですが (「知っていれば...」)、プロジェクトに組み込まれると、劇的にコストが高くなりますか?
11 に答える
9
セキュリティの問題を完全に無視します。
クロスサイト スクリプティングはその一例です。alert('hello there!')管理インターフェイスにポップアップが表示されるまでは無害と見なされます (運が良ければ、スクリプトは、管理者がアクセスできるすべてのデータをサイレント モードでコピーしたり、顧客にマルウェアを提供したりすることもできます)。
そして、昨日修正された 500 個のテンプレートが必要です。急いで修正すると、データが二重にエスケープされ、すべての脆弱性がプラグインされるわけではありません。
于 2008-11-21T20:25:47.193 に答える
7
ローカル タイムゾーンでデータベースに日付を格納します。ある時点で、アプリケーションが別のタイムゾーンに移行され、問題が発生します。日付が混在してしまうと、それらを解くことはできません. それらをUTCで保存するだけです。
于 2008-11-21T20:37:26.360 に答える
5
単体テスト -- 途中でテストを書き損ねると、取り戻すのが難しい莫大な負債が発生すると思います。私は TDD のファンですが、コードを実装する前にテストを作成するか、実装した後にテストを作成するかはあまり気にしません... テストとコードの同期を維持している限りは。
于 2008-11-21T20:53:04.970 に答える
5
この一例は、Unicode をサポートしないモードでデータベースを実行することです。データベースで Unicode 文字列をサポートすることを余儀なくされるまでは、正しく機能します。データベースによっては、移行パスは簡単ではありません。
たとえば、SQL Server の行の最大長はバイト単位で固定されているため、列を Unicode 文字列 (NCHAR、NVARCHAR など) に変換すると、既にあるデータを保持するのに十分なスペースがテーブルにない場合があります。ここで、移行コードで切り捨てを決定するか、テーブル レイアウトを完全に変更する必要があります。いずれにせよ、すべての Unicode 文字列から始めるよりもはるかに多くの作業が必要です。
于 2008-11-21T20:10:40.860 に答える
4
JavaScriptフレームワークを使用してWebプロジェクトを開始せず、すでに利用可能なものを手動で実装します。手書きの JavaScript を維持するのが面倒になり、最終的にすべてを切り取ってフレームワークでやり直すことになりました。
于 2008-11-21T20:09:07.197 に答える
2
YAGNIと「私はこれで何度もやけどを負った」のバランスをとろうとして、私はこれに本当に苦労しています
すべてのアプリケーションでレビューする項目のリスト:
- ローカリゼーション:
- タイムゾーンが重要になることはありますか? はいの場合、日付/時刻を UTC で保持します。
- メッセージ/テキストはローカライズされますか? はいの場合、メッセージを外部化します。
- プラットフォームの独立性? 簡単に移植できる実装を選択してください。
技術的負債が発生する可能性のあるその他の領域には、次のものがあります。
- ブラックホール データ収集: すべてが入り、何も出ません。(古いデータのアーカイブ/削除の長期的な計画はありません)
- アプリケーションの存続期間にわたって MVC または階層を明確に分離しておくことができない - たとえば、あまりにも多くのロジックがビューに忍び込み、モバイル デバイスまたは Web サービス用のインターフェイスを追加するコストがはるかに高くなります。
きっと他にもいるだろうな…
于 2008-11-21T20:34:48.860 に答える
2
スケーラビリティ - 特にデータ駆動型のビジネス アプリケーション。すべてが正常に動作しているように見えるところを何度も見てきましたが、UAT 環境が最終的に実稼働に近づくデータベース テーブル サイズで立ち上がると、物事は左右に落ち始めます。データベースが基本的にメモリ内のすべての行を保持している場合、オンライン画面またはバッチ プログラムを実行するのは簡単です。
于 2008-11-21T20:41:10.067 に答える
1
時期尚早の最適化は諸悪の根源であるという決まり文句がありますが、これはマイクロ最適化にも当てはまります。ただし、パフォーマンスが明らかに重要な領域で設計レベルでパフォーマンスを完全に無視することは、悪い考えになる可能性があります。
于 2008-11-22T03:47:57.363 に答える
1
以前の会社では、必要のないものに COM を使用し、強制していました。
C++ コードベースを持つ別の会社は、STL を許可しませんでした。(なんてこと?!)
私が参加していた別のプロジェクトでは、コレクションのためだけに MFC を使用していました。UI は関与していませんでした。それは悪かった。
もちろん、これらの決定の影響は大きくありませんでした。2 つのケースでは、理由もなく哀れな MS テクノロジに依存していました。もう 1 つのケースでは、ジェネリックとコレクションのより悪い実装を使用することを余儀なくされました。
私はこれらを「負債」と分類しています。前もってばかげた決定を下したために、後でプロジェクトの決定とトレードオフを行わなければならなかったからです。ほとんどの場合、欠点を回避する必要がありました。
于 2008-11-21T20:12:36.660 に答える
1
誰もが同意するわけではありませんが、技術的負債の最大の原因は、あらゆる種類のアプリケーションのインターフェイスから始まり、スタック内で作業を進めることだと思います。TDD と DDD を組み合わせて実装することで、プロジェクトの目標から逸脱する可能性が少なくなることを学びました。これは、インターフェイスがアイシングになってコア機能を開発およびテストできるためです。
確かに、それ自体は技術的負債ではありませんが、トップダウンの開発は、よく考えられていない決定を招きやすいオープンな入り口であることがわかりました。 "。また、誰もがそれに同意したり、同じように感じたりするわけではないことを理解しています. チームのダイナミクスとスキルも、この方程式の一部です。
于 2008-11-21T20:22:15.923 に答える
0
まとまりのあるデザインを前面に出さないと、それにつながりがちです。時間をかけて頻繁にリファクタリングを行えば、ある程度は克服できますが、ほとんどの人は、変化する要件に適合しない全体的な設計を非難し続けます。これは、あなたが探しているより一般的な答えかもしれませんが、技術的負債のより一般的な原因の 1 つになる傾向があります。
于 2008-11-21T20:11:18.923 に答える