タグ付けされた質問 「maintainability」

作成したコードが読みやすく、理解しやすく、保守しやすいことをどのように知ることができますか？作成者の観点からはもちろん、作成者がコードを作成および編集したため、最初からコードは読み取りおよび保守が可能です。しかし、私たちの職業がコードを測定できる客観的で定量化可能な標準がなければなりません。 これらの目標は、元の作者の専門家のアドバイスなしにコードを使用して次のことを実行できる場合に満たされます。 コードを読んで、基本的なレベルでロジックの流れを理解することができます。 入力、出力、アルゴリズムを含めるためにコードが何をしているのかをより深いレベルで理解することができます。 他の開発者は、バグ修正やリファクタリングなど、元のコードに意味のある変更を加えることができます。 元のコードを活用するクラスやモジュールなどの新しいコードを作成できます。 コードの品質を定量化または測定して、読み取り、理解、および保守が可能になるようにするにはどうすればよいですか？

336 code-quality  code-reviews  readability  maintainability 

私は長年ソフトウェア開発者として働いています。多くの開発者が製品の開発に関与するにつれて、プロジェクトがより複雑で維持できなくなるというのが私の経験でした。 開発の特定の段階でソフトウェアが「ハッカー」と「ハッカー」を獲得する傾向があるようです。特に、アーキテクチャを定義したチームメンバーが会社で働いていない場合です。 何かを変更しなければならない開発者が、アーキテクチャの全体像をつかむのに苦労しているのはイライラするものです。したがって、問題を修正したり、元のアーキテクチャに対して機能する方法で変更を加えたりする傾向があります。その結果、コードはますます複雑になり、理解しにくくなります。 何年もの間ソースコードを本当に保守しやすくする方法について何か役に立つアドバイスはありますか？

156 project-management  maintainability 

既存のコードを拡張/改善する必要がある状況に陥ることがあります。古いコードは非常にスリムですが、拡張するのも難しく、読むのに時間がかかります。 それを最新のコードに置き換えるのは良い考えですか？ 少し前に私は無駄のないアプローチが好きでしたが、今では、より高い抽象化、より良いインターフェース、より読みやすく拡張可能なコードのために多くの最適化を犠牲にするほうが良いように思えます。 コンパイラも同様に良くなっているように見えるので、何も言わずstruct abc = {}にmemsetsに変わり、shared_ptrsは生のポインタをいじるのとほぼ同じコードを生成します。 それでも、スタックベースの配列や、いくつかのあいまいなロジックを持つ古いC関数が表示されることがありますが、通常はクリティカルパスにありません。 どちらかの方法でコードの一部に触れる必要がある場合、そのようなコードを変更することは良い考えですか？

78 c++  c  refactoring  optimization  maintainability 

私はC＃のAvSolコーディングガイドラインに目を通し、ほぼすべてに同意しましたが、特定のルールについて他の人がどう考えているかを知りたいと思います。 AV1500 メソッドは7つのステートメントを超えてはなりません。7つを超えるステートメントを必要とするメソッドは、処理が多すぎるか、責任が多すぎます。また、人間の心が正確なステートメントを分析して、コードが何をしているかを理解する必要があります。わかりやすい名前で、複数の小さくて焦点を絞った方法に分けてください。 あなたのほとんどはこのルールに従っていますか？読みやすさを大幅に向上させることは別として、新しいメソッドを作成すること（コードはまだDRYです）から節約できることはほとんどありませんか？そして、あなたの番号はまだ7と低いですか？私はもっ​​と10に向かう傾向があるでしょう。 私はあちこちでこの規則に違反していると言っているわけではありません。反対に、私の方法は95％小さくて集中していますが、この規則に違反してはいけないと言って本当に衝撃を受けました。 私は本当に誰もがこの規則に違反しないと思うことを知りたいだけです（コーディング標準の「1」です-これを絶対にしないでください）。しかし、そうでないコードベースを見つけるのに苦労すると思います。

78 c#  coding-standards  maintainability 

コードを書くときは、コードをできる限りクリーンで読みやすいものにするように常に心がけています。 ときどき、ラインを越えて、すっきりしたきれいなコードから少しugいコードに移行して、より速くする必要があるときがあります。 その線を横切るのはいつですか？

67 performance  optimization  quality  readability  maintainability 

ネストされた関数呼び出しのコーディングスタイルは次のとおりです。 var result_h1 = H1(b1); var result_h2 = H2(b2); var result_g1 = G1(result_h1, result_h2); var result_g2 = G2(c1); var a = F(result_g1, result_g2); 私は最近、次のコーディングスタイルが非常に使用されている部門に変更しました。 var a = F(G1(H1(b1), H2(b2)), G2(c1)); コーディングの私の方法の結果、クラッシュする機能の場合、Visual Studioは対応するダンプを開き、問題が発生した行を示すことができます（特にアクセス違反が心配です）。 最初の方法でプログラムされた同じ問題によるクラッシュの場合、どの関数がクラッシュを引き起こしたかを知ることができないのではないかと心配しています。 一方、1行に追加する処理が多いほど、1ページに表示されるロジックが多くなり、読みやすくなります。 私の恐怖は正しいのですか、それとも一般的には商業環境で好まれる何かが欠けていますか？可読性または保守性？ 関連するかどうかはわかりませんが、C ++（STL）/ C＃で作業しています。

57 c#  c++  coding-style  readability  maintainability 

これを求める別の方法は次のとおりです。なぜプログラムはモノリシックになる傾向があるのですか？ Mayaのようなアニメーションパッケージのようなものを考えています。人々はさまざまなワークフローに使用します。 アニメーション機能とモデリング機能を独自の個別のアプリケーションに分割し、それらの間でファイルをやり取りして個別に開発した場合、それらの保守は容易ではないでしょうか？

48 design  architecture  maintainability  application-design 

フラグ変数は悪ですか？次の種類の変数は非常に不道徳であり、それらを使用するのは邪悪ですか？ 「特定の場所で値を割り当てた後でブール値または整数変数を下にチェックしてから、何かをするかどうかをチェックしてから、たとえばnewItem = true以下の行を使用するif (newItem ) then」 フラグの使用を完全に無視して、より良いアーキテクチャ/コードになったプロジェクトをいくつか行ったことを覚えています。しかし、それは私が働いている他のプロジェクトでは一般的な慣行であり、コードが大きくなりフラグが追加されると、IMHOコードスパゲッティも大きくなります。 フラグを使用するのが良い習慣である、あるいは必要な場合があると言いますか？またはコードでフラグを使用することは...赤いフラグであり、回避/リファクタリングする必要があることに同意しますか？私は、代わりにリアルタイムで状態をチェックする関数/メソッドを実行するだけでうまくいきます。

47 code-quality  code-smell  maintainability 

マジックナンバー（ハードコードされた値）がプログラムに大混乱をもたらす可能性があることは誰もが知っています。特にコメントのないコードセクションを変更するときは、どこに線を引きますか？ たとえば、2日間の秒数を計算する関数がある場合、置き換えますか seconds = num_days * 24 * 60 * 60 と seconds = num_days * HOURS_PER_DAY * MINUTES_PER_HOUR * SECONDS_PER_MINUTE どの時点で、ハードコーディングされた値の意味が完全に明らかであると判断し、そのままにしておくのですか？

36 refactoring  coding-standards  maintainability 

この質問に答えながら、なぜ多くの開発者が優れた設計がパフォーマンスを考慮すべきではないと考えるのか疑問に思い始めました。なぜなら、そうすると読みやすさや保守性に影響するからです。 優れたデザインでは、執筆時にパフォーマンスも考慮され、優れたデザインの優秀な開発者は、可読性や保守性に悪影響を与えることなく効率的なプログラムを作成できると考えています。 極端な場合があることは承知していますが、なぜ多くの開発者が効率的なプログラム/設計が読みやすさや保守性の低下をもたらすと主張するのでしょうか？

34 code-quality  performance  readability  maintainability 

これはやや物議を醸すトピックであり、プログラマーと同じくらい多くの意見があると思います。しかし、そのために、ビジネス（または職場）での一般的な慣行を教えてください。 私の職場では、厳密なコーディングガイドラインがあります。その1つのセクションは、マジックストリング/マジックナンバー専用です。状態（C＃の場合）： コードでは、記号定数を定義する以外に、数値または文字列のリテラル値を使用しないでください。次のパターンを使用して、定数を定義します。 public class Whatever { public static readonly Color PapayaWhip = new Color(0xFFEFD5); public const int MaxNumberOfWheels = 18; } 例外があります：値0、1、nullはほとんど常に安全に使用できます。多くの場合、値2および-1も問題ありません。ロギングまたはトレースを目的とした文字列は、この規則から除外されます。リテラルは、意味が文脈から明らかであり、将来の変更の影響を受けない場合に許可されます。 mean = (a + b) / 2; // okay WaitMilliseconds(waitTimeInSeconds * 1000); // clear enough 理想的な状況は、次の場合にコードの可読性/保守性への影響を示す公式の研究論文です。 魔法の数字/文字列がいたるところにある 魔法の文字列/数字は、一定の宣言によって合理的に（またはさまざまな範囲で）置き換えられます-「合理的に」使用することについて私に怒鳴らないでください 魔法の文字列/数字は、過剰に置き換えられる必要があります（以下の私の例を参照） 私の同僚の1人と議論するときに科学的根拠に基づいた議論をするためにこれをしたいと思います。彼は次のような定数を宣言するようになります： private const char SemiColon = ';'; private …

31 coding-style  refactoring  coding-standards  readability  maintainability 

非常にパフォーマンスに敏感ないくつかの関数（1秒あたり数百万回と呼ばれる）を持つかなり大きなプロジェクトにソースファイルがあります。実際、以前のメンテナーは、1つの関数で条件のチェックに費やす時間を節約するために、それぞれわずかに異なる関数のコピーを12個書くことにしました。 残念ながら、これはコードが維持するPITAであることを意味します。重複するコードをすべて削除し、テンプレートを1つだけ作成したいと思います。ただし、Java言語はテンプレートをサポートしていないため、ジェネリックがこれに適しているかどうかはわかりません。 私の現在の計画は、代わりに関数の12個のコピーを生成するファイル（実際には1回限りのテンプレート拡張機能）を書くことです。もちろん、ファイルをプログラムで生成する必要がある理由については、豊富な説明を提供します。 私の懸念は、これが将来のメンテナーの混乱につながり、変更後にファイルを再生成するのを忘れると厄介なバグを引き起こす可能性があることです。残念ながら、C ++ですべてを書き直すまで、これを修正する方法はありません。 このアプローチの利点は欠点を上回っていますか？代わりに： パフォーマンスに打撃を与え、単一の保守可能な機能を使用します。 関数を12回複製する必要がある理由の説明を追加し、保守の負担を丁寧に負担します。 ジェネリックをテンプレートとして使用することを試みます（それらはおそらくそのようには動作しません）。 単一の関数にコードをパフォーマンスに依存させるという古いメンテナーに大声で叫ぶ。 パフォーマンスと保守性を維持する他の方法は？ PSプロジェクトの設計が貧弱であるため、関数のプロファイリングはかなりトリッキーです...しかし、前のメンテナーは、パフォーマンスの低下は許容できないと私に確信させました。これは彼が5％以上を意味すると思いますが、それは私の側の完全な推測です。 おそらく少し詳しく説明する必要があります。12個のコピーは非常によく似たタスクを実行しますが、わずかな違いがあります。違いは関数全体のさまざまな場所にあるため、残念ながら多くの条件文があります。事実上、6つの操作の「モード」と2つの操作の「パラダイム」があります（自分で作成した単語）。関数を使用するには、操作の「モード」と「パラダイム」を指定します。これは決して動的ではありません。コードの各部分は、厳密に1つのモードとパラダイムを使用します。12のモードパラダイムペアはすべて、アプリケーションのどこかで使用されます。これらの関数には、func1〜func12という適切な名前が付けられ、偶数が2番目のパラダイムを表し、奇数が最初のパラダイムを表します。 保守性が目標であれば、これは最悪の設計であることを認識しています。しかし、それは「十分に速い」と思われ、このコードはしばらく変更を必要としませんでした...元の関数が削除されていないことにも注意する価値があります（ただし、私が知る限り、それはデッドコードです） 、したがって、リファクタリングは簡単になります。

29 java  performance  maintainability  templates 

であるelse while「安全」メンテナンスが賢明と考え括弧を介在せずに？ if-else以下のような中括弧なしでコードを書く... if (blah) foo(); else bar(); ...中括弧がないため、コードの意味を不注意に変更することが非常に簡単になるため、リスクが伴います。 ただし、以下も危険ですか？ if (blah) { ... } else while (!bloop()) { bar(); } またはelse while、介入する中括弧なしで「安全」と見なされますか？

26 coding-style  language-agnostic  maintainability 

プラグインがプログラムフローに反応できるようにするアプリを検討してください。 これを達成する2つの方法を知っています：フックとイベント 1.フック メインプログラムフロー内の空の関数の呼び出しを使用します。これらの機能はプラグインによってオーバーライドできます。 たとえば、Drupal CMSはモジュールとテーマで利用可能なフックを実装しています。file_copy関数でフックを実装する方法の例を次に示します。 function file_copy(stdClass $source, $destination = NULL, $replace = FILE_EXISTS_RENAME) { // ... [File copying routine] // Inform modules that the file has been copied. module_invoke_all('file_copy', $file, $source); return $file; // ... } モジュールはmodulename_file_copy($file, $source)、module_invoke_allin によって呼び出される関数を実装できますfile_copy。この関数が終了すると、file_copy実行が再開されます。 2.イベント プラグインがリッスンできるイベントをアプリにディスパッチさせます。サブスクライブされているイベントを受信した後、プラグインはプログラムフローをインターセプトし、必要な操作を実行します。 たとえば、jQueryギャラリープラグインFotorama はいくつかのイベントを実装します。例として、イベントshowを発生させるメソッドの一部を次に示しfotorama:showます。 that.show = function (options) { …

24 readability  maintainability  event-programming  plugins  hooks 

コンテキスト：私は、すべてがMSショップのエンタープライズ開発者です。 コードやアプリケーションの保守性を客観的に測定するための良い方法を誰かがお勧めできますか？ なぜ保守性があるのか：バグとコードカバレッジの数のみを対象とするグループの "品質"メトリックにうんざりしています。特に保守性を測定していない場合は、どちらのメトリックも簡単にゲームできます。近視眼と締め切りは、実際に対処されない膨大な量の技術的負債をもたらします。 なぜ客観的に測定できるのか：私は大企業グループで働いています。客観的に測定できない場合は、人々に説明責任を負わせたり、それを改善することはできません。主観的な測定は、発生しないか、一貫して発生しません。 私はVS2010コードメトリックスを見ていますが、誰か他の推奨事項があるかどうか疑問に思っています。

23 c#  visual-studio-2010  metrics  maintainability  measurement