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

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

7
内部の代表者、投票、バッジは、優れたプログラミングの実践を促進するでしょうか？
声を出して考えてみてください-私たちのプログラマーは投票/バッジ/担当者が好きなので、このようなスキームを企業のコードレビュープロセスに導入して、より良いコーディングを奨励できます。 何かのようなもの あなた（またはあなたに代わって他の人）は、コードレビューのためにレビュー（スニペット、シングルコミット、または一連）を投稿できます。 他の人はそれについてコメントすることができます（SEの回答に似ています） バッジを与える/提案することができます（一部は良いもの、一部は「Comment Desert」などのように悪いもの） コード自体とコメントとバッジに賛成票または反対票を投じることができます（例：誰かがバッジを提案し、あなたが同意した/同意しなかった場合） このようなスキームの目的は コードレビューの使用を促進するために、ちょっとした楽しみを紹介します 品質の向上（このスキームでは、コードのレビュー対象者とレビュー担当者の両方が学習する可能性が高い） コードレビューが「自我戦争」を引き起こす可能性を減らす 個々のパフォーマンスの測定に役立つメトリックを提供します これは機能しますか？考え？
7
プログラマーがコードレビューを処理する最善の方法は何ですか？
私はコードレビューはかなり新しいですが、博士号を取得している間は何年もコーディングを行ってきました。 レビュアーがコードを変更し、1行ずつコードを検討する場合、同意しない場合はどうしますか？Xを選択し、レビュアーがそれをYに変更し、Yを思い浮かべていたが、デメリットのためにそれを行わないことに決めたことがありますが、レビュアーはこれらのデメリットは重要ではないと断言します。意見の不一致を言葉で表現するべきでしょうか、それともそうではなく、それらに耳を傾けるべきでしょうか？ 批判を受け入れるのが苦手で、レビュアーが組織の上級者である場合は困難です。防御的すぎると出くわすのは良くありません。
8
一般的なコードレビュープロセスとは何ですか？
私の会社は最近、正式なコードレビューを開始しました。プロセスは次のようになります：githubに送信し、プルリクエストを要求し、約3人がコードをレビューし、すべてのパスが完了したらコードを入力します。 このプロセスは公平に思えますが、コードレビューを行う3人は公平ではないようです。レビューのためにコードを挿入すると、100〜200のコメントが表示されます。私にとって一番の数は一度300コメントでした。もちろん大きな変更だと思うでしょうが、これは50行未満のコード（ユニットテストを含む）でも非常に小さな変更になる可能性があります。すべてのコメントは「やらなければならない」と見なされ、議論はありません。 それを念頭に置いて、ここでの私の主な問題は、それが少し過剰に見えることです。私はグループと話をしましたが、彼らは基本的に、PHPで長年開発してきたからといって、「開発者」であるという意味ではないと言っていました。もちろん、これはそうでないことよりも痛いようです。また、グループ内ではあまりコメントを生成していないようであり、ほとんどの場合、他のコメントや提案を無視したり、無視したりします。 私の質問は、これが公平かどうかです。それとも普通ですか？
3
コードコメントのみを使用するコードレビューは良いアイデアですか？
前提条件 チームはDVCSを使用します IDEはコメントの解析をサポートしています（TODOなど） CodeCollaboratorのようなツールは予算的に高価です gerritのようなツールはインストールするには複雑すぎるか、使用できません ワークフロー 著者は中央リポジトリ機能ブランチのどこかに公開しています レビュー担当者が取得してレビューを開始します 質問/問題レビューアの場合、「REV」などの特別なラベルを付けてコメントを作成します。そのようなラベルは、製品コードに含めることはできません-レビュー段階でのみ： $somevar = 123; // REV Why do echo this here? echo $somevar; レビュアーがコメントの投稿を完了すると、愚かなメッセージ「comments」でコミットし、プッシュバックします 作成者は機能ブランチをプルバックし、同様の方法でコメントに回答するか、コードを改善してプッシュバックします 「REV」コメントがなくなると、そのレビューは正常に終了したと考えることができます。 作成者は機能ブランチをインタラクティブにリベースし、それを押しつぶしてそれらの「コメント」コミットを削除します。これで機能をマージして、通常は内部レビューが正常に完了した後のアクションを開発または実行する準備ができました IDEサポート 私は、カスタムのコメントタグがEclipseとNetBeansで可能であることを知っています。確かにそれはblablaStormファミリーにもあるはずです。 ご質問 この方法論は実行可能であると思いますか？ 同様のことを知っていますか？ それで何を改善できますか？
7
他の人のコードを学習するプロセスをどのように説明すればよいですか？（請求書発行の状況で。）[終了]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 編集：ジャスティン・ケイブは、この種のコミュニケーションが私の引用/見積もりで前もってあるべきであるという良い点を指摘しました。この場合、「既存のコード学習」アクティビティを記述するために人々がどのような言語を使用しているかを知りたいと思っています。特に、以前にソフトウェア請負業者と取引したことがない会社にとって。 編集を終了 大企業向けに社内ソフトウェアをアップグレードする契約を結んでいます。同社は、複数の機能追加といくつかのバグ修正を要求しています。これは私の最初のフリーランススタイルの仕事です。 まず、アプリケーションがどのように機能するかを理解する必要がありました-私はユーザーであるかのようにそれを学びました。 次に、ソフトウェアがどのように機能するかを学ぶ必要がありました。広い概念から始め、必要な詳細に絞り込んでから、各バグ修正と機能に取り組みました。 少なくともプロジェクトの開始時には、既存のコードを学習するのに、追加機能を書くよりもはるかに長い時間がかかりました。 請求書の既存のコードを学習するプロセスをどのように説明できますか？（会社のこの部分は通常社内で仕事をしているので、私のようなソフトウェア請負業者との取引経験はあまりありません。他の人のコードを学ぶオーバーヘッドを理解できないかもしれません。）実際の機能のアップグレードに学習時間を追加したくありません。これは、場合によっては「単純なタスク」に時間がかかりすぎるように見えるためです。請求書を関連するステップに分割し、自分のコードを追加する前に他の人のコードを学習するための大きなオーバーヘッドを請求していることを伝えたい。 ジョブの請求時にこの種のアクティビティを記述する標準的な方法はありますか？
4
TimeZoneに基づいてDateTimeを保存するためのベストプラクティス
ユーザーがTimeZoneに基づいて予定をスケジュールできるWebアプリケーションを開発します。そして、ユーザーの予定日時をサーバー日時としてデータベースフィールドに保存しています。スケジュール情報を表示しながら、データベースから値を取得し、ユーザーtimzoneに変換しました。コードベースでの処理ユーザーのタイムゾーンに基づいてDateTimeを変換しています。このベストプラクティスなのか、それとも簡単な方法が存在するのか教えてください。
5
正式なコードレビューを実施する際に役立つ考え方
当社のチームは最近、各チェックインに対してコードレビューの実施を開始しました。 チームのリーダーとして、私はあまりにも多くの提案を提供し、開発者をいらいらさせ、チームの出力を減らし、コードを手放すというバランスを見つけようとしています。 有用なアプローチを示唆する、よく知られた情報源からの証拠、研究、またはガイダンスはありますか？
4
プルリクエストの作成者がマージする必要があるコードレビューワークフロー
私の会社のいくつかのチームは、今まで見たことのないコードレビューワークフローを実践しています。会社全体の一貫性を保つことには価値があるという考えで、その背後にある考え方を理解しようとしています。（私は複数のコードベースに貢献しており、過去の違いにつまずいたことがあります。） コード作成者がプルリクエストを送信する レビュアーはコードを調べます レビュー担当者が承認すると、「よさそうだ、気軽にマージしてください」という行に沿ってコメントを残します レビューアに懸念がある場合は、「マイナーな問題XおよびYを修正してからマージしてください」などのコメントを残します（大きな変更については、手順2に戻ります） コードの作成者は、必要に応じて変更を加え、自分のプルリクエストをマージします 次の懸念事項があります。 ステップ3での承認の場合、このワークフローはプルリクエストの作成者に対して一見不必要なラウンドトリップを作成します。すでにコードを見ているレビューアは、ただちにコードをマージできます。 ステップ3で変更が要求された場合、プルリクエストをマージする機関は、PRの作成者のみに任されています。著者以外の誰も、マージする前に変更を見ません。 このワークフローのその他の長所と短所は何ですか？このワークフローは他のエンジニアリングチームで共通ですか？
5
コードレビューを行うタイミング
最近、スクラムプロセスに移行し、スプリント内のタスクとユーザーストーリーに取り組んでいます。コードを頻繁にレビューして、手間を軽減したいと考えています。ユーザーストーリーレベルでそれらを行うことを考えていますが、これを説明するためにどのようにコードを分岐させるのかわかりません。 VSとTFS 2010を使用しており、6人のチームです。 現在、機能の分岐を行っていますが、スクラムの分岐への変更に取り組んでいます。 現在、シェルフセットを使用しておらず、他に利用可能な技術がある場合は実際に実装したくありません。 ユーザーストーリーごとにコードレビューを実装することをどのようにお勧めしますか？
4
コードレビューと単体テストの実践を推進する
コードレビューと単体テストの経験がない（そして必要がない）開発者グループを管理するチームリーダーとして、コードレビューと単体テストの実践をどのように進めることができますか？ コードレビューと単体テストが開発者のフローに自然に適合するように、どのように方法を作成しますか？ これら2つの領域の抵抗の1つは、「私たちは常に日付変更に厳しいため、コードのレビューと単体テストの時間がない」ということです。 コードレビューに対する別の抵抗は、現在どのようにそれを行うかわからないということです。チェックインごとにコードを確認する必要がありますか、それとも特定の日にコードを確認する必要がありますか？
6
クリーンコード-リテラル1を定数に変更する必要がありますか？
マジックナンバーを避けるために、リテラルに意味のある名前を付ける必要があるとよく耳にします。といった： //THIS CODE COMES FROM THE CLEAN CODE BOOK for (int j = 0; j < 34; j++) { s += (t[j] * 4) / 5; } -------------------- Change to -------------------- int realDaysPerIdealDay = 4; const int WORK_DAYS_PER_WEEK = 5; int sum = 0; for (int j = 0; j …
5
コードレビューが配信/テストサイクルに遅れている
アジャイルプロセスには2週間のスプリントがあります。タスクは毎日配信され（毎日ビルド）、テストチームは翌日または同じ日にテストを完了します。 Devコードレビューもありますが、これには時間がかかります（1〜2時間）ため、週3回、月曜日から水曜日にスケジュールされます。開発者が集まり、コードを改善/リファクタリングする方法を提案します。 問題は、コードレビュー後にアクションアイテムが登場するまでに、ほとんどのタスクが既にテストされていることです。テスターは、既にテストに合格したものを再テストしたくない。内部の開発者の変更を気にしません。 アジャイルプロセスを誤解していますか？コードレビューは毎日のリリース/テストサイクルと互換性がありませんか？毎日コードレビューを行うことはできません。すべての人の時間がかかるからです。
1
ペアプログラミングは、エクストリームプログラミング（XP）プロジェクトでのコードレビューの必要性を排除しますか？
極端なプログラミングプロジェクトでは、プログラマはほとんどの場合ペアプログラミングを行います。 これらのペアも回転するため、つまり、プログラムをさまざまな人とペアにし、集団所有権の感覚があるため、ソースコードは頻繁にレビューおよび更新されています。 そうであれば、コードレビューが必要ですか？つまり、プログラミングを停止し、実際にコードレビューを行うだけです。
5
レビューするコードを選択するにはどうすればよいですか？
私は小さなソフトウェア会社の7人の開発者のチームの一員であり、定期的なグループコードとデザインレビューを紹介しようとしています。過去にいくつかのレビューを実施しましたが、散発的です。もっと定期的なものにしたいと思います。 私はコードコンプリートや他の類似のリソースを読んでいると、彼らはの力学について話どのようにコードレビューを実施することが、私は、選択する方法上の任意のベストプラクティスを見つけることができなかったものを確認することを。8年以上前のコードベースがあり、さまざまな言語をカバーしているので、見ることができるものがたくさんあります。 以下は、選択に影響を与える可能性のあるいくつかの要因です。 言語：C、Java、SQL、PL / SQL コード年齢：新しいコードと古いコード コードの使用：頻繁に使用されるコードと（効果的に）デッド/ほとんど使用されないコード コードの重要性：重要なコードと重要でないコード 開発者：ジュニア開発者コードとシニア開発者コード これは絶対的な決定的な答えを伴う質問ではないことを理解していますが、ガイダンスがあれば役に立つでしょう。 周辺に関連するいくつかの質問： コードレビューのアプローチ（重要なセクションと新しい開発者コードをレビューするという意味） すべてのコードをレビューする必要がありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.