難易度価格

「技術的負債」という言葉でさえ自分に説明することは私にとって常に困難でした。 誰が、誰が、何のために、どれだけの債務を負っているのかは明確ではありませんでした。 そして、それが借金である場合、それをどのように支払うのか、それは全額を支払うことができますか？ 私にすべきことは可能ですか？



最近、私はYammerのChris Galeによる記事を読みました。この記事では、「複雑さのコスト」という概念を紹介しています。 複雑さの代償は、技術的な義務と複雑なシステムの開発のまったく同じ側面を説明しますが、私の観点からは、より明確になります。



アイデアは非常に単純です-プロジェクトが複雑になるほど、プロジェクトのサポートにより多くの労力が費やされ、プロジェクトを変更するのに費用がかかります。 「複雑さ」を純粋な形で測定することはできませんが、おそらくすべてのエンジニアはこの声明を真実だと考えています。



Chrisは、新しい機能を作成するのにかかる時間は、この機能のコストの最小部分であると彼の記事に書いています。 彼はYammerで1時間でどのようにしたかを例に挙げ、今後5年間で40時間を費やして他のエンジニアにそれが何であり、どのように機能するかを伝えました。 そして、これは、他のエンジニアも時間を費やしていたため、これらの会話が合計で少なくとも80時間かかったことを意味します。



複雑さは2つのタイプに分けることができます。 最初の種類の複雑さは、システムが持っている機能の数です。 2番目のタイプの複雑さは、機能を実装する際の過剰なエンジニアリングです。 また、製品に搭載されている機能が多いほど、サポートと変更のコストは高くなります。 このタイプの複雑さは、何らかの機能を削除するという1つの方法でのみ削減できます。 クリスは、Yammerで新しい機能を追加した後、しばらくそれを監視し、それが使用されず価値をもたらさない場合は削除されると書いています。 さらに、サイト上のすべての機能がどのように使用されるかを測定し、投資する価値があるものと拒否できるものを評価します。



2番目のタイプの複雑さは不必要な複雑さであり、成熟したエンジニアリングアプローチによってのみ処理されます。 「ロシア人の若い技術者だけがこの病気にかかっているのではない」「クール」なことをする代わりに、できるだけ簡単なことをする方法を考える必要があります。 または、プロジェクトで既に使用されているものを単純化します。



たとえば、私のプロジェクトの1つにタスクスケジューラがありましたが、もともとは「高負荷向けにシャープ化」されていました。 マルチスレッドアーキテクチャを使用し、各スレッド内でスレッドを使用しました。 さらに、スケジューラーが実行したタスクをロールバックするためのマルチレベルの手順が設計されました。 しかし、地味な反射は、このスケジューラーが実行するタスクの数が非常に少なく、マルチレベルのロールバックがプロジェクトの作成とサポートを非常に複雑にしていることを示しました。 スケジューラを簡素化するために1週間を費やした後、そのコードも大幅に減少し、はるかに単純になりました。



1日あたりのメッセージ数が数千を超えず、すべてがプロジェクトで既に使用されているデータベースで完全に有効になったときに、別の「高速」メッセージキューの導入からプロジェクトを保護する必要がありました。



コンサルティングし、リレーショナルDBMSを使用したいくつかのプロジェクトでは、MongoDBを廃止し、サポートを大幅に簡素化しました。



マネージャーが「そのようなことをするのにどれくらい時間がかかりますか？」



複雑さがゼロのプロジェクトがないことは明らかであるため、どのプロジェクトでも、複雑さに対して支払う必要があります。 唯一の問題は、プロジェクトで何かを実行できるかどうかです。そのため、プロジェクトの複雑さが軽減され、同じ金額がもたらされます。 これは複雑な管理です。成熟したエンジニアが解決するタスクです。



そして、この記事の冒頭で私が尋ねた質問は、「複雑さのためにいくら払えばいいのでしょうか？」だけに変えることができます。この数字をお金で数えれば、これは「技術的負債」になります。