これは、前の記事「
いかに大きなオフィスが減少するか 」の実例です
非効率の実例を共有したいと思います。 若い開発者および/または大規模オフィスで働いたことがない人にとっては、非現実的に見えるかもしれませんが、それは本当です。
目的：既存のシステムの機能を拡張する。 システムは巨大で古くなっています。 数百万行のコード、多くのハード、数十年の寿命。
拡張の本質：システムはタイプAおよびBの材料を処理できます。タイプCを追加する必要があります。
当然、これは分析と見積もりを必要とする困難なタスクです。すべての人件費はいくらですか？ 理解するには評価が必要です：経済的な実行可能性はありますか？
リーダーやアーキテクトを含む多くの開発チームがあります。 そして、彼らはすべて彼らの成績を提供する必要があります。
ツールを使用すると、このコードが記述されているシステム内の場所を簡単に見つけることができます。
typedef enum { OBJECT_A, OBJECT_B } object_types; switch(object){ case OBJECT_A: printf("This is object A"); case OBJECT_B: printf("This is object B"); default: raise_error("Unknown object!!!"); break;
多くの場合、このスイッチは単に報告するだけで、オブジェクトのタイプに関連する機能はありません。
つまり この特定の場合、Cを追加する問題を解決するには、enumを展開して1行追加するだけです。
case OBJECT_C：printf（ "これはオブジェクトCです"）;
ここで注意が必要なのは、この変更を行うのにどれくらい時間がかかるかということです。
- あなたがあなたのホームプロジェクトの開発者なら、数秒ですか？
- セミフォーマルグループの開発者の場合：もう少し...チェックアウト/レビュー/チェックイン/テスト-1〜2時間ですか？
- あなたが大規模なオフィスの開発者である場合：チェックアウトを開始する前であっても、変更の必要性を正当化するいくつかのドキュメントを準備し、テストが実行され結果がOKであることを証明する必要があります。
そして、これらの文書は「チェック/承認済み」のスタンプを取得する必要があります（他の人は時間を費やす必要があります）。 このため、このようなわずかな変更でも1日未満しかかかりません。 物理的にはできません。 また、ビジネスに従事している大規模なオフィス内には「一般的な改善」のためのリソースがほとんどないため、チームが機能変更に20％を追加できる「紳士協定」があります。
オフィスが稼働し始めたばかりのときは、工数が労力の見積もりに使用されます。 老朽化として-マンデイズ。 後で-数週間。 詳細は不明になり、人々は単に自分の仕事に「それを把握する時間ですが、それは何についてですか？！」
例に戻りましょう。一般に、この変更を行うグループのアーキテクトと話し合った後、0.5週間で合意しました。 1行追加する2.5日（および関連するすべての簿記/管理を完了する）。
すでにここでは、すべてが大きなモンスターの中にどれほど悪いかが明らかになります。
しかし、それだけではありません。PLがケースに参加した後、彼は控え目に「詳細」に進むことなく「アップ」と報告しました-10週間。 そして最悪のことは、上記の人々が議論していないことです。
10週間-これは、トピックの質問に対する正しい答えです:(
興味深い：良いKPIを知っている人はいますか？ コードの量とそれを実装するのにかかる時間によって、何かをすでに解決すべきでしょうか？