2020/07/21 に弊社新卒向けに実施したコードレビュー研修の資料です。
普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 割と大きめなソースコードに対するレビューの話が主となります。 ざっくりまとめ 本記事では以下のようなトピックについて記載しています。 差分の目的が1つ レビューをしながら「私はいま何のレビューをしているのか」のコンテキストスイッチが発生しないので嬉しい 何を達成したいのかがわかる レビューの多くは「やりたいこと」と「実現方法」のすり合わせなので、前者の精度を上げたい 分割されすぎていない 他のコードとの関連性や構造についてのレビューがしやすい レビューの強弱をつけるための情報がついている 機械的な変換の差分だったりした場合、それが事前にわかると嬉しい 検証結果が書いてある コードだ
開発現場に学ぶ、円滑なコードレビューに必要な8つの手法 ~手段から準備、実施時期まで徹底解説~ コードレビューによって解決される問題とは?そして、実際にチームでコードレビューを実施する上で気をつけるべきこととは?ソニックガーデンの取締役プログラマー西見公宏さんが、コードレビューのポイントを、実践に基づき解説します。 ITを活用して事業の課題を解決するサービス「納品のない受託開発」を提供する会社、ソニックガーデンの西見公宏(にしみ・まさひろ/@mah_lab)です。お客様の「バーチャルCTO」として、サービスの企画からシステムの開発・運用まで、日夜幅広く関わらせていただいております。 皆さんは普段、ソースコードをどのくらい読んでいるでしょうか? 普段からソフトウェア開発をしている人であれば、何か問題が起こったときの原因調査のために他の人が書いたコードを読んだり、はたまた自分の書いたコードを読
PushRequest PushRequestはコードレビュワーマッチングサービスです。 レビューしてもらいたいエンジニアとマッチングしてサービスを開発しましょう!
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
Chromium Code Review Advent Calendar 2017の25日目の記事です。参入障壁が低かったのでなんとなく書いてみました。興味のある方は充実の本家Chromium Browser Advent Calendar 2017も参照下さい はじめに オープンソースのウェブブラウザ Chromiumでそこそこ長く開発をしてるので、自分や周りの人がコードレビューで心がけていることを書いてみました。良いコードとは何かという話はまた別の長い議論になるのでここではとりあげません。 基本的に、コードレビューはコミュニケーションと思っており、うまくやることで開発効率をあげたりコードベースをより良くしたりできる可能性があると思ってるので、そんなことを書こうかと思います。なお、目指しているだけで、必ずしもいつもできているわけではないです 以下、唐突にである調で。 レビューレイテンシを
コードレビューの際に落とし穴にはまらずに、どのようにうまくコミュニケーションをとるか、に関する記事の後半部分です。著者がコードレビューで失敗した実例を元にお互いの衝突を避けるテクニックについて紹介します。 [プログラミング]原文 How to Do Code Reviews Like a Human (Part Two) - Silly Bits (English) 原文著者 Michael Lynch 原文公開日 2017-11-09 翻訳依頼者 翻訳者 taka-h 翻訳レビュアー doublemarket 原著者への翻訳報告 2151日前 メールで報告済み 2149日前 原著者承諾済み 編集 この記事はコードレビューの際に落とし穴にはまらずに、どのようにうまくコミュニケーションをとるか、に関する記事の後半部分です。今回はひどい衝突を避け成功裏にレビューを終わらせるテクニックに焦点をあ
そういうときがよくあります。 コードレビューがある会社は今が初めてだけど、きっとこれから先もコードレビューがある限りは、なくならない気持ちなんだと思います。 だから、そんなときに振り返れるようなものを残しておきます。 「コードレビュー つらい」でググってみると、はてな匿名ダイアリーのこんな記事が見つかりました。 anond.hatelabo.jp さすがに、ここまでヒドいケースを経験したことはないし異常だと思ったけれど、以下のくだりは自分の胸にすごく刺さりました。 私はプログラマに向いていないんじゃないかと思う。よいプロダクトを作る上で強い言葉を交えた議論が必要不可欠ならば、それに強いストレスを感じてしまう私はプログラマとして適正がないのでは? 刺さったのですが、それでも自分はここでやっていかなくちゃならないと思っているので、つらくなったときにいつでも読み返せるよう、見つけた記事・資料をま
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
こんにちは!サービス開発部でAndroidアプリの開発をしているこまたつ(@k0matatsu)です。 みなさんコードレビューしていますか? 最近ではとりいれているチームも多いと思いますが、良い効果をもたらしてくれる一方で、負荷の高い作業でもあります。 また、コードレビュー自体に馴染みの薄かった人はなにをどうしたらいいのか難しいですよね。 同僚から得たアドバイスと自分なりのノウハウをあわせて、コードレビューの指針を考えていたので公開してみようと思います。 前提として、クックパッドではGitHub Enterpriseとプルリクエストを使った開発プロセスを採用しています。 また、コードレビューの前には自動テストと静的解析ツールによる単純なフォーマット、コードスタイル、頻出バグのチェックは行われているものとします。 静的解析による機械的なチェックはコードレビューよりも低コストで有効な方法ですの
実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす
はじめに:コードを良くするためなら遠慮は不要 昨日Twitterに投稿した内容が思った以上に拡散されていたので、タイムラインに流れてしまわないようにQiitaにも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん!って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、コードを改善できるせっかくのチャンスが失われてしまいます。 「自分ができているかどうか」と「そのコードを改善すること」は、それぞれ別の問題です。 なので、レビューする人は自分のことを棚に上げてでも、コードの問題点を指摘する必要があります。 また、レビューされ
こんにちは。アプリケーションエンジニアの id:itchynyです。 今回は、コードレビューを会話しながら行う取り組みについて紹介します。 コードレビューは大事なコミュニケーションの場です。 コードレビューの効用としては、単純なミスがあるコードをリリースしない・プロダクトのコードの品質をよりよくしていく、あるいはその方策を模索するといったことが挙げられます。 こういったことは当然のことですが、なによりもまず、レビューというのは一緒にプロダクトを作っている仲間とのコミュニケーションの場だと思います。 多くの人は、プロダクトのコードをよくしていきたい、読みやすいコードを書きたい、分かりやすいコードで目的の機能を作りたいといった共通の思いを持っていることでしょう。 コードを書いた人の思いを汲み取りながら、共感したり、譲歩したりしながら、よりよい方法を提示していきます。 それでも時には、どういうコ
この記事は freee Engineers Advent Calendarの6日目です。 こんにちは。freee株式会社でアプリエンジニアをしている @kompiroです。主に会計freeeの開発に携わっています。 僕には「よりよい機能を、より早くユーザーに届けたい」という信念があります。今日はよりよい機能を、より早くユーザーに届けるためのGit/GitHubを活用する10の方法と題してGitやGitHubの便利な使い方や日々のTipsをお届けします。1 PRのレビュー完了までの時間を最速にするための工夫 freeeではGitHub上でレビューをしながら開発を進めています。レビューをするのもされるのも、うまく進めないと結構時間がかかります。もちろんコードをより良くする作業に時間を割いているのであれば時間がかかるのも致し方ないです。しかし、進め方による問題でも数日〜数週間デプロイが延期されれ
この記事はpepabo Advent Calendar 2016の4日目です。 3日目は@r_takaishiさんの「IIJmioのクーポン残量をAWS LambdaとMackerelでプロットしてみよう」でした。 コードレビューでよくある風景#突然ですが、コードレビューを行っていると、このようなコメントを一度はする・されると思います。 インデントやスペースの抜け漏れといった、細かいコーディングスタイルに関する指摘ですね。 人力でフォーマットの指摘をするのは見逃しが発生しやすく、細かい部分を確認するコストがかかります。小言のようなコメントになってしまいがちで、開発者・レビュアー双方に負担が増えてしまいます。 このような作業は機械に任せましょう。RuboCopやPHP-CS-Fixer、ESLintといったコーディング規約チェックツール(Lintツール)が役立ちます。 Lintツールを導入す
#code_kaizen コード改善 #2 で発表したスライドです。 SpeakerDeck: https://speakerdeck.com/yasuhiroki/kodorebiyunowen-hua-woshou-tan-ridezuo-tuteitutahua
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く