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

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

4
プルリクエストでTODOを処理する方法
この質問は、Software Engineering Stack Exchangeで回答できるため、Software Quality Assurance＆Testing Stack Exchangeから移行されました。 昨年移行し ました。 プルリクエストの変更を確認すると、「TODO」のメモが付いたコメントに出くわすことがあります。 問題を解決するために使用されるソリューションは改善できますが、かなりの時間投資が必要になります。作成者はより迅速なソリューションを選択しましたが、より良いオプションが潜在的に利用可能であるというコメントを入れました すぐに修正する必要がある既存のバグを回避するための一時的なコードがあります TODOsが一般的にコードベースの存続期間中コードベースに留まることを知っているので、プルリクエストでそれらにどのように対応する必要がありますか？どうすればそれを避けるよう丁寧に要求できますか、またはそれが本当に正当化された場合、PRの作者が将来それをフォローアップすることをどのように確認できますか？
10
悪いコードベースでアプリケーションが構築されていることを証明する方法は？
私は現在、私の仕事で以前働いていたいくつかの開発者によって構築されたシステムをレビューしています。システムはユーザーの観点からはかなりうまく機能しますが、コードレビューを掘り下げると、まったく混乱します。私は、アプリケーションの構築方法が将来の更新に耐えられず、使用量が大幅に増加することはないと確信しています。 問題は、それがどれほど悪いかは知っているが、上司はそうではないということです。マネージャーにそれを証明して問題を実際に確認し、現在のコードベースで最小限のトリアージを行い、近い将来、アプリケーションの次のバージョンの新しい開発ラインを開始できるようにするにはどうすればよいですか？
4
一人のプログラマーのためのアプリケーション/コードレビュー？
「リーズナブルな価格で」アプリケーションに関する優れた技術的なアドバイスを提供するサービスはありますか。多くのプロジェクトでは、私は通常、唯一の開発者です。時には、作業の一部を効率化、MVCインタラクションの改善などのために改善する必要があると思います。そのようなレビューを行います
6
最短時間のレビューのためにコードを文書化するにはどうすればよいですか？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 去年閉鎖されました。 数か月後にコードの読み取りと閲覧を最小限に抑えるようにコードを文書化したい。 さまざまな種類のドキュメントがあることを知っています（ソースコードと外部、シーケンス図など）。 コードを効率的に文書化する方法を知りたいので、数か月後にコードを確認したいとき、コードの読み取りとコードフローの理解に費やす時間が少なくなります。
3
機能ブランチからマスターにマージする前のコードレビューの戦略
私と私のチームは機能ブランチを使用しています（gitを使用）。マスターにマージする前に、コードレビューの最適な戦略はどれかと思います。 マスターから新しいブランチをチェックアウトし、fb_＃1と呼びます 私は数回コミットし、それをマスターにマージしたい 私がマージする前に誰かがコードレビューをすることになっています 現在、2つの可能性があります。 1日 私はマージ＃1 FB_するマスターを（いない最新のできるだけそれを作るためにマスターにFB_＃1） チームメイトがマスターヘッドとfb_＃1ヘッド間の変更を確認します fb_＃1で問題なければ、fb_＃1をマスターにマージします 長所：廃止されたコードはレビューされていません 短所：他の誰かが「1」の間に何かをマージする場合 および「2.」彼の変更はレビューに表示されますが、別のレビューに属します。 2番目 チームメイトがチェックアウト（git merge-base master fb_＃1）とfb_＃1 headの間の変更をレビューします 長所：機能ブランチでの作業中に変更された内容を正確に把握できます 短所：一部の古いコードがレビューに表示される場合があります。 あなたはどちらの方が良いと思いますか、なぜですか？別のより適切なアプローチがありますか？
3
GithubのようなGithubのような「プルリクエスト」
私は金融機関のアナリストとして働いています。金融機関はデータの機密性のため、クラウドにデータを保存しません。ただし、コード管理にGitを使用してチームを成功させることはできました。私たちのサーバーにGithubのようなプルリクエストを実装する方法があるかどうか疑問に思っていました。私が興味を持っている特定の機能は、特定のブランチに実際にマージせずに、コメントの変更セットを送信する機能です。（1）変更を送信し、（2）変更をレビューしてコメントし、（3）コミットを受け入れるか拒否するかのワークフローが好きです。これを独自のサーバーに実装できますか（さらに良いことですが、簡単に実装できますか）。
21 git  code-reviews 
17
基本的なルールに従うようにプログラマーを説得する方法
この質問はして移行され、それがソフトウェア工学スタック所に答えることができるので、スタックオーバーフローから。 8年前に移行され ました。 プログラマーに非常に頻繁に従うことを求めなければならないいくつかのルールがあります。彼らはコードを書き、それがうまくいけば、仕事は完了です。最も基本的なルールは次のとおりです。 変更をコミットする ビューまたはコントローラーでモデルの問題を記述しない ハードコーディングを避ける あなたの経験を教えてください。これをどのように管理しますか？
9
コードレビューは良いことだと上司を説得するためのヒント[非公開]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 たとえば、プロジェクトでほとんど一緒に働いていない開発者が数人いる架空の会社で働いていて、上司がコードレビューに時間と費用の価値があるとは考えていなかったとします。 コードレビューの利点を描写するこのシナリオで提示できるさまざまな議論は何ですか？さらに、ここでのコードレビューに対する潜在的な議論は何であり、これらにどのように対抗できますか？
4
経験の浅いプログラマーのコードを修正するにはどうすればよいですか？
少しのバックグラウンド：私は10人の部門の2人のプログラマーのうちの1人です（残りはアーティストと管理職です）。私たち2人は、物事を順調に進めるために必要なすべてのコーディングを行い、出てくるプロジェクトを開発します。私は約4年前からプログラミングを行っていますが、これが彼の最初の「本当の」仕事です（彼の言うとおりです）。通常、私たちはいつでも異なるプロジェクトに取り組んでいます。 数か月前、私は後のプロジェクトで使用するクラスのセット（決して完璧ではない）を開発しました。そのプロジェクトの大部分は、GUIインターフェースを設計およびプログラムするために（請求のため）彼に委任されました。彼は新しいので、私は設計を少し手伝い、残りの部分で必要な場合は助けを求めるように言いました。彼は数週間前にインターフェースを完成させましたが、それは少し遅いですが、それが機能することを示すためにデモしました。 私が取り組んでいるプロジェクトの次の部分は始まっています。次のステップから始めるためにインターフェースを開いたところ、すぐに問題にぶつかりました（少し遅かったのは、控えめな表現、一般的なアクションのエラーなどでした）。いくつかの問題についてコードを調べ、エラーチェックのないタイプの仮定（Pythonにあります）、元のコードに追加されたGUIへの参照などを見つけるO(n^n)必要がO(n)あります。 今、私は間違いなく彼に何が間違っていたのか、どのようにそれを修正するのかを教えたいと思っていますが、彼はすでに次のプロジェクトに移っており、これは数週間前でした。「戻って正しいことを！」と言って怖いです。（もちろん助かります）厳しすぎるので、その間にやるべき他のプロジェクトがまだあります。私は今のところ自分でコードを修正し、将来的に物事をキャッチしようとする必要がありますか？
19 code-reviews  bug 
5
標準コードレビューには何が含まれていますか？
私の会社では、どの機能が実装され、どのようなバグが修正されるかについて、コードを書いた人によって送信されたメールでの議論です。そして、メールを受け取ったレビュアーは、コードをレビューし、自分の意見でコードの品質と編集方法を議論します。標準コードレビューには何が含まれていますか？
5
コードが「間違っている」必要がある場合、レビュアーとして何をすべきですか？
私は、数ヶ月前に必須のコードレビューが導入された、設計が不十分でオーバーエンジニアリングされたプロジェクトで働いています。 新しい機能を実装するコードのかなりの部分をレビューするように頼まれました。コードベースの他の部分と同じ欠陥があります。私は、これらの欠陥が新しいコードに忍び込むことを大いに理解しています。ひどく設計されたクラスから継承するか、互換性を保持しながらひどく設計されたインターフェイスを実装する必要があるため、コードベースの半分を書き直さずに、はるかに優れたソリューションを提供することはできません。しかし、エンジニアリングの観点からは、すでに壊れているコードベースに対して、それをさらに壊していることは役に立たないと思います。私がレビューしているコードは間違いなく悪いですが、機能を実装する場合はそうでなければなりません。 この特定のレビューに関して、どのように振る舞うべきですか？誠実さを維持し、建設的であり続ける方法はありますか？ この文脈でのコードレビューの境界について尋ねていることに注意してください。この問題は組織や仕事の文化などの他の要因によって引き起こされることは承知していますが、私が知りたいのはレビュー自体の処理方法です。
3
うまく機能していても、シニアや上司と一緒にプログラムを見直すのは良いことですか？
私の会社では、プロジェクトを実施する前に、上司は先輩に私や他のチームメンバーによって書かれたプログラムをレビューするように依頼します。 知識を得るには良い方法だと思いますが、プログラムがうまく機能していると、レビュー後も同じように機能しない場合があり、プログラムをもう一度調べる必要があります。 彼らは、レビューがプログラムとクエリの実行を最適化するのに役立つと言いますが、プログラムの実際の機能よりも最適化を好むことができますか？
12
すべてのコードをレビューする必要がありますか？
私たちは現在、開発プロセスを修正しており、コミットの100％をピアレビュー済みにしておくべきかどうか疑問に思っています。 コードレビューに関するあなたの経験は何ですか？ あなたはそれらに「多くの」時間を費やす傾向がありますか（1日あたり1/2時間と言ってください）、それとも最大5/10分のスキムオーバーですか？ 1日/週/スプリント/プロジェクトごとに費やす時間は決まっていますか？ 最も重要なことは、コードの100％がピアレビューされることを目標とすべきか、または100％が必要ではないと思いますか？
2
Mercurialを使用したコードレビューの推奨プロセス
通常はPerforceとSmartBearのCode CollaboratorをBig Corp使用していましたが、特定のプロジェクトではMercurialを使用する予定です。 Code CollaboratorはMercurial（バージョン5を使用しています）をサポートしており、コードレビューの最適な時間（サーバーへのコミット/プッシュ中）プロセスが最適な時間であるかどうかを判断しようとしています。 ありがとう
5
リリースフィーバー中に効率的なコードレビューを行う方法
リリースの締め切りは明日です。同僚はこのリリースに不可欠なタスクをやっと完了しました。プロジェクトマネージャーは肩越しに立ち向かい、最終的にビルドを作成するように促しました。重大なものではありませんが、明日リリースされなければ、手放せないものです。そして、事態を悪化させるには、できるだけ早く終了するために必要な自分の仕事があります。それで、あなたは何をしますか？プレッシャーにも関わらず異議を申し立てますか、それともこれを滑らせますか？ 私が見つけた1つの方法は、このコミットを別のブランチに一時的にマージし、後で確認できるようにすることです。問題が表面的なものであり、コードレビューを待っている唯一の問題である場合に機能します。しかし、これを処理するより効率的な方法はありますか？たとえば、コードレビューとテストのみを1人で行うことをお勧めしますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.