タグ付けされた質問 「code-quality」

私は非常に大きいPHPアプリを持っています。通常、2〜3人の開発者がフルタイムで取り組んでおり、変更を加えてバグ（咳機能）を作成するところまで来ています。ソフトウェアは言うまでもなく複雑ではありません。多くのことが起こっているだけです（35〜コントローラー、同じモデルなど）。 注意していても、このビューを変更すると（要素のIDを微調整）、特別な条件（片足でログアウトしている）で発生するajaxクエリが壊れるのは簡単です。 ユニットテストは最初に思い浮かぶものですが、別のアプリで試してみたので、それらを忘れたり、テストを記述してからテストを実行したりすることに多くの時間を費やすことは簡単です。ライブ配信する前にコードがチェックされるステージング環境があります。 多分パートタイムのQ / Aの人が必要ですか？ 誰もが何か提案/考えを持っています。

10 testing  code-quality  tdd 

（私はこの質問を見ましたが、最初の答えはデザインよりも自動プロパティに関するもので、2番目の答えは、データストレージコードをコンシューマから隠すことです。これは、自分のコードが何をしたいのかわからないのですが、他の意見も聞きたいです） 私には2つの非常に類似したエンティティがHolidayDiscountありRentalDiscount、「それが少なくとも続く場合numberOfDays、percent割引が適用される」として長さ割引を表します。テーブルにはさまざまな親エンティティへのアクセス権があり、さまざまな場所で使用されますが、それらが使用される場所には、適用可能な最大の割引を取得するための共通のロジックがあります。たとえば、aにHolidayOfferはの数がありHolidayDiscounts、そのコストを計算するときは、該当する割引を計算する必要があります。レンタルと同じですRentalDiscounts。 ロジックは同じなので一箇所に留めておきたい。これが、次のメソッド、述語、およびコンパレータが行うことです。 Optional<LengthDiscount> getMaxApplicableLengthDiscount(List<LengthDiscount> discounts, int daysToStay) { if (discounts.isEmpty()) { return Optional.empty(); } return discounts.stream() .filter(new DiscountIsApplicablePredicate(daysToStay)) .max(new DiscountMinDaysComparator()); } public class DiscountIsApplicablePredicate implements Predicate<LengthDiscount> { private final long daysToStay; public DiscountIsApplicablePredicate(long daysToStay) { this.daysToStay = daysToStay; } @Override public boolean test(LengthDiscount discount) { return daysToStay >= discount.getNumberOfDays(); …

10 java  object-oriented  object-oriented-design  code-quality 

コントローラークラスのアクション関数は、モデルからビューへのデータのフローを単純に制御するための多数のコード行で、巨大で厄介なものになる場合があります。ある時点で、これらの巨大な関数は、優れたコードの基本原則を完全に失うことになります。 これらの巨大なアクション関数をコントローラークラスで小さなプライベート関数に分割することは良い習慣と考えられるでしょうか、またはそのような最適化の必要性はモデルにそれらを追加する必要があることを意味しますか？ アクションに関連するように、コントローラーで小さい関数をプライベートとして使用することに投票しますが、モデルが巨大でぎこちない場合は、コントローラーはシンプルであることが望ましいという意見を聞いています。そして、どちらが最も好ましい方法であるか疑問に思っていました。

10 php  code-quality  mvc 

テストしているクラスがあります。クラスには関数があります：apply(List<IRule> rules, List<ITarget> targets); 1つのテストで、各ターゲットが1つのルールaに渡されていることを確認します。 rule1.AssertWasCalled(fnord => fnord.Test(target1)); rule1.AssertWasCalled(fnord => fnord.Test(target2)); rule1.AssertWasCalled(fnord => fnord.Test(target3)); 自分を単一の表明文に限定することはかなりホブゴブリンだと私には思えます。この仮定は正しいですか、それとも各ターゲットが実際にテストされたと断言できる他の方法がありますか？

10 unit-testing  code-quality 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 コードの最適化、標準、ベストプラクティスを最優先しないことを選択したソフトウェア開発者は、最適化、コーディング標準の実装、時間どおりにタスクを完了することを実践したい開発者よりも有用なコードを作成しますか？ 個々のパフォーマンスレビューに関して、これらの異なる方法論はどのように比較されますか？ これらのスタイルはピアレビューでどのように比較されますか？ SDLC中により多くのベストプラクティスを実装するためにチームに影響を与える最良の方法は何ですか？

10 code-quality  teamwork 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 6年前休業。 私のJavaの本の多くは5〜10年前のものです。それでもそれらを読むのに役立ちますか、それとも2年以内に何かを使うべきですか？

10 books  code-quality 

StackOverflowからの再投稿のリクエスト： 私は開発期間が非常に限られた短い開発時間で働いています。私たちは、仕事の結果には重要ですが、日常的には使用されないツールを開発しています。私は、プログラマーとしての経歴を持つチームで唯一の人物です。 私の問題は、1年以上トランクにマージする前にコードレビューを強く求めてきたことです。誰もがこれに同意しましたが、それでもレビューされたのは私のコードだけです。長い休暇から戻ってきて、「これは醜い解決策です-できるだけ早く削除してください」と「クイックフィックス」のコードコメントでトランクに戻ります。また、新しいのは、ある人がツールの責任者に任命されたということです。（最初に私に与えられた役割ですが、仕事以外の理由で辞退しました。）そして、彼はこれは仕事をするのに良い方法であると考えています。 私の懸念は、他の開発者が醜いコードを書くことです：多くの場合、カプセル化の破壊、巨大なクラスの作成、奇妙な場所での内部クラスの追加、ユニットテストがほとんどまたはまったくないなどです。最終的にはツールをさらに開発することは不可能になります。 トランクにマージする前にコードレビューを実行するように主張する必要がありますか、それとも単なるコード品質の問題ですか？

10 code-quality  collaboration  code-reviews 

結合と凝集に関するc2wikiページから： 凝集度（モジュール内の相互依存性）強度/レベル名：（悪いものから良いものへ、高い凝集性が良い） 偶然の凝集度：（最悪）モジュール要素は無関係 論理的凝集度：要素は、外部モジュールから選択されたものと同様のアクティビティを実行します。つまり、実行する操作を選択するフラグによって実行されます（CommandObjectも参照）。つまり、関数の本体は1つの巨大なif-else / switch on operationフラグです 一時的な結束：実行される一般的な時間のみに関連する操作（すなわち、initialization（）またはFatalErrorShutdown？（）） 手続き的結束：それぞれが異なるデータにある、異なるが順次のアクティビティに関与する要素（通常、線形シーケンス境界に沿って複数のモジュールに簡単に分割できます） コミュニケーションの結束：同じデータまたは入力を必要とする以外は無関係な操作 シーケンシャル凝集：重要な順序での同じデータの操作。1つの関数の出力が次の関数に入力される（パイプライン） 情報のまとまり：モジュールはいくつかのアクションを実行します。各アクションには独自のエントリポイントがあり、アクションごとに独立したコードがあり、すべて同じデータ構造で実行されます。基本的に、抽象データ型の実装。つまり、sales_region_tableとその演算子の構造を定義します。init_table（）、update_table（）、print_table（） 機能的結束：すべての要素が1つの明確に定義されたタスク、つまり1つの操作を実行する関数get_engine_temperature（）、add_sales_tax（）に貢献します （強調鉱山）。 私は論理的な結束の定義を完全に理解していません。私の質問は： 論理的な結束とは何ですか？ なぜそんなにひどいラップ（2番目に悪い凝集力）になるのですか？

10 code-quality  metrics  cohesion 

このコードは、簡略化すると次のようになります。 public class Room { public Client Client { get; set; } public long ClientId { get { return Client == null ? 0 : Client.Id; } } } public class Client { public long Id { get; set; } } 現在、3つの視点があります。 1）Clientプロパティは常に設定される必要があるため（つまりnullではない）、これは適切なコードでClient == nullあり、Id値0は偽のIDを示します（これはコードの作成者の意見です;-)） 2）が0偽の値であることを呼び出し元に依存することはできません。Idまた、 Clientプロパティを常に設定する必要exceptionがあるget場合は、Clientプロパティがnullになったときにをスローする必要があります。 3）Clientプロパティを常に設定する必要がある場合は、プロパティがたまたまnullの場合に戻りClient.Id、コードにNullRef例外をスローさせClientます。 これらのうちどれが最も正しいですか？または、4つ目の可能性はありますか？

9 c#  code-quality  null 

パブリックメソッドの引数を検証することをお勧めします。 彼がnullを期待していない場合、nullをチェックする必要がありますか？ メソッドはパラメータを検証する必要がありますか？ MSDN-CA1062：パブリックメソッドの引数を検証します（.NETの背景がありますが、質問はC＃固有ではありません） 動機は理解できます。モジュールが誤った方法で使用される場合は、予測できない動作ではなく、すぐに例外をスローする必要があります。 気になるのは、モジュールの使用中に発生する可能性のあるエラーは間違った引数だけではないということです。推奨事項に従ってエラーのエスカレーションを望まない場合に、チェックロジックを追加する必要があるいくつかのエラーシナリオを以下に示します。 着信-予期しない引数 着信-モジュールの状態が間違っています 外部呼び出し-予期しない結果が返されました 外部呼び出し-予期しない副作用（呼び出しモジュールへの二重入力、他の依存関係の状態を壊す） 私はこれらすべての条件を考慮して、1つのメソッド（申し訳ありませんが、C＃ではありません）で単純なモジュールを作成しようとしました： public sealed class Room { private readonly IDoorFactory _doorFactory; private bool _entered; private IDoor _door; public Room(IDoorFactory doorFactory) { if (doorFactory == null) throw new ArgumentNullException("doorFactory"); _doorFactory = doorFactory; } public void Open() { if (_door != null) throw …

9 design  code-quality  coding-standards  exceptions  error-handling 

C＃では、usingステートメントを使用して、ガベージコレクターを待たずにリソースを確定的な方法で破棄します。たとえば、次の目的で使用できます。 SQLコマンドまたは接続を破棄します。 ストリームを閉じ、ファイルのように基礎となるソースを解放し、 無料のGDI +要素、 等 これは、using処理するものが何もない場合にますます使用されていることに気付きましたが、呼び出し元usingが2つの個別のコマンドではなくブロックを書き込む方が便利な場合に使用します。 例： Stack Overflowチームによって作成されたMiniProfilerは、usingプロファイルするブロックを示すために使用します。 using (profiler.Step("Name goes here")) { this.DoSomethingUseful(i - 1); } 1つの代替アプローチは、2つのブロックを持つことです。 var p = profiler.Start("Name goes here"); this.DoSomethingUseful(i - 1); profiler.Stop(p); 別のアプローチはアクションを使用することです： profiler.Step("Name goes here", () => this.DoSomethingUseful(i - 1)); ASP.NET MVCもusingフォームに選択されています。 <% using (Html.BeginForm()) { %> <label for="firstName">Name:</label> <%= Html.TextBox("name")%> …

9 c#  .net  code-quality  readability 

私はロイ・オセロベによるユニットテストの芸術を読んでいます。私はセクション7.2にいます。ここでは、作成者がコードのにおいについてこのメモを持っています。 注：外部テストから見えるように内部状態をリファクタリングする場合、それはコードのにおい（コードの設計またはロジックに問題がある可能性がある兆候）と見なすことができますか？共同編集者を公開するためにリファクタリングしているときは、コードのにおいではありません。リファクタリングを行っていて、共同編集者がいない場合は、コードのにおいです（したがって、何もスタブしたりモックしたりする必要はありません）。 編集：著者が「共同編集者」によって意味するのは依存関係です。彼の依存関係の例には、データベースにアクセスするクラスや、OSのファイルシステムにアクセスするクラスがあります。ここで、彼はスタブを定義し、コラボレーターという言葉を使い始めます。 スタブは、既存の制御置換である依存性（または 共同編集システムにおいて）。 作者にはこのコードの匂いの例はなく、これがどのように見えるか理解/描写するのに苦労しています。誰かがこれをもう少し説明して、おそらく具体的な例を提供できますか？

9 unit-testing  code-quality  code-smell 

入門レベルのソフトウェア開発者としてのポジションを始めてから数ヶ月になります。いくつかの学習曲線（言語、専門用語、VBやC＃の構文など）を過ぎた今、より優れたソフトウェアを書くために、より難解なトピックに焦点を合わせ始めています。 同僚に簡単な質問をしたところ、「間違ったことに集中している」と答えました。私はこの同僚を尊重していますが、これが「間違ったこと」に焦点を当てていることには同意しません。 ここにコード（VB）があり、その後に質問が続きました。 注：関数GenerateAlert（）は整数を返します。 Dim alertID as Integer = GenerateAlert() _errorDictionary.Add(argErrorID, NewErrorInfo(Now(), alertID)) 対... _errorDictionary.Add(argErrorID, New ErrorInfo(Now(), GenerateAlert())) 私は後者を最初に作成し、「Dim alertID」を使用して書き直したので、他の誰かが読みやすくなっています。しかし、ここに私の懸念と質問がありました： Dim AlertIDでこれを書き込むと、実際にはより多くのメモリを消費します。有限ではありますが、このメソッドを何度も呼び出す必要がありますか？.NETはこのオブジェクトAlertIDをどのように処理しますか。.NETの外では、使用後にオブジェクトを手動で破棄する必要があります（サブの末尾近く）。 ガベージコレクションだけに頼らない知識豊富なプログラマーになりたいです。私はこれを考えすぎていますか？私は間違ったことに集中していますか？

9 programming-practices  code-quality  garbage-collection 

静的コード分析とコードレビューの違いを知りたかっただけです。これら2つはそれぞれどのように行われますか？より具体的には、PHPのコードレビュー/静的分析に現在利用できるツールは何ですか？また、あらゆる言語のコードレビューに適したツールについても知りたいです。

9 code-quality  terminology  code-reviews  quality 

今日、私の同僚が私のコードをレビューし、設定のみのプロパティを削除して、代わりにメソッドを使用することを提案しました。 私たち2人は他のことで忙しかったので、Property Design「フレームワークの設計ガイドライン」の本のセクションを見るように言われました。本の中で作家はただ避けようと言った： ゲッターよりも広いアクセシビリティを持つセッターを持つプロパティ そして今、私はなぜそれがセットオンリープロパティを持つことが推奨されないのか疑問に思っていますか？誰かが私のために明確にできますか？

9 design  code-quality  code-reviews  code-smell