保守性は、開発中のソフトウェア製品の最も重要な価値です。 保守性は、新しい請負業者が製品を大幅に変更し始める前に調査するために必要な作業時間で測定されます。 時間がかかるほど、保守性が低下します。 一部のプロジェクトでは、この時間が無限になりがちです。これは、製品がサポートや変更にまったく適していないことを意味します。 サポートされていない製品の作成につながる致命的なエラーが7つあると考えています。 ここにあります。
アンチパターン
残念ながら、現代のプログラミング言語はすべて柔軟性が高すぎます。 許可が多すぎて禁止が少なすぎます。
たとえば、Javaは、5000種類のメソッドを使用して、アプリケーション全体を1つの「クラス」に配置することに反対しません。 技術的には、アプリケーションはコンパイルおよび実行されますが、これはDivine Objectと呼ばれる有名なアンチパターンです。
したがって、 アンチパターンは技術的に受け入れられる開発方法であり、よく知られた誤りです。 すべての言語には、このようなアンチパターンがたくさんあります。 製品中のそれらの存在は、生体内の腫瘍の存在に似ています。 成長し始めたら、停止することはできません。 生物全体が最終的に死にます。 ソフトウェア製品全体が修復不能になり、書き換える必要があります。
アンチパターンを1つ作成すると、すぐにそれらのパターンが増え、この「腫瘍」は成長しているだけです。
このステートメントは、
プロジェクトについては常に懐疑的であることを心がけ、「うまくいく」ならリラックスしないでください。 問題を診断するのが早ければ早いほど、簡単に解決できます。
追跡できない変更
ソフトウェア製品を使用する場合は、いつ変更されたのか、誰が変更したのか、なぜ変更したのかをいつでも説明できる必要があります。 さらに、これらの質問に対する回答を得るのに必要な時間は数秒で測定する必要があります。 ほとんどのプロジェクトではそうではありません。 実用的な推奨事項を次に示します。 
常にチケットを使用します。 プロジェクトやプロジェクトを担当するチームがどれだけ小さいかは関係ありません。たとえ素晴らしい隔離で作業している場合でも、問題が発生した場合は常にチケットを使用してください。 問題の本質を簡単に説明し、仮定を修正します。 問題に関連する情報の一時ストレージとして
コミットのチケットを参照してください 。 すべてのコミットにメッセージを添付する必要があることを教える必要はありません。 コミットの送信は厄介なことです。 ただし、単に投稿するだけでは十分ではありません。 各メッセージは、作業中のチケット番号で始まる必要があります。 GitHubなどの多くの
何も削除しないでください。
アドホックリリース
エンドユーザーに配信する前に、各ソフトウェア製品をパッケージ化する必要があります。 Javaライブラリの場合は、.jarファイルで囲み、
理想的な解決策は、この手順を自動化して、コマンドラインから1つのコマンドで実行できるようにすることです。
多くのプロジェクトはこれから遠いです。 リリースのプロセスは、担当者（DevOpとも呼ばれます）が特定のボタンをクリックし、どこかにログインし、どこかにログインし、特定のインジケーターをチェックする
アドバイスは1つしかありません。プロセスを自動化することです。
ボランティア静的分析
静的分析は、コードを「組み合わせる」ものです。 外部的に改善することで、最高の仕事を提供します。 ただし、これは、チーム全体が静的コードアナライザーによって指示されたルールに従う必要がある場合にのみ発生します。
必ずコードアナライザーを使用してください。 コードアナライザーを使用するほとんどのプロジェクトでは、開発者はそれに基づいて美しいレポートを作成し、以前と同じようにさらにコードを書き続けます。 静的分析に対するこのような「ボランティア」アプローチは、ソフトウェアプロジェクトを尊重しません。 さらに、それは単に良質の幻想を作り出します。
静的分析は製品開発パイプラインの必須ステップである必要があり、そのルールは無視しないでください。
不明なテストカバレッジ
テストカバレッジは、ソフトウェアが統合テストに合格した程度です。 カバレッジが大きいほど、テスト中により多くのコードが実行されました。 明らかに、高いカバレッジは良いことです。
ただし、多くの開発者はカバレッジが何であるかを知りません。彼らは単にこの指標を測定しません。 おそらく彼らは
もちろん、高いカバレッジは高品質を保証するものではありません。 しかし、未知のカバレッジは、製品の機能的信頼性に関する問題の明確な指標です。 プロジェクトが新しい開発者の手に渡ると、彼または彼女は変更を加えて、これがカバレッジにどのように影響するかを確認できるはずです。 理想的には、テストカバレッジは静的解析と同じ方法でチェックする必要があります。そうしないと、カバレッジが特定のレベル（通常80％）を下回るとビルドが失敗します。
継続的な開発
ここでいう継続とは、時間枠やリリースのない開発を指します。 作成するソフトウェアの種類に関係なく、頻繁にリリースおよび変更する必要があります。 明確なリリース履歴のないプロジェクトは、単にサポートされていないソフトウェアの混乱です。 これはすべて、製品サポートの可能性は、たとえば、コードを読むことであなたを理解できるかどうかだからです。
ソースコードとそのリリースの履歴を見ると、誰もが、たとえば1年前の開発者の意図、現在何が起こっているのか、将来の見通し
GitHubなど、
文書化されていないインターフェース
各ソフトウェアには、使用することになっている独自のインターフェイスがあります。
上記のすべてと同様に、この事実は製品をサポートする能力を指します。 新しいプログラマーはインターフェースからプロジェクトの研究を開始し、誰もがこのインターフェースまたはそのインターフェースの目的と使用方法を理解する必要があります。
開発者向けではなく、ユーザー向けのドキュメントについて話します。 一般に、ソフトウェア内のドキュメントに反対します。動作中のソフトウェアは、ソフトウェアのドキュメントよりもはるかに優れています。 ただし、これは、ユーザーによる使用を目的とした「外部」ドキュメントには適用されません。
ソフトウェアとのエンドユーザーの相互作用は、必ず文書化する必要があります。 プログラムがライブラリの場合、そのエンドユーザーは製品を開発するのではなく、単に「ブラックボックス」として使用する開発者です。
これらの基準はすべて、オープンソースプロジェクトに使用されます。