まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
どんな人向けの記事？ レビューによって心理的なダメージを受けやすい方 非エンジニアだが、エンジニアチームがどんな機能を作っているか知りたい方 業務が溜まっていて、レビューに割く時間を捻出するのに苦労している方 コピペできるコードも公開します 初回レビューをAIに任せると、いろんなロールの人の役に立つ レビューは得意ですか？ 優秀なエンジニアしかいないチームであれば、PRは1トピックに絞って小さく明確なコミットによって作成され、適切な要約とともに提供されることでしょう。 しかし、実際にはいろいろな制約から、PRが想定よりずっと大きくなってしまったり、関連トピックと異なるコードが混じってしまうこともあります。 実際のところ、大きなPRを適切にレビューするのは難しいことです。また、自分が詳しくない領域のレビューを行わなければいけない機会もあります。 今回の記事は、レビューを作成してくれるAI C
［速報］「Amazon CodeGuru」発表。機械学習したコンピュータが自動でコードレビュー、問題あるコードや実行の遅い部分などを指摘。AWS re:Invent 2019
Amazon Web Services（AWS）は、米ラスベガスで開催中の年次イベント「AWS re:Invent 2019」の基調講演で、機械学習を用いて自動的にコンピュータがコードレビューをしてくれる「Amazon CodeGuru」を発表しました。 Amazon CodeGuruのコードレビュー機能は、Amazon自身のこれまでの大量のコードと、GitHubで公開されているポピュラーな1万のオープンソースソフトウェアのコードを基に機械学習のトレーニングを行ったモデルを用いて、対象となるコードを解析。 GitHubやCodeCommitのプルリクエストと連係し、問題があるとされた個所には人間に読める形式でコメントをしてくれるというもの。 並列処理や脆弱性の問題あるコードを指摘 例えばAWSにおけるベストプラクティスのコードから外れているものや、並列処理における問題などの指摘。
ChatGPTとは？ OpenAIが開発するGPT-3という言語モデルをベースとした(執筆当時)チャットアプリです。 こちらの質問に対して、AIが色々な質問に答えてくれて、一般的な内容だけではなく、コードレビューやバグなども発見してくれるめっちゃ凄いやつです。 細かい内容は以下の記事がとても参考となります。 筆者の関連記事 VSCodeと連携して、ブラウザを開かなくてもChatGPTを使用できるようにする 通常はブラウザを開いて使用するのですが、コーディング中にサクッとレビューしてもらったり、バグを見つけてもらえるような拡張機能があったので、そちらの設定方法について記述してみます。 今回インストールする拡張機能 使用までの手順 環境 PC: MacBook Pro (Apple M2) OS: macOS Ventura 13.1 VSCode: v1.74.3 OpenAIの価格について
コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
コードレビュー ありがちな問題への対処例 - Crieit
コードレビュー、これまでいろんなプロジェクトで経験して、意外と使われていないノウハウがあったり、風習が違ってつらみがあったりしたので、いろいろまとめてみる。 指摘事項について よくある話 - 駄目コードを憎んで人を憎まず。駄目なのはコードであって人格じゃない - 指摘する人は人格攻撃せずにコードのどこが悪いのかを指摘しましょう - 指摘される人も、言われているのはコードの問題であって人間の問題じゃないので、素直な心で受け止めよう この辺はみんな知ってると思うので略。ぼくが思う大事なルール コードレビューで指摘された内容は、対応必須ではない 理由： 対応必須にすると、「これ言ったらリリースできなくなるよね」みたいな忖度が発生してコメントできない人が出現するから。 絶対ダメとは言わないけど、あまりよくはない、みたいな指摘については、そのときは急ぐからリリースするけど、次回から気をつけるとかがあ
Googleがコードレビューのガイドラインなど、ソフトウェアエンジニアリング実践のためのドキュメント「Google Engineering Practices Documentation」を公開
Googleがコードレビューのガイドラインなど、ソフトウェアエンジニアリング実践のためのドキュメント「Google Engineering Practices Documentation」を公開 ライセンスはクリエイティブコモンズの「表示 3.0 非移植 (CC BY 3.0)」で、複製や再配布、営利目的を含めた改変や翻案が可能になっています。 Googleで一般化されたエンジニアリングプラクティス Googleはこのドキュメントを次のように紹介しています。 Google has many generalized engineering practices that cover all languages and all projects. These documents represent our collective experience of various best practic
はじめに Gitのステージングエリアにあるファイルを対象に、レビュー結果をSlackに通知するアプリケーションを作成しました。 開発環境のターミナルで指定したコマンドを実行するだけで、Slackにレビュー結果が送信されます。 ソースコードは以下です。 こんな人におすすめ コードレビューを受ける前に自分で事前チェックをしたい方 一人でコードを書くことが多く、レビュワーがいない方 どうせなら楽しくレビューしてもらいたい、好きなキャラクターにレビューしてもらいたい方 アプリケーションの構成 レビュー依頼の手順と流れ 以下のような手順と流れでレビュー結果を得ることができます。 レビュー対象のファイルをステージングエリアに登録する（複数ファイルの登録が可能です） ローカルのターミナルでaireviewコマンドを実行 Slackに必要な情報が送信される レビュー結果を確認する スレッドにレビュー結果が
Merpay Advent Calendar 2019 の22日目は、メルペイスマート払いチーム/Backend Engineer の @oinume がお送りします。今日はコードレビューについて自分が普段から実践していることを書いてみたいと思います。 はじめに 世の中にはコードレビューをする時の観点については数多く共有されていますが、より良いコードレビューをするためにはどうするのが良いか、というHOWについてのノウハウはあまりシェアされていないような気がしています。そのため、今日は自分なりに心がけているコードレビューのやり方と、ついでに気をつけている観点について書きたいと思います。 Slackを閉じる (これが本当に一番大事だと思っているので最初に持ってきたのですが)私は極端に集中力がないため、SlackのDesktop通知が来るとついついそれが気になって見てしまいます。コードレビューの
コードレビュー研修
2020/07/21 に弊社新卒向けに実施したコードレビュー研修の資料です。
あるときコードレビューするときにどういうところ見てるんですか？ と訊かれてたしかに自分でもあまり言語化したことはなかったな、と気づいたので簡単に書いておく。 変更意図が要求に沿っているか そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。 モデリングが妥当か モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。 わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。 仕事にあったインタフェースになっているか。テスト
良いソフトウェアとコードレビュー / Good software and code review
Scala + Caliban で作るGraphQL バックエンド / Making GraphQL Backend with Scala + Caliban
https://fortee.jp/phpcon-2021/proposal/5d39aa6d-aef2-4bed-8747-60b6d2f6adfe PHPカンファレンス2021の登壇スライドです
コードレビューの「純粋に質問ですが」は「勝手に指摘だと受けとってよくわからん修正するんだろ？質問なんだよ！修正すんなよ！」という意思表示な説
やきにくのすえなみ @a_suenami コードレビューの「純粋に質問ですが」は表現を柔らかさ目的でなく、「お前は質問だって言わないと勝手に指摘だと受けとってよくわからん修正するんだろ？質問なんだよ！！修正すんなよ！」という意思表示で、むしろ元より殺伐となってる可能性すらあります。 2023-02-13 16:43:45
用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R
はじめに こんにちは。 プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow のエンジニアの藤井です。 エンジニアであれば誰しも日頃からコードレビューをしたり、されたりしていることと思います。 健全な開発組織を育む意味でもレビューの文化を根付かせることはとても大切ですが、小規模な組織の場合「レビューアが足りない」という問題が往々にして起こり得ます。 もちろん、特定のエンジニアにコードレビューが集中してしまうのを防ぐために、チーム全体で負荷分散を図るのが本質的かつ王道的なアプローチではあります。 しかしときには、とにかく個人の力で乗り越える、という状況も避けられないでしょう。 そこで今回はコードレビューの生産性を上げるための Tips をいくつかご紹介します。 自分でも開発をしなければならないが、その片手間で一日に何本ものプルリクエストを確認しなけ
長くなりがちだったコードレビューを改善した話 - 弁護士ドットコム株式会社 Creators’ blog
弁護士ドットコム クラウドサイン事業本部でエンジニアをしている山田です。 主にフロントエンドを担当しています。 普段の業務でフロントエンド開発のコードレビューをすることが多く、今回は長い時間がかかりがちだったコードレビューを以下の施策で改善した話をします。 タスクへの認識合わせを拡充 タスクを小さく分割 類似するタスクのレビュー内容は共有 必要に応じて同期的にレビュー 達成されないスプリントゴール スプリントゴールが達成できない原因 コードレビューが長くなる要因 レビュアーのレビュー期間が長い タスク担当による対応期間が長い 対応策 タスクについての認識合わせの時間を設ける タスクをなるべく小さくする 類似する複数のタスクはレビュー内容を共有 必要に応じてオンラインミーティングなどで画面共有し会話しながら同期的にレビューする スプリントゴールも達成できるように まとめ 達成されないスプリン
＼スニダンを開発しているSODA inc.の Advent Calendar 10日目の記事です!!!／ こんにちは！！！！SODA開発部の矢野です！！！ はじめに 私のチームでは一年前からコードレビューを最優先に実施するという取り組みをしています。この取り組みを継続した結果開発生産性にも良い影響を与えてくれたかもしれないので記事にしようと思います！ ちょうどこの記事を作成しているときにX(旧Twitter)で「PRのレビューを最優先にしたらチームの生産性が上がった」の投稿にたくさんのいいねがついていたので、コードレビューを最優先に取り組んで効果を実感している組織やチームが多いのかもしれないですね。 レビューを最優先にした結果 結果から書くと、 「コードレビューを最優先にする」取り組み前後の「レビューからアプルーブまでの平均時間」を比較すると6.5時間から2.5時間に縮まりました（本当かな
※本記事は2019年1月に公開された内容です。 コードレビューとは、誰かが作成したソースコードを他者がレビューすることで、問題のある記法やバグがないかを確認する作業のこと。プログラムの品質を高めるために、なくてはならない工程のひとつです。 しかし、コードレビューを成功させることは簡単ではありません。読者のなかにも、「同じような指摘を何度もしているのに、メンバーのスキルが向上しない」「つい感情的なコメントをしてしまう」といった悩みを抱えている方は多いのではないでしょうか。 やみくもにコードレビューを実施しては、成功率は上がりません。レビューアーが実施方法やマインドを適切なものに変えなければ、良いコードレビューにはならないのです。 ここでは、コードレビューを成功させるための方法を7つご紹介します。 本記事の監修：高遠和也（株式会社LIG CTO） コードレビューを含む求人の検索はこちら コード
そのコードレビュー、使い捨てになっていませんか？
こんにちは。株式会社プラハCEOの松原です。 どんな人にこの記事を読んで欲しいか コードレビューの効率化に悩んでいる コードレビューのやり方に自信が持てず、何か参考になる事例を知りたい 使い捨てコードレビューに翻弄される日々 1~2年ほど前に自社サービスを開発していた頃、弊社では全てのプルリクエスト（以降PR）に対してランダムに割り当てられたレビュワー2名、もしくはテックリード1名にapproveされない限りマージしない運用で開発していました。開発者が5名ぐらいだったと記憶しているので、規模の割にはリッチなレビュー体制だったのではないでしょうか。 修正点があれば指摘して、直して、再確認して、merge。 来る日も来る日も、確認、指摘、修正、再確認、merge。 次第に「僕ら業務時間の大半をコードレビューに使ってね？」と、レビューに費やす時間が気になるようになってきたあたりで、一度自分たちの
GitHub Next | AI for Pull Requests GitHub Next Project: AI for Pull Requests wants to make GitHub Pull Requests seamless, low burden an... この機能の登場により、PR でのレビューのオーバヘッドを少なくすることが期待されます。この PR では何を変更したのかを説明したり、更には review の依頼を投げることもできます。 また、Issue でも AI にどうしたらよいか？を聞くこともできるそうです。詳しくは公式の動画を見てください。 How many times have you submitted a change and forgot to update the unit tests? Or the documentation? Or introd
Twitterの買収を完了したイーロン・マスクがCEOに就任、テスラから集められた50人以上のエンジニアがTwitterのコードレビューに加わる
2022年10月にTwitterの買収を完了したイーロン・マスク氏が、Twitterの新CEOに就任することが明らかになりました。さらにマスク氏は、自身がCEOを務める電気自動車メーカー・テスラなどのソフトウェアエンジニアを選抜し、Twitterのコードレビューに従事させていると報じられています。 Elon Musk has pulled more than 50 Tesla employees into Twitter https://www.cnbc.com/2022/10/31/elon-musk-has-pulled-more-than-50-tesla-engineers-into-twitter.html Elon Musk, who runs four other companies, will now be Twitter CEO | Reuters https://www
「コードレビュー・・・うっ頭が」となっているそこのアナタへ。 先週弊社キカガクで人生初の実務コードレビュー体験をしました。 控えめに言って最高すぎました。 お互いが「気持ちよく・効率的に」学びを深められるように組まれた一級品のレビュー構成。 細部に渡る心遣いとテクニックの為せる技だと思いました。 そこで私は考えた ー。 真逆のことをしたらどうなるんだろう？ 想像してみたらなかなかブラックな開発環境が脳内で出来上がりました （大学時代のコードレビュー現場そっくりだなと思ったのは内緒）。 自分がコードレビューに参加する時こうはなるまいぞいう戒めを込めて紹介していこうと思います。 具体的な改善案も5選紹介しています。 共に愛され系コードレビュアー ＆ レビューイを目指しましょう！ 想定している対象読者 「もうすぐ初めてコードレビューを受ける予定で不安・・・」 「コードレビューを行うことになったけ
コードレビューのやり方、基礎の基礎 - コード改善に重要なレビューの基本的な考え方を学ぼう - エンジニアHub｜Webエンジニアのキャリアを考える！
コードレビューのやり方、基礎の基礎 - コード改善に重要なレビューの基本的な考え方を学ぼう コードレビューとは？レビューで問題を見つけて指摘するには？レビューをされる側の心構えとは？ソフトウェアレビューを研究する名古屋大学の准教授 森崎修司さんが、コードレビューの考え方を解説します。 はじめまして森崎です。大学でソフトウェアレビューの研究をしています。さまざまな組織との共同研究、調査、議論を通じて、レビューの原理・原則や体系的な考え方・知識を明らかにしようとしています。大学で研究に従事する前にソフトウェアエンジニアとしてインターネットサービスの開発をしていたため、研究として価値があり、実務としても役に立つ研究を目指しています。 レビューは、とにかく多くの経験をつまなければ上達しないという先入観を持たれがちです。その先入観をなくして、レビューの上達やソフトウェア品質の向上につながるしくみや活
余裕を生み出すコードレビュー 〜レビュイー編〜 / code-review-phpcon-2019
PHPカンファレンス2019 LT ブログ記事もあわせてお読みください！ https://tech.connehito.com/entry/heartful-code-review
ソフトウェアの品質を保つためのツールとして、コードの変更点を一度他の人にチェックしてもらうという「コードレビュー」は高く評価されていますが、そのコードレビューにおいて、スムーズにレビューを進めるためのヒントをGoogleがブログに公開しています。 Google Testing Blog: Code Health: Respectful Reviews == Useful Reviews https://testing.googleblog.com/2019/11/code-health-respectful-reviews-useful.html ◆レビューする場合とされる場合の両方において守るべきこと ・相手の能力を尊重する 人が違えば得意分野や背景知識なども異なります。相手には高い能力があるはずだという前提に立ち、まずは質問を通して理解を深めることが大切です。 ・根拠を提示する ベスト
コードレビューの思想や心構え - Qiita
株式会社ブレインパッドでデータサイエンティストをしているasanoです。 この記事はBrainPad Advent Calender 2023 1日目の記事シリーズ2です。 ※シリーズ1は@fuyu_quantさんの入力プロンプトを復元する技術 #ChatGPTです！ 今日はコードレビューの思想や心構えについて書きます。 はじめに コードレビューをより生産的に進めるには単にコーディングのスキルだけでなく、そもそものコードレビューに対する思想や心構えについても一定のリテラシーを求められると考えています。 コードレビューはどうしてもロジカルな話になるため伝え方にも気を付けないとモチベーションの低下に繋がりやすいと考えています。 そうなると当然パフォーマンスも下がってしまいます。 これを防ぐために自分は「コードレビューの思想・心構え」をまとめてチームのガイドラインとして使っています。 あくまで主
コードレビューで気をつけていること 5 選
こんにちはnasaちゃんです。 コードレビューの記事を見かけたので僕がコードレビュー時に考えていること、行っていることを書いてみようと思いました。 この記事ではレビューを受ける側、行なう側それぞれの話がありましたが、ここではレビューを行なう側のことを書いていきます。(洗い出してみるとすべてがレビューコメントに関するものでした。) Whyを書く コードの変更をリクエストする際になぜ変更したほうが良いのかを書くようにしています。 レビュイーが変更を取り込むか判断する材料になるのでちゃんとなぜこっちのコードのほうが望ましいのかを書くようにしています。あと、言語化することで自分の理解も深まるので良いですね。 このとき、レビュー中のコードを批判しないことを心がけています。 「今のコードは〇〇というデメリットがあるので変えたほうが良い」と伝えるよりも「このような書き方をすることで〇〇がよくなると思いま
コードレビュー時のコメントの意図を明確にする
コードレビューあるあるなんですけど、レビューする時に「これってなんでこうしてるんですか？」みたいなピュアなコメントを書いてしまうと、その意図がレビュイーに伝わらなくて、「詰められてる」「コードに疑念を持たれている」「修正依頼をされている」「純粋に質問されている」という解釈のブレを生んでしまって物事が円滑にいかないみたいなことは発生します。 コメントする側からするとただ単に質問しているだけなのにどうして・・・と思いがちなのですが、コードレビューに慣れていない人はこういう重要度や意図がはっきりしないコメントをたくさん書いてレビュイーを困惑させがちというのはあるんじゃないでしょうか。 重要度や意図がはっきりしないコメントを書くのが常になってしまうと、GitHubでPRを出してレビューをしてもらってマージするという開発者が何度も何度も回していくワークフローに滞りが発生してしまう、もしくはそれどころ
こんにちは。ECプラットフォームサービスSREチームリーダーの川崎（@yokawasa）です。本記事では、コードレビューを通じたチームのパフォーマンス向上のための取り組みについてご紹介します。なお、コードレビューそのもののテクニックに関する話はしないので、あらかじめご了承ください。 目次 目次 はじめに コードレビューはチーム全体のパフォーマンス向上のため 複数ユニット、複数チームで行う 活動状況を定量的に評価する コードレビュー体験を向上させる レビュアーの負担を減らす 同期・非同期コミュニケーションを使い分ける 参加しやすい雰囲気を作る 1. 心理的な安全性を高める 2. チームの共通目標にする さいごに はじめに まずはじめに、我々はGitHubのPull Request（以下、PR）機能を活用してコードレビューをしています。下記の記事でも書いているようにIaCとCI/CDを基本ルー
はじめに 新人のころ、先輩からコードレビューを受ける際、よく耳にしたのが、 「うーん、細かいがおれならこう書くよ。まあ、間違ってはないけど」 当初は、そのありがたみがよくわからず、しぶしぶ直していましたが、 今になって、先輩の「細かいけど伝えたい」気持ちがわかったような。 先輩の指摘事項(Python例) シングルクォートか、ダブルクォートか 自分
コドレビューの観点 コドレビューの観点をまとめてみました。チェックリスト的なものになりますた。 機能性 コードが設計通りの機能を有するか？ データの流れ、取得方法は、設計と一致するか？ データのチェックの漏れはないか？ データの生成、修正、加工は、設計と矛盾がないか？ ループの中で更にSQLなど重い処理を発行するなど、パフォーマンスの懸念はないか？ 必要な場合、国際化の対応しているか？ コネクションやリソースは適切な方法で閉じられているか？ NULLとなる場合や値が取れない場合を考慮しているか？ NULLをある程度許容したコードになっているか？ 読みやすさ 名前の付け方は、共通認識の範囲か？ スタイルガイドにそっているか？ ループ、分岐等の処理記述方法は同じか？ コード設計 パラメータ、プロパティなど正しく機能区別されて実装されているか？ インスタンス等の上書き、重複など考慮されているか？
この記事はNuco Advent Calendar 2022の13日目の記事です はじめに 私は情報系の学部に通う大学４年生です。大学でプログラミングを学んだことをきっかけに、プログラミングを使用した実際の業務に取り組んでみたいと思いました。そして、株式会社Nucoさんで機会をいただき、現在インターン生として実務に参加させていただいています。 自分のように、プログラミングを学び、「実務の経験が積みたい」「インターンに参加してみたい」という方はたくさんいらっしゃるかと思います。この記事では自分が実際にインターン生として実務に参加し、コードレビューで指摘されたポイントを紹介します。 難易度、頻出度の目安を★の数で示しています。 ・難易度・・・それぞれの項目で指摘されないようなコードを書く難しさ。 ・頻出度・・・それぞれの項目のミスの起きやすさ。 難易度(低→高)、頻出度(高→低)の順番で紹介し
React18 設計とコードレビューの観点
はじめに 最近チームに React 18 を布教することの多い osuzu です。 普段の業務で、ペアプロ時に設計意図を伝えたり、コードレビューで都度自分の意図を伝えたりしてきました。 今回、これまでのチーム開発の経験やドキュメントに目を通す中で、自分が良いと考えている設計やコードレビューの観点を言語化することが出来てきたので、筆を執ってみました。 この記事はコードレビューの観点をチーム内へ知見共有するために書きましたが、社内に閉じる必要もない内容のため、Zenn でオープンに公開することにしています。 設計部分はプロジェクト（チーム）に依存していることが多く参考にしにくい部分もあるかもしれませんが、この記事がコードレビューや設計ガイドラインのような形で少しでも参考になれば幸いです。 記事の対象外 コードレビューそのものの基準や観点は取り扱いません。下記記事など適宜参考に。 Google
Developer Enablement Monthと、そこから生まれたコードレビュー手法｜Knowledge Work Developers blog
こんにちは、よしこです。 みなさんコードレビューしてますか？ 今日の記事では、最近おこなわれた社内でのイネーブルメントを推進する取り組みと、そこから生まれた新たなコードレビューのやり方についてご紹介しようと思います。 コードレビューにおけるトレードオフ取り組みやレビュー手法の話をする前に、前提としてコードレビューの際に以前から私が持っていた悩みをお話しします。 （以降レビューする人をレビュアー、される人をレビュイーと記載します） ナレッジワークのフロントエンドチームでは私が主なレビュアーとしてコードレビューをしているのですが、その際に1つ悩ましいトレードオフがありました。 これはレビュアーにもよるかもしれないのですが、私の場合は「全体像を見てレビューしたい」という方針があります。 「ある振る舞いを実現するコードのうち一部だけのコード」よりも「ある振る舞いを実現するコード」をまとめてレビュー
XP祭り2020 #xpjug で発表した内容です。 コードレビューが教育に良い理由と、 更に効果を高めるTipsを紹介しました。
コードレビュー 開発者ガイド
コードレビュー 開発者ガイド はじめに コードレビューとは、コードの作者以外の誰かがそのコードを確認するプロセスです。 Google では、コードと製品の品質を確保するためにコードレビューを活用しています。 このドキュメントは、Google のコードレビューのプロセスとポリシーに関する正式な説明です。 このページは、コードレビューのプロセスの概要となっています。このガイドは、次の2つの大きなドキュメントからなります。 コードレビューの方法: コードレビュアのための詳しいガイドです。 CL の作者のためのガイド: コードレビュー対象の CL を作成する開発者のための詳しいガイドです。 コードレビュアは何を期待するべきか？ コードレビュアは、以下の点について確認しなければなりません。 設計: コードはよく設計されており、あなたのシステムにとって適切なものですか？ 機能: コードは作者が期待して
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビューの目的と考え方 - osa_k’s diary
コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
もう初回コードレビューはAIに任せる時代になった - CodeRabbit -
VSCodeにChatGPTの拡張機能を入れてコードレビューやバグを発見してもらう - Qiita
設計/コードレビューで"常に"心がけるポイント - little hands' lab
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
もう初回コードレビューはずんだもんに任せる時代になった
より良いコードレビューをするために気をつけていること | メルカリエンジニアリング
コードレビューのときに見ているところ - 詩と創作・思索のひろば
【IMO】コードレビューって難しいよね.pdf
コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せ
コードレビューの生産性を上げるためのTips | Offers Tech Blog
チームで1年間コードレビューを最優先に実施したら開発生産性に良い影響を与えてくれたかも
コードレビューを成功させるには？ CTOが考えるべき7つのこと│監修：高遠和也（株式会社LIG CTO） - FLEXY（フレキシー）
コードレビューをAIに手伝ってもらい楽をしてみる - hiroppy's site
コードレビューで嫌われる人の特徴7選 - Qiita
Googleがコードレビューにおいてスムーズにコミュニケーションを進めるための注意点を公開
コードレビューを通じたチームパフォーマンス向上のための取り組み - ZOZO TECH BLOG
細かいけど伝えたかった先輩のコードレビュー - Qiita
コードレビューするときの観点 - Qiita
知らないと恥ずかしいコードレビューで指摘されがちなポイント14選 - Qiita
コードレビュー地獄から�抜け出すためのペアプロ育成法��〜学習科学の視点から〜 #xpjug