コードを保守可能にする特徴または機能は何ですか？
私はこれが何であるかを知っていたと思っていましたが、本当にそれについて考え始めた... "保守可能" ...コードを正確に保守可能にするものは何ですか？
私にとって、コードが保守可能でなければならないということは、将来コードに何らかの変更を加えるためにコードを再検討することが期待できることを意味します。コードは、どのような状態であっても常に「変更可能」です。つまり、コードは簡単に変更できる必要があるということですか。ただし、コードがスケーラブル/拡張可能である場合、無料で自動的に「変更」（適応）されるため、コードを直接変更する必要はありません。
また、コーディング標準と互換的に使用されるコードの保守性も確認しました。一貫したコーディングパターンまたはスタイルを使用して、コードを実際に保守しやすくしていますか？より読みやすく、一貫性がありますか？確かに、しかしこれはどのように保守性を改善するのでしょうか？
これについて考えようとすればするほど、混乱するようになります。誰か適切な説明がありますか？
保守性は、保守可能であるかどうかにかかわらず、バイナリプロパティではありません。それは連続体です。大まかに言えば、保守性は、開発者が変更を加えるのにかかる時間と、変更が何かを壊すリスクに反比例します。読みやすさ、結合、または一貫性を向上させることはすべて、特定の変更を行うのに時間がかからないため、保守性に貢献します。保守性は、1時間かかるはずだと思っていたものが1週間かかるような場合に、その不在によって認識しやすくなります。
コーディング標準は、コードベースが一貫している必要があるという点で役立ちます。そのため、複数のコーディングスタイルを含むコードベースよりも扱いが簡単です。理解しやすいものは保守が簡単です。
私にとって、保守可能なコードとは、実際には本のように読み、十分に文書化されているコードを意味します。
保守可能なコードは、ユニット（および必要に応じて機能/統合）でテストされているため、ノックオン効果をもたらす変更が行われた場合、コードがチェックインされる前に、迅速かつ早期にキャッチされます。
私にとって、保守可能なコードは、プログラミング人口の0.1％が認識している風変わりな言語機能を利用していません（つまり、簡単な例：一時変数の代わりに XOR swap を使用しています）作者が「かっこいい」と思っているからです。
保守可能なコードは、健全なアーキテクチャの原則も実装しています： [〜＃〜] dry [〜＃〜] 、 [〜＃〜] solid [〜＃〜] など。適切な問題を解決するための既知の設計パターンとアルゴリズム。
コードの保守性は、コーディングの公理、経験則、原則などをすべて適用したときに実現される相乗効果です。科学というよりアートです。これらすべてを適切な量で調理した限り、コードベースは保守可能です。コードを変更できる（またはできない）からといって、コードを保守できない（はい/いいえ、オン/オフ、またはその両方）。
ただし、保守性の酸性テストはコードを変更しようとしています。コードが抵抗する、または抵抗しない範囲で、コードとの相互作用によりコードの保守性が決まります。
保守性には「能力」があります。これに限定されるわけではありません
- 読みやすさ
- わかりやすさ
- 変更可能性
- テスト容易性
- 信頼性
- 他？
これらの能力をどのようにして達成しますか？
これらのソフトウェアの原則とガイドラインをすべて適用することで、これまでに、またはおそらく聞いたこともありません。例えば：
- 良いコメント
- 説明変数、メソッド、クラス名
- メソッドをページの長さ以下に制限する
- 凝集力を最大化し、結合を最小化
- 同じものをカプセル化する
- 変化するものをカプセル化する
- コードのレイアウト/フォーマットのガイドラインが一貫して適用されている
- 1つの入口点のみ、および1つの出口点のみ。
- ...そして、もっと、もっと、もっと...
優れた保守性を実現するには、コードのすべてのレベルで常にそれらすべてを考慮し、それらを（ "the"ではなく）適切な組み合わせで適用する必要があります。さらに、これを十分に強調することはできませんが、単独で最適に（またはおそらく非常にうまく）機能する原理はありません。
ダマスカスへの道を探す
数年前、二つのことが一緒になりました。文字通りメンテナンス不可能なプログラムのセットと、Steve McConnellによるCode Completeの私の発見。この本は、失敗よりも悪いコードをすべて書き換える聖書であり、コードの「前と後」の比較は啓示に他なりませんでした。
ダマスカスへの道を見つけます。ターゲットとなるリッチな環境です。
読み取りコード完了
この本が基本的なソフトウェア開発の原則を学ぶのにどれだけ優れているかを誇張することはできません。
保守可能なコードは、高い凝集性と低い結合を示すコードです。凝集度は、コードがどのように関連し、読みやすく、理解できるかを示す尺度です。結合は関連するコードの測定です。低結合とは、Aが何かを行う方法を変更しても、Aを使用するBに影響を与えないことを意味します。二。
保守性はそれ自体がコードを変更する容易さの尺度であり、保守性が高いほど、変更する時間が短くなります。コーディング標準は、高い保守性を実現する方法であり、以前の経験の結果として開発されたものであり、普遍的ではなく、開発者の好みに依存しています。
いくつか質問してください。
（または、一部の人が言うように、-いくつかのシナリオを通じて一緒に実行しましょう）
あなたが書いたものを理解するのはどれほど難しいでしょうか？
- 先週？
- 先月？
- 昨年？
- 今から27年？
あなたが書いたものを理解するのはどれほど難しいですか同僚の場合？
不幸な出来事では、チームの全員が利用できなくなりますが、フィックスは数時間でトラフになる必要があり、仕事に利用できる唯一の人は夏のインターンです、彼が成功する可能性はどれくらいですか？
その後：
- コードのランダムなチャンクにセキュリティ修正を適用するのはどれほど難しいでしょうか？
- 要件の論理的な誤解を変えることはどれほど難しいでしょうか？
- ユーザビリティ/ UX /化粧品の問題を処理することはどれほど難しいでしょうか？
- 絶えず変化する法的状況に適応するのはどれほど難しいでしょうか？
- いくつかの新しい市場性のある機能をプッシュするのはどれほど難しいでしょうか？
- 全体を別のアーキテクチャに移植するのはどれほど難しいでしょうか。
そして、すべてのベスト：
- ベヒモス全体を同様のニーズを持つクライアントの新しい一連の要件に適応させるのはどれほど難しいでしょうか？
これは多かれ少なかれメンテナンスについてです。後者は、おそらくアプリケーションを製品に変換することについてですが、それは時間とともに発生するかなり典型的なニーズです。
"ベストプラクティス"：
- コメント
- ドキュメンテーション
- 図
- 一貫したインデント
- コーディングパターン
すべては、コードをより長く存続させるためのものです。
特に、コーディングパターンは、コードを次第に発見せず、ますます多くの"そうすることでメンテナンスを支援します。 。ここ周辺 "。
もちろん、これらは注意して使用する必要があり、そのためにコピーペースト/乱用しないでください。
これはレゴではありません。インスピレーションの源です。
誰かのパターンの使用と保守性の利点を関連付けることができない場合は、それらを正しく使用していない可能性があります。ただし、さまざまなソリューションを比較し、メンテナンスの場合に応答時間を短縮する方法として、理論的には適切であることを確認してください。
McCabe複雑度メトリックス について誰も言及していないことに驚いています。高度な複雑性メトリックは、保守性に関しては実際のコード臭です。ルーチンが「複雑」であることが必要な場合がありますが、通常は、保守が非常に難しいコードを示します。
別の見方をすると、すべてのコードは保守可能です。差別化要因は、コードを維持するために必要な労力と、特定の状態でコードが表す技術的負債の量に要約されます。
適切に因数分解されたコードは維持するためにほとんど労力を必要としません、そしてあなたがそれを修正する必要があるときそれは大きなリソース費を課しません。読むのが難しいコード、それだけでは「賢い」、因数分解が不十分、またはコードが書かれた意図に適さないコード。これらは、維持または回避策により高いコストがかかるタイプのコードです。 cost：benefitにより、直接保守を回避する方が都合がよい場合。貧弱なコードの維持に失敗すると、技術的負債が大幅に増加し、最終的にコードが維持するにはコストがかかりすぎると見なされる可能性が高くなります。
コードを保守可能または保守不可能としてラベル付けすると、会社に重大な損失が発生する可能性があり、何年もの間、開発者が悪臭を放つようにプロジェクトを失敗させるという汚名が生じる可能性があります。管理が非常に困難になる前に問題に努力を集中できるようにすることで、言語を変更してより努力を重視し、保守性の認識を少なくすることは、長期的にはより有用になります。
保守性の意味を理解するために支援を必要とする他の開発者と協力する場合、私は彼らに尋ねます。 ？」これが人々の視点をどのように変えることができるかに驚くでしょう。
コードの維持とは、そのコードを取得し、バグを修正したり機能を追加するためにコードを変更することを意味します
保守可能なコードにより、このプロセスが簡単になります
コードを保守可能にすることは、理解しやすくすること（説明的な変数名、コメント、およびドキュメントがここで役立ちます）、変更を簡単にすること（パターンはこれを容易にすることができますが、実際のニーズによって異なります）
保守性を次のように定義しました。アプリケーションソフトウェアの機能を変更するために必要な労力の尺度。 「努力」の尺度には、時間、リソース、専門知識を含める必要があります。
一般に、ソフトウェア開発マネージャーは、ソフトウェアの作成に適用される「努力」のこの定義に精通しています。 「機能の変更」という用語は、機能強化とバグ修正の両方に適用されます。また、保守可能なコードは活用されるように設計されているとも言えます。
保守可能なソフトウェアを作成するには、ある程度の努力が必要です。それが価値があることについて、私は最近この件についてブログを始めました。
メンテナンス可能です-ある程度-主観的です。ただし、ライターの自我を念頭に置いて書かれたコードではなく、ある時点で誰かがこのコードを再検討し、現在未定義の理由で変更する必要がある可能性が高いという認識をもって書かれています。何年もずっと静的なコードベースはほとんどありません。
ある人が保守可能であると考えるものは、いくつかの点で他の人の見解とは非常に異なる場合がありますが、それに含める必要があると思ういくつかの品質は次のとおりです。
- 将来の不注意のための隠された罠はありません
- 論理と根拠を文書化する必要があります
- 文書化されたローカル規格に準拠する必要があります
ここでは、ドキュメンテーションと解説をテーマに、時々議論を行っています。
送金とロジックの追跡が容易なコードは、元の設計の考慮事項に注意が必要なため、ほとんどの場合、必要に応じて簡単に更新できます（ただし、適切に文書化されることはありません）。