保守性は、最新のソフトウェア開発の最も貴重な資産です 。 保守性は、主に新しい開発者が重要な変更を加える前にプロジェクトを掘り下げるのにかかる時間で測定できます。 時間がかかるほど、メンテナンスのレベルは低くなります。 一部のプロジェクトでは、この時間は無限に近いため、これらのプロジェクトには実質的に同伴者がいません。 ソフトウェア製品を伴わない7つの大罪についてお話したいと思います。
アンチパターン
残念ながら、使用しているプログラミング言語は柔軟性が高すぎます。 許可が多すぎて禁止が少なすぎます。 たとえば、Javaでは、アプリケーション全体のコードを数百のメソッドを持つ1つのクラスに配置することを禁止していません。 技術的には、アプリケーションがコンパイルされて起動します。 しかし、これはよく知られているアンチパターンの神のオブジェクトです。
したがって、 アンチパターンは、明らかに間違っているようにアプリケーションを設計するための技術的に実行可能な方法です。 各プログラミング言語には、かなり多数のアンチパターンがあります。 あなたのプロジェクトでのそれらの存在は、生物の腫瘍に似ています。 いったん成長し始め、それを止めることはすでに非常に困難です。 最終的に、生物は死にます。 最終的に、プロジェクトは同伴者がいないため、書き直す必要があります。
いくつかのアンチパターンを作成すると、腫瘍のようにその数が増えるだけです。
これは主にオブジェクト指向言語（Java、C ++、Ruby、Python）に当てはまります。これは、主に手続き型言語（C、Fortran、COBOL）から多くのものを継承したためです。 それが、OOP開発者が手続き型および命令型のスタイルで考える傾向がある理由です。 ごめんなさい
ところで、 よく知られているアンチパターンの既存のリストに加えて、私はこれらのいくつかの点を自分から追加したいと思います 。これは悪い開発アプローチだと思います。
ここでの私の実践的なアドバイスは、読んで学ぶことです。 おそらくこれらの本はあなたを助けるでしょう。 コードの品質については常に懐疑的であり、「正常に機能する」ときにリラックスしないでください。 がんと同様に、診断が早ければ早いほど、生存の可能性が高くなります。
追跡できない変更
コミットの履歴を見ると、各変更について、 何が変更されたのか 、 誰がこれらの変更を行ったのか 、 なぜこれらの変更が行われたのかを伝えることができるはずです。 さらに、これら3つの質問に答えるのにかかる時間は数秒で測定する必要があります。 ほとんどのプロジェクトはそうではありません。 実用的な提案を次に示します。
常にチケットを使用します 。 プロジェクトやチームがどんなに小さくても、独身であっても、解決しなければならない問題ごとにチケット（GitHubの問題）を作成します。 チケットの問題を簡単に説明してください。 後で考えるためにチケットシステムを使用します。これにより、後で「少数のコミット」が何であるかが明確になります。
チケットとコミットをリンクします。 もちろん、すべてのコミットにはメッセージを添付する必要があります。 サイレントコミットは汚い行為であり、その理由については説明しません。 しかし、メッセージだけでは十分ではありません。 各メッセージは、作業中のチケット番号で始まる必要があります。 GitHub（これを使用していると確信しています）は、チケットとコミットを自動的にリンクし、変更の追跡を改善します。
何も削除しないでください 。 Gitを使用すると、プッシュフォースを実行できます。これにより、サーバー上に存在していたブランチ全体が上書きされます。 これは、開発履歴を破壊する方法のほんの一例です。 多くの場合、GitHubのディスカッションに関するコメントを削除して、チケットがより「きれい」に見えるようにしました。 これは単に間違っています。 何も削除しないでください。 どんなにひどい（または）い）と思っても、あなたの話を残してください。
複雑なリリース
各ソフトウェアは、エンドユーザーに配信する前にパッケージ化する必要があります。 Javaライブラリの場合は、* .jarファイルにパッケージ化し、何らかのリポジトリでリリースする必要があります。 これがWebアプリケーションである場合、何らかのプラットフォームなどにデプロイする必要があります。 プロジェクトの規模に関係なく、テスト（テスト）、パッケージ（パッケージ）、およびデプロイ（デプロイ）を行う標準的な手順が常に存在する必要があります。
理想的な解決策は、これらの手順を、1行のコマンドで起動できるレベルに自動化することです。
./release.sh
または
mvn deploy
ほとんどのプロジェクトはこれから遠いです。 リリースプロセスには常に少しの魔法が伴います。この処理の責任者（DevOpとも呼ばれます）は、こことここでいくつかのボタンをクリックし、どこかにログインし、いくつかのメトリックをチェックする必要があります。 このような複雑なリリースプロセスは、依然としてソフトウェア開発業界全体の典型的な罪です。
実用的なアドバイスは1つだけです：これを自動化します。 これにはrultor.comを使用しますが、好きなツールを使用できます。 手順全体が完全に自動化されており、コマンドラインを使用して実行できることが重要です。
自発的静的解析
静的分析は、コードの見栄えを良くするものであり、したがって、より良く機能します。 ただし、これはチーム全体が静的アナライザーによって指示されたルールに従っている場合にのみ発生します。 これについては、Javaコード品質の厳密な制御で書きました。 Javaプロジェクトにはqulice.comを使用し、Rubyプロジェクトにはrubocopを使用しますが、これ以外にも各言語には多くのオプションがあります。
任意のアナライザーを使用できますが、必須にします！ 静的アナライザーが関係する多くのプロジェクトでは、開発者は美しいレポートを作成し、以前と同様にコードを作成し続けます。 このような「任意の」アプローチは、プロジェクトに利益をもたらしません。 さらに、それは品質の幻想を作成します。
静的コード分析は、生産パイプラインで不可欠なステップであると言っています。 静的アナライザーが規則違反を示した場合は、アセンブリを実行しないでください。
不明なテストカバレッジ
簡単に言えば、 テストカバレッジとは、単体テストまたは統合テストによってテストされるコードの割合です。 カバレッジのパーセンテージが高いほど、テスト中により多くのコードが実行されます。 もちろん、カバレッジの割合が大きいほど良いです。
ただし、多くの開発者はテスト範囲の割合を知らないだけです。 彼らはこのメトリックを測定しません。 彼らにはテストがあるかもしれませんが、どれほど深くコードに侵入し、どのくらいのコードがテストでカバーされていないかを誰も知りません。 この状況は、測定可能なカバレッジの低い割合よりもはるかに悪いです。
カバレッジの高い割合は、高品質の保証ではありません。 これは明らかです。 ただし、カバレッジの不明な割合は、メンテナンスの問題の明らかな兆候です。 新しい開発者がプロジェクトに参加するとき、彼はいくつかの変更を行い、テストがこれにどのように反応するかを見ることができるはずです。 理想的には、テストカバレッジの割合は、静的解析の場合と同じ方法で測定する必要があります。値が所定のしきい値（通常約80％）を下回った場合、アセンブリは合格しません。
無限の開発
「無限」とは、ステージ（マイルストーン）とリリースのない開発を意味します。 どのソフトウェアを作成するかは関係ありません。定期的にバージョンを割り当て、リリースする必要があります。 明確なリリース履歴のないプロジェクトは、伴わない混乱です。
かなりの程度まで、保守性はコードを読むことであなたを理解できるときです。
ソースコードとそのコミットとリリースの履歴を見ると、著者の意図が何であったか、1年前にプロジェクトに何が起こったのか、彼が今どこに行っているのか、彼の開発計画は何なのかなどを確認する必要があります これらの情報はすべてソースコードに含める必要があり、最も重要なのはGit履歴に含める必要があります。
GitタグとGitHubリリースノートは、すべての情報を提供する2つの強力なツールです。 それらを最大限に活用してください。 また、製品の各バイナリバージョンがすぐにダウンロードできることを忘れないでください。 製品が現在バージョン3.4であっても、今すぐバージョン0.1.3をダウンロードしてテストできるようにしたいと思います。
文書化されていないインターフェース
ソフトウェアの各部分には、それを使用するための独自のインターフェースがあります。 これがRuby gemである場合、エンドユーザーとして使用したいクラスとメソッドがあるはずです。 これがWebアプリケーションである場合、エンドユーザーが表示して使用するWebページがあるはずです。 各ソフトウェア製品にはインターフェースがあり、注意深く文書化する必要があります。
上記のすべてと同様に、これは保守性にも適用されます。 プロジェクトの新しいプログラマーとして、私はすぐにそのインターフェースの研究を始めます。 私は彼が何をしているかを理解し、彼自身でそれを使ってみなければなりません。
ここでは、開発者向けではなく、ユーザー向けのドキュメントについて説明しています。 理論的には、ソフトウェア内のドキュメントに反対です。 この点で、私はアジャイルマニフェストを完全にサポートしています-実用的なソフトウェア製品は詳細なドキュメントよりもはるかに重要です。 ただし、これは、開発者向けではなく、エンドユーザー向けの「外部」ドキュメントには適用されません。
そのため、エンドユーザーとソフトウェア製品との相互作用を明確に文書化する必要があります。
製品がライブラリの場合、そのエンドユーザー（それを使用するプログラマー）はそれを開発せず、「ブラックボックス」として使用します。
これらは、当社の受賞コンテストでオープンソースプロジェクトを評価するために使用される基準です。