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

このタグは、コードレビューとコードウォークスルーの実践に関する質問に使用します。既存の動作するコードのレビューについては、http：//codereview.stackexchange.comを参照してください

4
トランクにマージする前にコードレビューを実行するように主張する必要がありますか？
StackOverflowからの再投稿のリクエスト： 私は開発期間が非常に限られた短い開発時間で働いています。私たちは、仕事の結果には重要ですが、日常的には使用されないツールを開発しています。私は、プログラマーとしての経歴を持つチームで唯一の人物です。 私の問題は、1年以上トランクにマージする前にコードレビューを強く求めてきたことです。誰もがこれに同意しましたが、それでもレビューされたのは私のコードだけです。長い休暇から戻ってきて、「これは醜い解決策です-できるだけ早く削除してください」と「クイックフィックス」のコードコメントでトランクに戻ります。また、新しいのは、ある人がツールの責任者に任命されたということです。（最初に私に与えられた役割ですが、仕事以外の理由で辞退しました。）そして、彼はこれは仕事をするのに良い方法であると考えています。 私の懸念は、他の開発者が醜いコードを書くことです：多くの場合、カプセル化の破壊、巨大なクラスの作成、奇妙な場所での内部クラスの追加、ユニットテストがほとんどまたはまったくないなどです。最終的にはツールをさらに開発することは不可能になります。 トランクにマージする前にコードレビューを実行するように主張する必要がありますか、それとも単なるコード品質の問題ですか？
2
馴染みのないコードベースを説明するのに役立つツールやテクニックは何ですか？[閉まっている]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 5年前休業。 見慣れないコードを手動で検査（確認または変更）するとき、3つのオプションがあるようです。 トップダウン読み取り、ファイル名はそうどのように基本的なことで、それぞれ次のソースファイルを選択し、コードの。 私は通常、ほぼすべてを読むことになります。一部のファイルは2回。 幅優先読み取り、私が見つけ、最小限の理解した上で、呼び出すメソッドのすべてを読み、。次に、関数が呼び出したすべての関数を読み取ります。 私のメンタルスタックは、数回の呼び出しで深くすると、オーバーフローする傾向があります。 デバッガですべてのコードをステップ実行する深さ優先の読み取りでは、これに8分かかるのか8時間かかるのかわかりません。 コードの内容を十分に理解するのに十分なコードを読んだら、基本コードが20％以下である一方で、コードベースの80％以上を読んだことをよく反映します。私は多くの時間を無駄にしました。 なじみのないコードをすばやく把握するには、どのツールが役立ちますか？クリティカルコードパスの「全体像」を示し、特定の部分の詳細にドリルダウンできるツールはありますか？
7
静的コード分析とコードレビューの違いは何ですか？
静的コード分析とコードレビューの違いを知りたかっただけです。これら2つはそれぞれどのように行われますか？より具体的には、PHPのコードレビュー/静的分析に現在利用できるツールは何ですか？また、あらゆる言語のコードレビューに適したツールについても知りたいです。
4
パブリックメソッドからハッシュテーブルを返す際の何が問題になっていますか？
クラスを作成してそのオブジェクトを返すのではなく、複数のアイテムを返したいときに、パブリックメソッドからハッシュテーブルを返す際の設計上の問題は何ですか？ 問題がある場合は、どのような状況でそれを行うのが理にかなっていますか？ 言語が動的かどうかによって、この質問に対する答えはどのように変わりますか？ 編集：これは、キーが定数であり、データではなくコードの一部であることを明確にするためです。通常、クラスを作成するためのもの。問題は、クラスの作成が実際に正しい選択であるように思われる場合に、代わりにハッシュテーブルを使用することが間違っている理由です。
6
CSS、JS、HTMLのコードレビューガイドライン
CSS、JS、HTMLのレビューのためのガイドラインを作成するように依頼されました。JSのコーディングガイドラインがあることは知っていますが、HTMLとCSSについては何も知りません。JSをレビューするために、私は確かにそれらのガイドラインに従い、それらに言及します。しかし、CSSとHTMLはどうでしょうか？論理エラーやインデントの問題以外に、マークアップやCSSを確認するときに確認する必要がある具体的な事項はありますか？
4
設定のみのプロパティを持つことが推奨されないのはなぜですか？
今日、私の同僚が私のコードをレビューし、設定のみのプロパティを削除して、代わりにメソッドを使用することを提案しました。 私たち2人は他のことで忙しかったので、Property Design「フレームワークの設計ガイドライン」の本のセクションを見るように言われました。本の中で作家はただ避けようと言った： ゲッターよりも広いアクセシビリティを持つセッターを持つプロパティ そして今、私はなぜそれがセットオンリープロパティを持つことが推奨されないのか疑問に思っていますか？誰かが私のために明確にできますか？
2
GITをリポジトリとして使用する場合のコードレビュープロセス？
GITを使用する場合のコードレビューの最適なプロセスは何ですか？外部GITプロバイダー（Unfuddle）があり、リソース使用量に上限があります。そのため、すべての開発者に専用のリモートリポジトリを用意することはできません。 現在のプロセス： master誰もがコミットするブランチを持つGITサーバーがあります 開発者はローカルmasterミラーまたはローカル機能ブランチから作業します 開発者がサーバーのmasterブランチにプッシュ 開発者は最後のコミット時にコードレビューをリクエストする 問題： コードレビューのすべてのバグは、それがキャッチされるまでにすでにマスターにあります。 さらに悪いことに、通常、誰かが何が起こったのかを理解しようとして数時間火傷しました... ですので、 コードを実行するには、「マスター」に配信する前に確認してください。 グローバルチームと連携するプロセスを用意する（肩のレビューではありません！） 個人の開発者が自分のデスク/マシンに電源を入れて他の誰かがリモートでアクセスできるようにする必要がないもの（人間の依存関係を削除し、開発者が異なるタイムゾーンで家に帰る） TortoiseGITを使用して、変更されたファイルのリスト、ファイルの差分などを視覚的に表現します。GUIが十分でない場合、GITシェルにドロップする人もいますが、理想的には、ワークフローをシンプルでGUIベースにしたい（私は私のツールではなく、あらゆる負担を取り除くツールを求めています）。
4
どのようにしてコードに対して建設的な批判を得ることができますか？
私のチームがコードレビューを行うことはめったにありません。これは、主に十分な時間がないため、人々はエネルギーを欠いており、そうするつもりだからです。しかし、私のコードを読んだときに、人々が私のコードについてどう思うかを本当に知りたいです。このようにして、他の人が私のコードをどのように考え、調整するかを理解し、読みやすくしています。 だから私の質問は、どうすれば私のコードに対して建設的な批判を得ることができるのですか？私の目的は、より読みやすいコードを記述できるように、人々の考え方を理解することです。
3
大きなコードの塊についてコミュニティからフィードバックを得るにはどうすればよいですか？
Code Review.SEは、正確で短いコードに関するフィードバックが必要な場合に最適です。 しかし、次の場合にコード自体について同様のフィードバックをどこで得るか。 あなたは何千ものLOCを持っています、 職場の同僚がコードをレビューする準備ができていたり、喜んでレビューしたりしないでください¹、 サードパーティの開発者による専門家によるレビューに数千ドルも費やしていないのですか？² CodePlexのような場所はあなたのプロジェクトを知るための良い考えです³しかし、私が見たことから、あなたが既知のプロジェクトで得るフィードバックは消費者のフィードバックです。 Firefoxまたは類似の製品の規模を持たないオープンソースプロジェクトの特定のサイズのコードベースのコードレビューにコミュニティを参加させるための社会的な方法は何ですか？ ¹これは、ほとんどの個人的なオープンソースプロジェクト、または定期的かつ完全なコードレビューの実践が存在しない会社で行われたプロジェクトの場合です。 ²これもまた、ほとんどの個人的なオープンソースプロジェクトの場合です。 Code CodePlexで公開されたプロジェクトがあまりにも多くても、誰も気にしないため、またはそれらがあまりよく表示されないために、知られることはありません。
3
コードレビューのコード量
私の経験では、社内のほとんどのチームが、常に数百行未満の少量のコードでチームメンバーのコードを確認しています。コードが完成し、一度にすべてのレビューを受ける準備ができたときに、モジュールなどの大量のコードをレビューすることは適切ですか？
2
Gerrit、git、ブランチ全体のレビュー
現在、Gerrit（これは私が使用する最初のコードレビューツールです）を学んでいます。Gerritは、単一のコミットで構成されるようにレビューされた変更を必要とします。私の機能ブランチには約10のコミットがあります。 メリットを優先する方法は、これらの10個のコミットを1つのコミットに押しつぶすことです。ただし、この方法でコミットがターゲットブランチにマージされる場合、その機能ブランチの内部履歴は失われます。たとえば、git-bisectこれらのコミットを二分するために使用することはできません。私は正しいですか？ 私はこの状態について少し心配しています。この選択の理由は何ですか？歴史を失うことなく、Gerritでこれを行う方法はありますか？
1
提案された変更の潜在的なレビュー担当者を特定するツール
入力として提案されたパッチとgitリポジトリを受け取り、開発者がパッチをレビューするのに最適な候補であることを識別するツールはありますか？git履歴を使用して、変更されるコードのファイル/セクションで最も経験のある作成者を特定します。 編集：ユースケースは、大規模なオープンソースプロジェクト（OpenStack Compute）であり、マージの提案が出てきて、よく知らないコードのチャンクにマージの提案が表示され、他の誰かの名前を提案されたレビュー担当者のリスト。これにより、その人は、マージ提案を見るための通知を受け取ります。
4
ピアコードレビュー中に欠陥を分類することの利点/欠点は何ですか
約3か月前に、私たちのエンジニアリンググループはレビューボードを展開し、すべてのピアコードレビューに使用しました。今日、私はそのプロセスに関与している人の1人と話し合ったところ、いくつかの機能が不足しているため、すでに代替品（おそらく何か商業用）を探していることがわかりました。 多くの人から明らかに要求される機能の1つは、各コードレビューコメントを分類/分類する機能です（つまり、スタイルの問題、コーディング規約、リソースリーク、ロジックエラー、クラッシュなど）。 コードレビューを定期的に実践するチームにとって、この分類は一般的な手法ですか？あなたはそれをしますか？過去にそれをしたことがありますか？良い/悪いですか？ 一方で、これはチームにいくつかのより多くのメトリックを提供し、おそらく開発者をトレーニングする必要がある可能性があるより具体的な領域を示します（少なくともそれは議論のようです）。他のメリットはありますか？一方で、これは私の懸念ですが、コードレビュープロセスの速度がさらに遅くなるということです。チームリーダーとして、私はかなり多くのレビューを行い、コードのチャンクを強調表示し、コメントをハンマーで叩き、できるだけ早く進む機能が常に好きでした。私は個人的には試していませんが、そのコンボボックスを毎回展開し、適切なカテゴリをスクロール/検索すると、何かがあなたをつまらせているような気がします。また、これに関するメトリックを維持し始めた場合、
9
職場でクリーンなコーディングを促進するにはどうすればよいですか？
私は社内のアプリケーションで多くのレガシーJavaおよびRPGコードを使用しています。ご想像のとおり、コードの多くはさまざまなスタイルで記述されており、名前が不十分な変数、一貫性のない形式、および矛盾するコメント（存在する場合）のために、多くの場合読みにくくなっています。 また、十分な量のコードは堅牢ではありません。多くの場合、コードは熟練したプログラマーによって迅速に本番環境にプッシュされますが、新しいプログラマーによるコードは、IMOが不十分であるという「コードレビュー」によって妨げられます。（それらは通常、コードの深刻な批評よりも「うまくいく、大丈夫だ」という形をとります。）私たちはかなりの量の生産上の問題を抱えています。私は、元のデザインとテスト。 私はこの会社で約4か月働いており、私のコーディングスタイルについては2、3回褒められています。私のマネージャーはまた、標準よりもクリーンなコーディングのファンです。より良いスタイルとより防御的なコーディングを推進しようとするのは私の場所ですか、それとも私ができる限り最善の方法でコーディングすべきでしょうか？デバッグと変更時間を短縮できますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.