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

コードレビューを実行する理想的な方法を見つけたことがありませんが、多くの場合、顧客はそれらを必要とします。各顧客は異なる方法でそれらを行うようであり、私はそれらのいずれにも満足感を感じたことはありません。 コードレビューを行うための最も効果的な方法は何ですか？ 例えば： 1人が品質の門番と見なされ、コードをレビューしていますか、それともチームが標準を所有していますか？ プロジェクターを使用してチームの練習としてコードをレビューしますか？ 直接、メール、またはツールを使用して行われますか？ コードの品質を確保するために、ペアプログラミングや集合的なコード所有権などのレビューを避けて使用していますか？

71 code-quality  code-reviews 

私は最近、かなり古い開発者（50歳以上）がいる場所で働き始めました。彼らは、システムがダウンすることができなかった航空を扱う重要なアプリケーションに取り組んできました。その結果、古いプログラマーはこの方法でコーディングする傾向があります。 彼は、オブジェクトにブール値を入れて、例外をスローすべきかどうかを示す傾向があります。 例 public class AreaCalculator { AreaCalculator(bool shouldThrowExceptions) { ... } CalculateArea(int x, int y) { if(x < 0 || y < 0) { if(shouldThrowExceptions) throwException; else return 0; } } } （このプロジェクトでは、その時点では存在できないネットワークデバイスを使用しようとしているため、メソッドは失敗する可能性があります。エリアの例は、例外フラグの例にすぎません） 私にはこれはコードの匂いのようです。毎回例外フラグをテストする必要があるため、単体テストの作成は少し複雑になります。また、何か問題が発生した場合、すぐに知りたいと思いませんか？続行方法を決定するのは呼び出し側の責任ではないでしょうか？ 彼の論理/推論は、プログラムがユーザーにデータを表示するという1つのことをする必要があるということです。それを妨げないその他の例外は無視する必要があります。私はそれらが無視されるべきではないことに同意しますが、バブルアップして適切な人によって処理されるべきであり、そのためのフラグを処理する必要はありません。 これは例外を処理する良い方法ですか？ 編集：設計上の決定についてより多くのコンテキストを与えるために、このコンポーネントが失敗した場合でも、プログラムは引き続き動作し、メインタスクを実行できるためだと思います。したがって、例外をスローしたくない（そして、それを処理しない？）ので、ユーザーが正常に動作しているときにプログラムを停止させます 編集2：より多くのコンテキストを与えるために、この場合、メソッドはネットワークカードをリセットするために呼び出されます。ネットワークカードが切断および再接続され、異なるIPアドレスが割り当てられると問題が発生します。したがって、古いIPでハードウェアをリセットしようとするため、リセットは例外をスローします。

64 c#  design  object-oriented-design  exceptions  code-reviews 

私が書いたいくつかの古いコードを見ていました。動作しますが、すばらしいコードではありません。私は当時よりも多くのことを知っているので、改善することができました。これは現在のプロジェクトではありませんが、現在の作業中の製品コードです。過去に書いたコードに戻って改善する責任がありますか、それとも「壊れていない場合は修正しないでください」という正しい姿勢ですか？私の会社は数年前にコードレビュークラスを後援しましたが、重要なポイントの1つは、時にはそれで十分であるということでした。進め。 それで、ある時点でそれを十分に呼び出して先に進むべきですか、それともより良いと思うときに古いコードを改善するためにプロジェクトをプッシュしようとするべきですか？

64 code-quality  code-reviews 

私のチームメンバーの1人であるジュニアプログラマーは、彼の経験レベルに対して優れたプログラミングスキルを持っています。 また、コードのレビュー中に、間違いを指摘するのではなく、学習を重視することを信じています。 しかし、若いプログラマーは、より上級のプログラマーのコードレビューに関与すべきでしょうか？または、コードレビューには、対応する経験を持つプログラマーのみが参加する必要がありますか？

55 teamwork  code-reviews  pair-programming 

私はボーイスカウトルールを大いに信じています。 オリジナルの作者が誰であっても、モジュールを改善するためにどんなに小さな努力をしたとしても、結果はどうなるでしょうか？すべてがその単純なルールに従っており、ソフトウェアシステムの容赦ない劣化の終わりが見えますが、代わりに、システムが進化するにつれて徐々に改善されていきます。自分の小さな部分を気遣うだけの個人よりも。 私はまた、日和見的リファクタリングの関連するアイデアを強く信じています。 いくつかのスケジュールされたリファクタリングの努力のための場所がありますが、私は、いつでもどこでもコードをクリーンアップする必要があるとき、誰によってでも行われる日和見的な活動としてリファクタリングを奨励することを好みます。これが意味することは、誰かがそれほど明確でないコードを見たときはいつでも、すぐにそれを修正する機会をとるべきだということです-少なくとも数分以内に 特に、リファクタリングの記事からの次の抜粋に注意してください。 私は日和見的リファクタリングの摩擦を引き起こす開発慣行には警戒しています...私の感覚では、ほとんどのチームは十分なリファクタリングを行っていないので、人々がそれを行わないよう注意を払うことが重要です。これを洗い流すのを助けるために、小さなリファクタリングを行うことを思いとどまるときはいつでも気をつけてください。確かに1、2分しかかかりません。そのような障壁は、会話を促す匂いです。そのため、落胆のメモを取り、チームに報告してください。少なくとも、次の回顧展で議論する必要があります。 私が働いているところでは、大きな摩擦を引き起こす開発プラクティスが1つあります。それは、コードレビュー（CR）です。「割り当て」の範囲にないものを変更するたびに、レビュー担当者に非難され、変更をレビューしにくくします。これは、リファクタリングが関係する場合に特に当てはまります。「行ごと」の比較比較が困難になるためです。このアプローチはここでの標準です。つまり、日和見的リファクタリングはめったに行われず、「計画された」リファクタリング（通常は少なすぎる、遅すぎる）が行われます。 私は、メリットはそれだけの価値があり、3人のレビュアーが少し一生懸命に働くと主張しています（変更された行の狭い範囲を見るのではなく、実際に前後のコードを理解するために-レビュー自体はそれだけで良いでしょう） ）コードを読んで保守する次の100人の開発者が恩恵を受けるように。この論点をレビューアーに提示すると、同じCRにない限り、リファクタリングに問題がないと彼らは言います。しかし、私はこれが神話だと主張しています： （1）ほとんどの場合、課題の最中に何をどのようにリファクタリングしたいかを認識するだけです。マーティン・ファウラーが言うように： 機能を追加すると、追加するコードに既存のコードとの重複が含まれていることに気付くため、既存のコードをリファクタリングしてクリーンアップする必要があります...何か機能するかもしれませんが、既存のクラスとの相互作用が変更された場合に優れています。自分が完了したと考える前に、その機会にそれを行ってください。 （2）実行するはずのない「リファクタリング」CRをリリースすることを好む人はいません。CRには一定のオーバーヘッドがあり、マネージャーはリファクタリングに「時間を浪費する」ことを望んでいません。行うべき変更にバンドルされている場合、この問題は最小限に抑えられます。 問題はResharperによって悪化します。変更に追加する各ファイル（および最終的にどのファイルが変更されるか正確に知ることはできません）には、通常、エラーと提案が散らばっています。修正。 最終的な結果は、ひどいコードが表示されることであり、そのまま残します。皮肉なことに、このようなコードを修正しても私の地位が向上するだけでなく、実際にはそれらを下げて、仕事をする代わりに誰も気にしないものを修正する時間を無駄にする「焦点のない」男として描く 私は本当に悪いコードを軽deし、それを見て我慢できず、私のメソッドからそれを呼び出すことができないので、私はそれについて悪いと感じています！ この状況をどのように解決できるかについての考えはありますか？

55 refactoring  code-reviews 

コードレビューのガイドラインをまとめています。正式なプロセスはまだありませんので、正式にしようとしています。そして、私たちのチームは地理的に分散しています。 私たちが使用しているTFSをソース管理のために（私たちは、同様のタスク/バグトラッキング/プロジェクト管理のためにそれを使用するが、我々は、移行とJIRA）開発のためのVisual Studio 2008で。 コードレビューを行う際にあなたが探しているものは何ですか？ これらは私が思いついたものです 強制FxCopののルールを（我々は、Microsoftの店です） パフォーマンス（任意のツール？）とセキュリティ（OWASP-コードクローラーの使用について考えています）およびスレッドセーフを確認します。 命名規則に従う コードはエッジケースと境界条件をカバーする必要があります 例外を正しく処理する必要があります（例外を飲み込まないでください） 機能が他の場所で複製されているかどうかを確認します メソッド本体は小さく（20〜30行）、メソッドは1つのことと1つのことのみを行う必要があります（副作用はなく、一時的な結合を回避します-） メソッドでnullを渡さない/返さない デッドコードを避ける パブリックおよび保護されたメソッド/プロパティ/変数を文書化する 他に何か気をつけるべきことはありますか？ レビュープロセスを定量化できるかどうかを確認しようとしています（別の人がレビューすると同じ出力が生成されます）。例：「メソッド本体は、体は小さくなければなりません」。 または、コードレビューは非常に主観的ですか（また、レビュー担当者ごとに異なります）。 目的は、開発者がコードをチェックインする際により慎重になるように、マーキングシステム（各FxCopルール違反ごとに-1ポイント、命名規則に従わない場合-2ポイント、リファクタリング用に2ポイントなど）を持つことです。これにより、常に良い/悪いコードを書いている開発者を特定できます。目標は、レビュー担当者がレビューを行うために最大で約30分を費やすことです（変更セット/リビジョンに複数のファイル/既存のアーキテクチャへの大きな変更などが含まれる可能性があることを考えると、これは主観的なことですが、一般的な考え方として、レビュー担当者は誰かのコードをレビューするのに何日も費やすべきではありません）。 開発者が書いた良い/悪いコードを識別するために、他にどのような客観的/定量化可能なシステムに従っていますか？ ブックリファレンス：Clean Code：Robert Martinによるアジャイルソフトウェアの職人技のハンドブック。

55 code-reviews 

2週間のスプリントの終わりに、タスクにコードレビューがあります。このレビューで、機能する、読み取り可能な関数を発見しましたが、非常に長く、コードの匂いがいくつかあります。簡単なリファクタリングジョブ。 それ以外の場合、タスクはdoneの定義に適合します。 2つの選択肢があります。 このスプリントでチケットが閉じないようにコードレビューに失敗します。チケットを渡すことができないため、士気に少し打撃を与えます。 リファクタリングは小さな作業であり、次のスプリント（または開始前）で小さなハーフポイントストーリーとして行われます。 私の質問は次のとおりです。レビューを失敗するのではなく、レビューの裏からチケットを上げることに固有の問題や考慮事項がありますか？ 私が見つけることができ、詳細コードのレビューを読んだことがあるリソースは、通常、100％または何もありませんが、通常は現実的ではありません。

53 agile  code-reviews 

SOに関するこの質問は、OPが機能en望のコードだと考えているものを修正することについて語っています。この気の利いたフレーズが引用されているのを私が見た別の例は、ここでprogrammers.SEで最近与えられた答えです。私はその答えにコメントを入れて情報を求めましたが、Q＆Aを読んでプログラマがfeature-envyという用語の意味を理解することは一般的な助けになると思いました。適切と思われる場合は、追加のタグを自由に編集してください。

53 refactoring  code-reviews  clean-code  code-smell 

私はかなり長い間、かなり大きなオープンソースプロジェクトに独力で取り組んできましたが、それをリリースしたいところに近づいています。しかし、私は独学であり、プロジェクトを適切にレビューできる人を本当に知りません。 数年前、私はそれをリリースしたフォーラムで（重大な意味で）ほぼばらばらになった小さなコードをリリースしていました。コードは機能しましたが、批判は正確ではありましたが、残忍でした。それがきっかけで、あらゆるもののベストプラクティスの検索を開始し、最終的には自分がはるかに優れた開発者になったと感じています。私は数え切れないほど完璧にしようとして何度もプロジェクトのすべてを調べてきました。 私は自分のプロジェクトを信じており、多くの人々を助ける可能性を秘めていると思いますし、それで面白い方法でいくつかのクールなことをやったと感じています。それでも、私は独学なので、私の自己教育にはどのようなギャップがあるのだろうと思わずにはいられません。前回私のコードがばらばらにされた方法は、繰り返したくないものです。数え切れないほどの時間を費やしてきたプロジェクトをリリースすることに対する2つの最大の恐怖は、独学や、さらに悪いことに、クリケットの音でリリースしたために、特許的に明らかなものを見逃したため、まったく恥ずかしいと思います。 同様の状況にあった人はいますか？私は建設的な批判を恐れていませんが、それが建設的なものであり、私がいかに失敗したかについての暴言ではありません。StackExchangeにコードレビューサイトがあることは知っていますが、大規模なプロジェクトにはあまり設定されておらず、プロジェクトの断片の一部を投稿する場合、コミュニティがまだ十分なフィードバックを得ることができるとは感じませんでした（私は1つのファイルで試してみました）。恥ずかしさやプロセスに没頭することなく、少なくともある程度の成功をプロジェクトに与えるにはどうすればよいですか？

51 open-source  self-improvement  code-reviews  personal-projects 

コードレビュー中にコードの良い部分とそれが良い理由を指摘することは重要ですか？肯定的なフィードバックは、レビュー対象の開発者にとっても、レビューに参加する他の開発者にとっても同様に有用です。 オンラインツールを使用してレビューを行っているため、開発者はコミットしたコードのレビューを開き、他の人は特定の期間（1週間など）にコードをレビューできます。他の人は、コードまたは他のレビューアのコメントにコメントできます。 正のフィードバックと負のフィードバックのバランスをとるべきですか？

48 code-reviews 

私は、顧客向けの新しいソリューションを実装するコンサルタントチームの一員です。クライアント側のコードベース（Reactおよびjavascript）のコードレビューの大部分を担当しています。 一部のチームメンバーが独自のコーディングパターンを使用して、スタイルだけで作者が誰であるかをランダムに選択できるようになっていることに気付きました。 例1（1回限りのインライン関数） React.createClass({ render: function () { var someFunc = function () { ... return someValue; }; return <div>{someFunc()}</div> } }); 著者は、someFuncに意味のある名前を割り当てることで、コードが読みやすくなると主張しています。関数をインライン化し、代わりにコメントを追加すると、同じ効果が得られると思います。 例2（非バインド関数） function renderSomePart(props, state) { return ( <div> <p>{props.myProp}</p> <p>{state.myState}</p> </div> ); } React.createClass({ render: function () { return <div>{renderSomePart(this.props, this.state)}</div>; } }); これは通常の方法です（状態と小道具を渡す必要がなくなります）。 React.createClass({ renderSomePart: function …

47 javascript  code-quality  code-reviews  reactjs 

通常のgitとgithubを使用して、マスターブランチに取り組んでいる機能ブランチのプルリクエストを作成するだけで、コードレビューを行うことができます。git-flowでコードレビューを行うにはどうすればよいですか？「git flow feature finish`」のようなワークフローでは、コードレビューが実際に行われる場所と、git-flowまたはgitがそのレビューを容易にする方法について混乱しています。

43 code-quality  git  code-reviews  github  gitflow 

私は自分で作業する以外に選択肢がなく、自分の仕事を見渡したり、健全性をチェックしたり、アイデアをブレインストーミングしたり、ベストプラクティスについて話し合ったりするための適切な解決策を見つけることができません。 私はジェフ・アトウッドの記事で答えを得ると思った：プログラミングでは、One is The Loneliest Number、私はこのテーマで見つけることができる最高ですが、それは私の質問を繰り返したことが判明しました。 私はこのようなStack Exchangeサイトを知っており、Code Reviewは明らかに潜在的な答えですが、多くの人が理解するように、理想からは遠いです： すべての落とし穴をリストすることはできませんが、多くの場合、質問を定式化して自己完結型の問題にまとめると、多くの作業が必要になります。それ以外の場合にかかっていたよりも時間。また、詳細を隠して明確に定義された質問をすることで、誰かがあなたが考えていなかった問題を見つける可能性を排除します。また、指を置くことはできませんが、自由な会話の応答性は、私が考えることのできるテキスト形式のインターネットディスカッションとは一致しません。最後になりましたが、明白な理由から、プロジェクト全体を世界中に投稿して、残りの永遠を探したいとは思いません。 私のコードを見直すためにコンサルタントにお金を払う以外の答えはありますか？

39 code-reviews  solo-development 

私は2つの会社で働いていましたが、コードレビューに関してはそれぞれが異なる方法論を持っていました。 最初の企業では、チームリーダーがコードレビューを実施し、すべてのモジュールの完了後に必要になりました。 ただし、2番目の会社では、チームリーダーはコードレビューを行う必要がなく、機能と設計の問題をチェックしました。 だから私は混乱しています。コードレビュープロセスは本当に必要ですか？もしそうなら、なぜですか？そうでない場合は、なぜですか？

39 code-reviews  junior-programmer 

私は最近、ジュニア開発者として始めました。チームで最も経験の浅い人の1人であると同時に、私は女性でもあります。男性が支配的な環境で働くことには、あらゆる種類の課題が伴います。私は自分の仕事に対して不当な教訓的な批判をしすぎているように感じるので、最近問題を抱えています。最近の出来事の例を挙げましょう。 チームリーダーは忙しくて、私が作ったいくつかのブランチをプッシュすることができなかったため、週末まで彼らに連絡しませんでした。私は自分のメールをチェックしましたが、実際には作業を行うつもりはありませんでした。変数名に基づいて2つのブランチが拒否され、エラーメッセージがわかりやすくなり、いくつかの値が構成ファイルに移動しました。 これに基づいてブランチを拒否することは有用ではないと思います。週末に多くの人が働いていましたが、私が働くとは言いませんでした。事実上、変更を行って再送信する時間がなかったため、一部の人はおそらくブロックされました。私たちは非常に時間に敏感なプロジェクトに取り組んでおり、クライアントにとって透過的なものに基づいてコードを完全に拒否することは役に立たないと思われます。私は間違っているかもしれませんが、時間があればパッチタイプのコミットでこの種のことを処理する必要があるようです。 今、私はいくつかの環境ではこれが標準であることがわかります。しかし、批判は平等に分配されているようには見えず、それが私の次の問題につながるものです。これらの問題のほとんどの原因は、私が誰か他の人が書いたコードベースにいて、最小限の侵入を試みているという事実によるものでした。ファイルの他の場所で使用されている変数名を模倣していました。私がこれを述べたとき、私は「他人を真似しないで、正しいことをしてください」と率直に言われました。これはおそらく私が言われたかもしれない最も有用なものです。すでにチェックインされているコードが受け入れられない場合、何が正しいか、何が間違っているかをどのように伝えるのですか？混乱の原因が基礎となるコードに由来するものであった場合、私はそうは思わない 私はこの状況で本当に選び抜かれ、イライラしていると感じています。期待される標準に従うことについてはずっと良くなったし、たとえば、以前は行方不明だったエラーチェックを追加するためにコードの一部をリファクタリングするとき、私はそうしなかったと言われただけでイライラするエラーを十分に冗長にします（これに基づいてブランチは拒否されました）。そもそも追加したことがない場合はどうなりますか？それがとても間違っていた場合、どのようにして最初にコードに入りましたか？だからこそ、私はあまりにもひたむきだと感じています。私は常にこの既存の問題のあるコードにぶつかって、模倣したりリファクタリングしたりしています。私がそれを模倣するとき、それは「間違っている」。そして、それをリファクタリングするなら、私は十分なことをしないことを恐れる（そして、私がずっと行くなら、バグを導入するなど）。繰り返しますが、これがこのような問題である場合、コードがコードベースにどのように侵入するかわかりませんが、 とにかく、どうすればこれに対処できますか？私は女性だとトップで言ったことを覚えておいてください、そして、これらの人は他の人のコードをレビューしているとき、通常は礼儀について心配する必要はないと確信しています、そしてそれは私に生産性を低下させています。私はそれについて上司に話したら、彼は私が環境などを扱うことができないと思うだろうと心配しています。

39 code-quality  self-improvement  teamwork  code-reviews