maintenance - 保守可能なコードを書く

Question

保守可能なコード (言語に依存しない) を作成するための最も重要な要因は何ですか?

score 62 · Accepted Answer

Write it for other people to read. This means a combination of good names, good comments, and simple statements.

Once upon a time memory was scarce and cycles times were slow. programmers were encouraged to write complex single lines of code that did many things. Today memory is plentiful and cycle times are fast. You should write 5 lines of simple code people can follow instead of one line they cannot understand.

Good comments don't have to be long, but they must be helpful.

Also be consistent. Do not change styles in your code. For example don't change naming styles from one section to the next.

score 32 · Accepted Answer

関心の分離 (各メソッドが 1 つのことを行う) - これによりスパゲッティコードが停止します。

編集: (Ash のコメントに応えて) 保守性の鍵は、コードが何をしているか、タスクを達成するためにどのように変更を加えるかをすばやく把握できることです。

各タスクが専用のメソッドによって処理されるようにコードを分離すると、これが簡単になります。

たとえば、ロボットのソフトウェアで肘を曲げる方法を変更したい場合、BendElbow という名前のメソッドを使用すると、変更が必要な場所を簡単に変更できます。

score 28 · Accepted Answer

自動化された単体テスト。

既存の機能をいつ壊すかを知らせる自動テストでコードをカバーしている場合は、リファクタリングによってコードの設計をゆっくりと変更できます。自動化されたテストにより、コード変更のリスクが軽減されます。

score 12 · Accepted Answer

12

良い抽象化

于 2008-10-02T15:01:17.143 に答える

score 11 · Accepted Answer

単体テストは当然のことです。コードを最初から単体テストすると、変更を加えるたびにコードの有効性を検証するために実行できるテストスイートが得られます。

また、単体テストを使用してコードを記述している場合、メソッドはテストしやすいため、小さくなる傾向があります。同様に、メソッドを単一のタスクにすることを奨励する必要があります。これも、その方法でテストする方が簡単だからです。

score 9 · Accepted Answer

9

優れた先行設計。貧弱なデザインを救うことはできません。

于 2008-10-02T15:02:45.470 に答える

score 8 · Accepted Answer

作成したばかりのソフトウェアのリリース後 1 ～ 2 年間、第 1 レベルまたは第 2 レベルのサポートを受けることができます。

私を信じてください、私は自分でそこにいました。数年後に自分のコードを保守または拡張しなければならないかもしれないという「恐れ」は、保守性を向上させるための大きな動機となります。

score 6 · Accepted Answer

6

良いメソッド名

于 2008-10-02T15:01:43.087 に答える

score 6 · Accepted Answer

コンピュータが聴衆であると考えてコードを書く傾向があります。

厳密に言えば、コードが機能する必要があるため、これは真実です。しかし、人間の聴衆を念頭に置いて書くと、その考え方だけで、より読みやすいコードを作成するのに役立ちます。

これによってコードが遅くなることが心配な場合は、ほとんどのプログラムは、ほとんどすべての時間をコードの非常に小さな部分で処理していることに注意してください。読みやすくするために書き始めてから、プロファイラーを使用して、最適化する適切なセクションを特定します。

score 5 · Accepted Answer

このようなことはしないでください。笑いをくれた Roedy Green に感謝します。

score 5 · Accepted Answer

上記で指摘したように、「最も重要な要因」は 1 つではなく、いくつかの要因の組み合わせです。

さて、これらのルールのほとんどは、「コードを書いて後で読む」に要約できます。
または、面白いが良いアドバイスを言い換えると、「どこに住んでいるかを知っている殺人マニアが保守する必要があるかのように、コードを記述してください。」...

score 5 · Accepted Answer

Read Code Complete-変数の命名から非常に大きなものまで、これに関するすべてをカバーしており、すべて必要です。なんてことはありません。

私のアプローチは現在、有益な変数名と最小限の変数スコープを使用して、実行する必要があるジョブを実行するコードを作成することです (コードが実行する必要がある可能性のある将来のすべてのジョブではありません)。可能な限り補足文書。これにより、変数名とメソッド名が以前よりも少し冗長になることがありますが (これを使用すると、デバッグ出力が非常に包括的になります)、はるかに理解しやすくなります。

保守性は、通常、他の点でも堅実な実践の結果です。適切な DRY 方法でコードを記述している場合は、問題を見つけやすくなります。強力な一連のテストを行っている場合は、保守の変更が進行しているかどうかを確認できます。何でも壊す。

最終的には、思慮深く、将来のために書くことが問題です-コードは一度だけ書かれ、その後はすべてメンテナンスです...

score 3 · Accepted Answer

最も重要な要素はDRYだと思います。glenatron 他の要因の中で彼の答えにすでに言及していますが、それが最も重要なものだと思います.

score 3 · Accepted Answer

3

継続的なリファクタリング

于 2008-10-02T15:01:51.447 に答える

score 3 · Accepted Answer

I don't think there is a single factor you can focus on. If there is I think it would have to be good judgement. Even well documented, easy to read code can be difficult to maintain if a developer used poor judgement during the design phase. No matter how good the documentation and unit test are, bad design of a production application can be almost impossible to fix.

You could also take a look at something like The Guide to Unmaintainable Code for ideas of what not to do. Informative and funny!

http://mindprod.com/jgloss/unmain.html

I have actually worked at companies that "standardized" on some of the things mentioned in there. You would think most of that stuff is just common sense, but you might be surprised.

score 3 · Accepted Answer

仮定を作成したら記録します - 2 日後にはこれらの仮定を当然のことと見なすようになりますが、コードを保守する次の人は必ずしも同じ仮定を行うとは限らず、なぜ自分がそうしたことをしたのか疑問に思うでしょう...
人々のためのコード- コンピューターはあなたが指示したことを何でも実行します。人があなたのコードを理解できるようにコードを書いてください。

score 3 · Accepted Answer

プログラミングはパフォーマンスです。聴衆が誰であるかを決して忘れてはなりません。「あなたのコードを維持することになる人が、あなたがどこに住んでいるかを知っている暴力的なサイコパスであるかのようにコードを書いてください。」

score 2 · Accepted Answer

2

良いコメント。

于 2008-10-02T15:00:40.827 に答える

score 2 · Accepted Answer

2

Consistency.

于 2008-10-02T15:09:16.797 に答える

score 2 · Accepted Answer

間違いなく、他の人が読むように設計されたコードを書くことです。これには、ゴルフ、謎の構文、および何かを意味する思慮深い変数名を避けることが含まれます。コードが十分にきれいであれば、コメントを書くことを完全に避けることができます、IMO。\

[OO が追加されている言語ではなく、OO が組み込まれている言語を選択することも役立ちます]

score 2 · Accepted Answer

私が見ているように、保守可能なコードを作成する際の基本的なルールは、コードが非常に理解しやすいものであることです。これは思ったほど簡単ではなく、ここで説明した他のテクニックをすべて使用する必要があります。他の開発者があなたのコードをどのように見ているか、また自分のコードとはどのように異なっているかを知る必要があるため、ある程度の共感が必要です。それを理解する良い方法は、数年前に書いたコードに戻って見ることです。

さて、理論的には、非常に理解しやすく、意図したタスクを正確に実行するが、いかなる方法でも変更するのが難しいコードを書くことは可能であると思います. ただし、そのようなコードは見たことがありません。

score 2 · Accepted Answer

長くなってしまいましたが、私には答えがあります。コメントしすぎないでください。これはばかげているように聞こえるかもしれませんが、単純なことを説明するコメントが多すぎると、コードが乱雑になる可能性があります。良いコメントは奇跡を起こすことができますが、無意味なコメントは正反対です。

score 2 · Accepted Answer

余白たっぷり。- 高密度コードは理解しにくい。空行なしで 6 行以上ある場合、そのグループはまとまった思考/アイデア/操作ではない可能性があります。

適切な変数名 - 説明的ですが、簡潔です。巨大な変数名は、小さなものと同じくらい悪いです。

score 1 · Accepted Answer

私は、人々がコードの成長に合わせてコードを刈り込み、整形するのが好きです。非常に多くの場合、まともなアーキテクチャの元の背骨がぶら下がっています。

score 1 · Accepted Answer

私にとって、テスト可能なコードを書くこと（Googleのテストブログをチェックしてください）は、より保守しやすいコードです

score 1 · Accepted Answer

私はすでにマットの答え「良い抽象化」に投票しましたが、何かを追加したかったのです。

それを文書化することは、物事を説明することです。私は皆、Doxygen やその他の自動ドキュメンテーションツールを支持していますが、API 内の関数の粗雑なリストは、何もないよりはましです。

コードを保守可能にしたい場合は、ソリューションを適切な抽象化レベルまで記述し、そのレベルまでコードを洗練して、その機能が明確になるようにします。

score 1 · Accepted Answer

small, well defined functions and classes.

It's pretty easy to get used to other people's various coding conventions but if everything is in one giant class or function, my head explodes.

score 1 · Accepted Answer

良いメンターを見つける。この人は必ずしもあなたより優れたコーダーである必要はありませんが、コードを適切に書くための他の戦略を提案できるはずです。良いメンターは、このトピックに対して以前に与えられた多くの答えを提案してくれるでしょう。彼らは、励みになる楽観的な口調を維持しながら、あなたの欠点がどこにあるかを知らせる2番目の目のセットになる可能性があります. また、彼らは柔軟で、あなたと同じように常にスキルを磨いています。そうすれば、次の大きなパラダイムが現れたときに、もみ殻と小麦をよりよく分離できるようになります. これは、オブジェクト指向プログラミングとソース管理が次の大きなものに置き換えられたときに非常に貴重です (私が知っているとは想像しがたいです)。

score 0 · Accepted Answer

一貫して適用される強力で賢明な慣習。インデックス作成を開始する場所、物事を残すための終了状態に関する規則など。

これにより、すべてのコードがより単純な方法で動作するため、コードの理解がはるかに容易になります。

これは私の一番の秘訣の少なくとも1つです。

score 0 · Accepted Answer

保守可能なコードを書くことはコードを超えていると思います。要件が何であるかを理解し（そして、機能的および非機能的の両方で何らかの形で文書化して）、新しい従業員のように、それがどのようにコードに変換されたかを紹介したほうがよいと思います。

コードがそのようなものであることが判明した理由を誰かが知っている場合は、コードを改善したり拡張したりするのが簡単になります。

より技術的なこと（アルゴリズムなど）については、抽象的に説明し（目標、原則）、コードやパターンの実装の重要な部分にコメントを付けます。

私が行うことの1つは、アプリケーション内にミニラボ、ツールボックス、およびコードテンプレートを作成して、あることを実行したり、別のことを拡張したりするために必要な「標準」コードを人々が理解できるようにすることです（コピー/貼り付けにつながりますが、作成に役立ちます）ますます良くなる）。

score 0 · Accepted Answer

適切なドキュメントがあること。これには、自己文書化 (区分化され、説明的な名前が付けられ、明確) なコード、適切なコメント、(最新の) コードの最終バージョンに対して正確な詳細な設計ドキュメント、およびソース管理の説明的な変更メモが含まれます。

2 つ要求した場合、2 つ目は間違いなく単体テストになります。2つの間の難しい選択でした。

score 0 · Accepted Answer

良いコメントは、最悪のスパゲッティコードでも 10 倍簡単に保守できます。

score 0 · Accepted Answer

Good comments. Good comments help with abstraction by stating the code's intended purpose, bad comments just restate what the code is doing. Comments could actually come in the form of well-designed and named unit tests.

score 0 · Accepted Answer

一貫したコーディングスタイル。メソッドと変数の命名規則、コメントのスタイルと形式、さらにはモジュール/ファイルの命名など。

score 0 · Accepted Answer

私は他のいくつか、アブストラクトと一緒に行きます。また、いくつかのソフトウェアパターンを理解している場合にも役立ちます。GOF は、その種の作業を開始するのに適した場所です。

score -1 · Accepted Answer

-1

ドキュメンテーション。

于 2008-10-02T15:01:08.563 に答える

maintenance - 保守可能なコードを書く

37 に答える 37

Related

Reference