まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
Google エンジニアリング・プラクティス ドキュメント このページは、Google Engineering Practices Documentation の非公式な日本語翻訳です。元のドキュメントは、クリエイティブ・コモンズの「CC-By 3.0」ライセンスで公開されています。 Google には、あらゆる言語・あらゆるプロジェクトをカバーする一般化されたエンジニアリング・プラクティスが数多く存在します。こうしたドキュメントは、私たちが長年に渡って開発してきたさまざまなベストプラクティスの経験が集結したものとなっています。オープンソース・プロジェクトやその他の組織でも、こうした知識から恩恵を受けられるかもしれません。そのため、私たちは可能な限り、この知識を公開するように努めています。 現在、以下のドキュメントが公開されています。 Google コードレビューガイドライン (Googl
レビューの仕方
Open8 勉強会で発表したレビューの仕方と心理的安全性の話しです。
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
［速報］「Amazon CodeGuru」発表。機械学習したコンピュータが自動でコードレビュー、問題あるコードや実行の遅い部分などを指摘。AWS re:Invent 2019
Amazon Web Services（AWS）は、米ラスベガスで開催中の年次イベント「AWS re:Invent 2019」の基調講演で、機械学習を用いて自動的にコンピュータがコードレビューをしてくれる「Amazon CodeGuru」を発表しました。 Amazon CodeGuruのコードレビュー機能は、Amazon自身のこれまでの大量のコードと、GitHubで公開されているポピュラーな1万のオープンソースソフトウェアのコードを基に機械学習のトレーニングを行ったモデルを用いて、対象となるコードを解析。 GitHubやCodeCommitのプルリクエストと連係し、問題があるとされた個所には人間に読める形式でコメントをしてくれるというもの。 並列処理や脆弱性の問題あるコードを指摘 例えばAWSにおけるベストプラクティスのコードから外れているものや、並列処理における問題などの指摘。
Original article:https://dev.to/dotnetsafer/rip-copy-and-paste-from-stackoverflow-trojan-source-solution-4p8f その昔コピペできない文章というものがありました。 実際は単にフォントを変えているだけというものですが、人間の目に見える文字と実際の文字が異なることを利用した攻撃の一種と見ることもできます。 さて、最近になって似たような攻撃に関する論文が公開されました。 人間には見えない文字を織り交ぜることによって、一見問題ないコードが実は脆弱になってしまうというものです。 ただ論文は堅苦しいうえに長くて読むのがつらいので、具体的に何がどうなのかよくわかりません。 平易に解説している記事があったので紹介してみます。 以下はDotnetsafer( Twitter / GitHub / Web
コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
The Gopher character is based on the Go mascot designed by Renée French. はじめにTIG DXユニット 1の真野です。 コードレビューについては3,4年ほど前に、コードレビューにおけるレビュアー側のアンチパターン って記事を書いたりもしました。当時はレビュアーの伝え方って大事だよなって話をしてました。いつしかレビュイーからレビュアーに比重が変わることが増えてきました。相互レビューは当たり前にしていますがが、比較的こうしたらもっと良くなるんじゃないかな？と提案される回数より、自分が提案する回数の方が増えてくるタイミングってありますよね？ そういうわけで、最近Goで主にバックエンドのWebAPIや、AWS Lambdaで動くETLアプリ、たまにCLIツールを開発する時に、2回以上同じ指摘したコメントをまとめてます。Go言語
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
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
Merpay Advent Calendar 2019 の22日目は、メルペイスマート払いチーム/Backend Engineer の @oinume がお送りします。今日はコードレビューについて自分が普段から実践していることを書いてみたいと思います。 はじめに 世の中にはコードレビューをする時の観点については数多く共有されていますが、より良いコードレビューをするためにはどうするのが良いか、というHOWについてのノウハウはあまりシェアされていないような気がしています。そのため、今日は自分なりに心がけているコードレビューのやり方と、ついでに気をつけている観点について書きたいと思います。 Slackを閉じる (これが本当に一番大事だと思っているので最初に持ってきたのですが)私は極端に集中力がないため、SlackのDesktop通知が来るとついついそれが気になって見てしまいます。コードレビューの
あるときコードレビューするときにどういうところ見てるんですか？ と訊かれてたしかに自分でもあまり言語化したことはなかったな、と気づいたので簡単に書いておく。 変更意図が要求に沿っているか そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。 モデリングが妥当か モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。 わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。 仕事にあったインタフェースになっているか。テスト
ITエンジニア志望者にとって、時に「避けては通れない道」となるコーディング選考。実際に人気企業では、どのような試験や採点が行われるのだろうか。今回はLINE株式会社の協力の下、外資就活ドットコムの会員が参加（＊1）する模擬コーディング試験を開催。LINEが実際の選考で出すような問題を、参加者に解いてもらった。 その解答内容を題材に、LINEの新卒採用でコーディング試験を担当する大澤和宏さんと、特別ゲストのAtCoder高橋直大社長の対談を実施。2人の言葉から、「良い解答」「そうでない解答」の差、そしてコーディング選考と競技プログラミングの違いなどが見えてくる。【藤崎竜介】 ＊1 AtCoderで中級者とされる茶色もしくは緑色レベル、かつ2024年卒業予定の学生を対象に参加者を募集（AtCoderのランクについては、公式ページで詳細を確認できる） 〈Profile〉 写真左／高橋直大（たかは
Google Engineering Practices Documentation Google has many generalized engineering practices that cover all languages and all projects. These documents represent our collective experience of various best practices that we have developed over time. It is possible that open source projects or other organizations would benefit from this knowledge, so we work to make it available publicly when possibl
コードレビューの「純粋に質問ですが」は「勝手に指摘だと受けとってよくわからん修正するんだろ？質問なんだよ！修正すんなよ！」という意思表示な説
やきにくのすえなみ @a_suenami コードレビューの「純粋に質問ですが」は表現を柔らかさ目的でなく、「お前は質問だって言わないと勝手に指摘だと受けとってよくわからん修正するんだろ？質問なんだよ！！修正すんなよ！」という意思表示で、むしろ元より殺伐となってる可能性すらあります。 2023-02-13 16:43:45
私は長年 Pull Request のコメント数が多くて何回もレビューを往復することが多くて大変つらかったが最近ものすごく単純なコツに最近きづいたのでそのことをシェアしようと思う。 Pull Requestレビューの悩みこれはならない人はならないので、共感してもらえる人は少ないかもしれないが自分の悩みは Pull Requestのコメント数でこれが本当に多い。何がつらいって、レビューのコメントが多いという事は、マージに時間が掛かるということだ。最初にコードを書いてテストして完成させるのは２時間もかかってないのに大抵レビューで何往復もして時間を取られるのが本当につらいし、進捗がでないもの嫌だし、時間かかるし、自分が最近解決したい問題の中でも筆頭の問題だった。 何が悪いのだろう？すごく嫌なので物凄く考えたがうまくいかなかった。例えば、英語のスペルミスも良くしたし、ログやコメントの英文にレビュー
人の作ったWebアプリケーションのコードを見るときに注目しているところ - Runner in the High
普段見ているものをなんとなく書き出してみた。 インターフェイス あえてやってないとか、レイヤ的にやる必要がないというケースもある。しかし、ある程度の規模のソフトウェアには大抵インターフェイスが現れる。インターフェイスがないコードはユニットテストもないことが多い。したがって、インターフェイスが現れないコードは責務分離が行われてない可能性を感じたりする。 言語機能上インターフェイスがない動的型付け言語の場合には、ダックタイピングを意識したコードが書かれているかをチェックする。ダックタイピングでなくとも、例えばRubyだったら抽象クラスと実装クラスの分離が行われているかを見たりする。 バリデーションロジック すべてのバリデーションが、フレームワークの機能で実装されてたりしないかをチェックする。MVCとかクリーンアーキテクチャ的な実装であれば、それぞれのレイヤでどういうバリデーションをしているのか
そのコードレビュー、使い捨てになっていませんか？
こんにちは。株式会社プラハCEOの松原です。 どんな人にこの記事を読んで欲しいか コードレビューの効率化に悩んでいる コードレビューのやり方に自信が持てず、何か参考になる事例を知りたい 使い捨てコードレビューに翻弄される日々 1~2年ほど前に自社サービスを開発していた頃、弊社では全てのプルリクエスト（以降PR）に対してランダムに割り当てられたレビュワー2名、もしくはテックリード1名にapproveされない限りマージしない運用で開発していました。開発者が5名ぐらいだったと記憶しているので、規模の割にはリッチなレビュー体制だったのではないでしょうか。 修正点があれば指摘して、直して、再確認して、merge。 来る日も来る日も、確認、指摘、修正、再確認、merge。 次第に「僕ら業務時間の大半をコードレビューに使ってね？」と、レビューに費やす時間が気になるようになってきたあたりで、一度自分たちの
「コードレビュー・・・うっ頭が」となっているそこのアナタへ。 先週弊社キカガクで人生初の実務コードレビュー体験をしました。 控えめに言って最高すぎました。 お互いが「気持ちよく・効率的に」学びを深められるように組まれた一級品のレビュー構成。 細部に渡る心遣いとテクニックの為せる技だと思いました。 そこで私は考えた ー。 真逆のことをしたらどうなるんだろう？ 想像してみたらなかなかブラックな開発環境が脳内で出来上がりました （大学時代のコードレビュー現場そっくりだなと思ったのは内緒）。 自分がコードレビューに参加する時こうはなるまいぞいう戒めを込めて紹介していこうと思います。 具体的な改善案も5選紹介しています。 共に愛され系コードレビュアー ＆ レビューイを目指しましょう！ 想定している対象読者 「もうすぐ初めてコードレビューを受ける予定で不安・・・」 「コードレビューを行うことになったけ
コードレビューのやり方、基礎の基礎 - コード改善に重要なレビューの基本的な考え方を学ぼう - エンジニアHub｜Webエンジニアのキャリアを考える！
コードレビューのやり方、基礎の基礎 - コード改善に重要なレビューの基本的な考え方を学ぼう コードレビューとは？レビューで問題を見つけて指摘するには？レビューをされる側の心構えとは？ソフトウェアレビューを研究する名古屋大学の准教授 森崎修司さんが、コードレビューの考え方を解説します。 はじめまして森崎です。大学でソフトウェアレビューの研究をしています。さまざまな組織との共同研究、調査、議論を通じて、レビューの原理・原則や体系的な考え方・知識を明らかにしようとしています。大学で研究に従事する前にソフトウェアエンジニアとしてインターネットサービスの開発をしていたため、研究として価値があり、実務としても役に立つ研究を目指しています。 レビューは、とにかく多くの経験をつまなければ上達しないという先入観を持たれがちです。その先入観をなくして、レビューの上達やソフトウェア品質の向上につながるしくみや活
How to do a code review
How to do a code review The pages in this section contain recommendations on the best way to do code reviews, based on long experience. All together they represent one complete document, broken up into many separate sections. You don’t have to read them all, but many people have found it very helpful to themselves and their team to read the entire set. The Standard of Code Review What to Look For
ソフトウェアの品質を保つためのツールとして、コードの変更点を一度他の人にチェックしてもらうという「コードレビュー」は高く評価されていますが、そのコードレビューにおいて、スムーズにレビューを進めるためのヒントをGoogleがブログに公開しています。 Google Testing Blog: Code Health: Respectful Reviews == Useful Reviews https://testing.googleblog.com/2019/11/code-health-respectful-reviews-useful.html ◆レビューする場合とされる場合の両方において守るべきこと ・相手の能力を尊重する 人が違えば得意分野や背景知識なども異なります。相手には高い能力があるはずだという前提に立ち、まずは質問を通して理解を深めることが大切です。 ・根拠を提示する ベスト
Interesting. I would caution that some of the tips are very culture-dependent. For instance, the example of not criticizing the person - I would rather have someone tell me straight in my face "Your approach is adding unnecessary complexity" than go around in circles and word-dancing around it, I would appreciate the honesty and the respect for my time (the 2nd way of phrasing is longer. but more
コードレビューで気をつけていること 5 選
こんにちはnasaちゃんです。 コードレビューの記事を見かけたので僕がコードレビュー時に考えていること、行っていることを書いてみようと思いました。 この記事ではレビューを受ける側、行なう側それぞれの話がありましたが、ここではレビューを行なう側のことを書いていきます。(洗い出してみるとすべてがレビューコメントに関するものでした。) Whyを書く コードの変更をリクエストする際になぜ変更したほうが良いのかを書くようにしています。 レビュイーが変更を取り込むか判断する材料になるのでちゃんとなぜこっちのコードのほうが望ましいのかを書くようにしています。あと、言語化することで自分の理解も深まるので良いですね。 このとき、レビュー中のコードを批判しないことを心がけています。 「今のコードは〇〇というデメリットがあるので変えたほうが良い」と伝えるよりも「このような書き方をすることで〇〇がよくなると思いま
こんにちは！エンジニアの @fortkle です。 あの伝説のゲーム「メダロット」のスマホゲームのリリース日がついに 2020年1月23日と発表がありました!*1 いまからワクワクしてきましたね！リリースしたらぜひロボトルしましょう！ さて、今回の記事は「コードレビュー」についてです。コネヒトに入社してから早4年、数百のPRをレビューしてきてだんだんと自分の中でコードレビューに対する接し方が定まってきました。今日は私がコードレビューで心がけていることについてご紹介できればと思います。 レビュワーとして ① "既存コード" の 歴史的経緯を素早く紐解く コードレビューは様々な目的で行われますが、「欠陥・バグを検出すること」「コードの改善」に期待をしていることが多いかと思います。 これらの目的を達成するためには、既存・変更後のコードの実装意図や背景を理解することがとても重要になります。特に長年
やらないなんてもったいない！チーム開発におけるコードレビューのススメ | クリエイターのための総合情報サイト CREATIVE VILLAGE
みなさんのチームでは、コードレビューは行っているでしょうか？ メンバーズエッジカンパニーではリモートチームによるアジャイル開発を行っており、自分のチームでは言語にPython、フレームワークにDjangoを使った、業務系システムを作っています。 自分のチームでもコードレビューを行っていますが、自分はチームの立ち上げから関わり、かつプログラマーとしての経験も長いため、レビューをする立場が多いです。 この記事では、チーム開発においてのコードレビューの意義と手段について紹介していきます。 池本 英貴（いけもと ひでき）氏 株式会社メンバーズ メンバーズエッジカンパニー Webエンジニア 2019年中途入社。 神戸オフィスにて1年間の修行後、愛媛県にてフル在宅勤務中。 好きなハードはNeXTcubeです。 コードレビューの意義 コードレビューをする意義は何でしょうか。自分は4つあると考えています。
Go Codereview Comments
原文 目次 go fmt Comment Sentences Contexts Copying Crypt Rand Declaring Empty Slices Doc Comments Don’t Panic Error Strings Examples Goroutine Lifetimes Handle Errors Imports Import Blank Import Dot In-Band Errors Indent Error Flow Initialisms Interfaces Line Length Mixed Caps Named Result Parameters Naked Returns Package Comments Package Names Pass Values Receiver Names Receiver Type Synchronous Fun
コードレビューで本を参照として使う
コードレビューをすると修正の提案をする機会がありますが、その時に本を参照として添えることをしています。ちょっとポエムっぽい記事です。 そして、この記事は meihei GW アドベントカレンダー3日目の記事です。 meihei GW アドベントカレンダーとは？ meihei GW アドベントカレンダーとは、meiheiがゴールデンウィークの5月1日〜5日までの間に毎日記事を投稿する企画です。勝手にやっています。 1日目 https://developers.prtimes.jp/2024/05/01/had-a-good-time-at-phpcon-odawara-2024/ 2日目 https://developers.prtimes.jp/2024/05/02/use-leaguecsv-for-japanese-columns/ コードレビューの目的 個人的にコードレビューを行う目
The Standard of Code Review The primary purpose of code review is to make sure that the overall code health of Google’s code base is improving over time. All of the tools and processes of code review are designed to this end. In order to accomplish this, a series of trade-offs have to be balanced. First, developers must be able to make progress on their tasks. If you never submit an improvement to
こんにちは、@beta_chelsea です。 ご縁ありまして、今年の秋頃からフィヨルドブートキャンプにメンターとして参加させていただいております。ということで、フィヨルドブートキャンプ Part 2 Advent Calendar 2020 - Adventarの記事を書きます。 昨日は メンター @u1tnk さんの 「失なわれた構造化プログラミング、そしてオブジェクト指向へ… 」、構造化プログラミングのお話でした。 ソースが実際に構造化されていく様子、実際に見ないとピンとこないことも多いかと思います。特にオブジェクト指向にお悩みの方はぜひご一読ください！ 自分は「セルフレビュー 」をテーマにちょっと述べてみたいと思います。 フィヨルドブートキャンプは、メンターが生徒さんたちの書いた成果物(ソースコード)に「確認OK」を出すことで進めていくのですが、セルフレビューを活用することでそのサ
On Code Review
TL;DRCode review should probably always be your top priority, and you should figure out the best way to work it into your event loop.Make your code review requests a pleasure to read.I wrote this in March 2014 when I was managing the User Lookup Service team at Twitter, to codify our theory of and approach to code review, and to try to establish some basic best practices. It’s not intended to tell
Fix more bugs during code reviewTrusted by over 3000 teams to fix more bugs during code review and find hidden Python or Django issues already in their codebase. View demo We've improved thousands of codebases including Chrome PyTorch Sentry Tensorflow Firefox It caught malformed test assertions that were incorrect. The automated codebase audit tool is so handy! Jared Lockhart, Senior Software Eng
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビューの目的と考え方 - osa_k’s diary
Google エンジニアリング・プラクティス ドキュメント
コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
StackOverflowからのコピペをやめろ。今すぐにだ。 - Qiita
設計/コードレビューで"常に"心がけるポイント - little hands' lab
GoでWebアプリ開発時にあるあるだったレビューコメント | フューチャー技術ブログ
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
より良いコードレビューをするために気をつけていること | メルカリエンジニアリング
コードレビューのときに見ているところ - 詩と創作・思索のひろば
AtCoder高橋社長がLINEのコーディング試験を見て驚いた理由―。「競プロとこんなに違うとは……」
Google Engineering Practices Documentation
Pull Request のコメント数を減らすアホみたいなコツ｜牛尾 剛
コードレビューで嫌われる人の特徴7選 - Qiita
Googleがコードレビューにおいてスムーズにコミュニケーションを進めるための注意点を公開
Code Health: Respectful Reviews == Useful Reviews
コードレビューで心がけている3つのこと【PHPカンファレンス協賛記念ブログ！】 - コネヒト開発者ブログ
The Standard of Code Review
すばやく確認OKをもらうためのセルフレビュー - よもやま話β版
https://slideship.com/users/@massa142/presentations/2020/07/45muxmQzWHqr4iZYR73wBM/
Fix bugs hidden in your codebase | CodeReview.doctor