1. 技術的負債に関するメモ
1.1. 技術的負債とは何ですか?
1992 年、ウォード カニンガムはアジャイル宣言の中で「技術的負債」という概念を初めて提案しました。この概念は主に、意図的または意図せずに誤った、または最適ではない技術的決定を下すことによって蓄積された負債を指します。その後、『リファクタリング』の著者であるマーティン・ファウラーは、カニンガムの比喩に基づいて、次のような「技術的負債の 4 つの象限」を作成しました。
- 無謀/意図的: 「デザインする時間がない」。
- 慎重/意図的: 「今すぐ成果を上げて、後でスピードを追求した結果に対処しなければなりません」。
- 無謀/意図的でない: 「レイヤリングとは何ですか?」
- 用心深い/意図的ではない: 「何をすべきかはもうわかりました」。
1.2. 議論
少し前に、Reddit 上の技術的負債の話題が再びプログラマーの間で広範な議論を引き起こしました。ユーザー spo81rtyOP 氏は、「ほとんどのソフトウェアの実際の寿命はわずか 5 ～ 10 年です。たとえソフトウェアが生き残ったとしても、そのソフトウェアが完全に古い技術スタックから書かれているという事実は、その道を狭めることになります。これがソフトウェア エンジニアの命です。」と述べています。本当の運命。」
同時に、過去 20 年ほどの間に、Perl、Delphi、Fortran、FoxPro、ColdFusion などの多くのプログラミング言語も「人気がなくなった」のです。おそらく、これらの古いプログラミング言語は一部のアプリケーションにまだ存在している可能性がありますが、ほとんどの場合、これらのプログラミング言語をまだ使用している企業は、古いアプリケーションを最新化して廃止する必要があります。これらの時代遅れのプログラミング言語でプログラムを構築すると、これらの言語を使用するプログラマーを見つけるのが難しくなるため、最終的に書き直すことになる可能性があります。
2000 年代初頭、人々は Adobe ColdFusion が最も人気のある製品であると考えていましたが、現在はどうでしょうか? Ruby on Rails は、人気が落ちて使用する開発者を見つけるのに苦労している Adobe ColdFusion の後継となる可能性もあります。かつては Ruby on Rails に固有であった機能が、現在では他の言語でも利用できるようになりました。
プログラミング言語は流行ったり消えたりするもので、開発者は仕事に必要のないスキルを学びたくないとワトソン氏は語った。同時に、開発者は仕事から仕事へと素早く移り、常に履歴書に何か新しい話題を載せたいと考えています。
Watson は、WebAssembly が最終的には今日のフロントエンド開発を超え、まったく新しい世界が進化し続けるだろうと予測しています。
ユーザー Chesterriley は、極端な可能性を想像しました。おそらく将来、人々は 100 年前に書かれたコードを使い続けるでしょう。大きな勝者は、Unix ユーティリティ、TCP/IP コード、またはコンパイラ、ランタイム エンジン、またはインタプリタのようなものかもしれません。Linux や Windows などのオペレーティング システムのコードもあります。人々は、自分が修正したバグが実際には 100 年以上前のものであったことに突然気づくかもしれません。
もちろん、今日の誇大宣伝の影響をあまり受けていないコードもいくつかあります。興味深いことに、この種のコードのほとんどはサーバー側に集中しています。マイクロサービスや Lambda 関数などのサービスの構築方法を「破壊する」強力な力が常に存在しますが、これらの実装の詳細が無視された場合、間違いなくサーバーのメモリ空間で実行されている db+ サービスが依然として存在し、アイドル サイクルが依然として存在することになります。活用されていません。
「今日生まれた新しいプロジェクトが、長期的な保守性の重要性を念頭に置き、基本的な設計前提として考慮することさえ期待しています。結局のところ、古いソフトウェア プロジェクトを保守する能力を持っている人は実際には多くありません。地球の人口は依然として増加していますが、これらの古代のソフトウェアを保守するのに十分なスキルを持つ開発者の数は決して追いつくことができません。」
1.3. 国内の技術者はどう考えていますか?
パーセント CTO の Liu Yijing 氏は、技術的負債を判断する鍵は「何をすべきか」であると考えています。そのプロセスは組織ごと、プロジェクトごと、そして人ごとに異なります。たとえば、次のような側面があります。
- 組織が必要としているのに実行できていないもの: システム、プロセス、規範、共有学習など。
- ビジネスやテクノロジーで必要とされながらも実現できていないもの: 機能、パフォーマンス、セキュリティ、高可用性、拡張、監視、補助ツールなど。
ソフトウェアエンジニアリングのリンクに従って分類すると、技術的負債は、要件分析、ソリューション設計、アーキテクチャ設計（論理アーキテクチャ、機能アーキテクチャ、データアーキテクチャ、展開アーキテクチャ、運用アーキテクチャなど）、コーディング、テスト、リリースなどに分類できます。 。出力の種類に応じて分けると以下のように分けられます。
- 文書カテゴリ: 管理プロセス文書、要件分析文書、設計文書、テストケース文書など。
- コードカテゴリ: コード、スクリプト、仕様など。
- ソフトウェア パッケージ カテゴリ: 製品ソフトウェア パッケージ、依存ソフトウェア、依存リソースなど。
- 環境カテゴリ: 開発環境、テスト環境、起動前環境、本番環境など。
書き換えをするか、保守を継続するかをどのように判断するかというと、「保守を継続することによるメリット」と「書き換えをすることによるメリット」のどちらが大きいかを判断して、保守を続けるか書き換えを続けるかを決める必要があります。以下の側面からの利点を総合的に考慮できます。
- オープンソース: 既存事業の収益を増加させ、新規事業の開発をサポートします。
- 節約: メンテナンス要員と運営費を節約します。
- 組織：人員構成の調整と組織能力の開発。
借金は避けられないものであり、常に「借金を保有する価値」を判断し、価値が著しく低い場合には速やかに対処します。
テンセントの研究開発ディレクター、王輝氏は、人的資源、物的資源、建設時間などのリソースが豊富であれば、最適化できるものはすべて極限まで達成できると述べた。ただし、通常、リソースは豊富ではない、またはリソースが不足しているため、実際のビジネス状況によって異なります。Tencent の一貫したアプローチは、「最初に抵抗し、次に最適化する」です。プロジェクトが本当に最適化が必要な段階に達しているのか、最適化されなければいつダウンしてもおかしくない段階に本当に達しているのか。最初に抵抗する場合は、ビジネスが市場を引き継ぐまで待ちます。ユーザーが勢いを増し、プロジェクトの進行が鈍化した後、いくつかの最適化を再度実行できます。この時点では、高可用性、高パフォーマンス、高同時実行性、などが求められる場合があります。
「プロジェクトのリソースが許せば、多少過剰な最適化やリファクタリングは許容されますし、チームの技術的な熱意を維持するのは良いことです。しかし、リソースが許せない場合は、費やした金額を数えて、技術的負債の妥当性を判断する必要があります。自然、負債をより良く返済する方法、本当に返済する必要があるかどうか、ビジネスの発展に本当に影響を与えるかどうか、ビジネスの優先順位と併せて検討する必要があります。後で返済することもできます。」と王輝は結論づけた。