レビューの仕方Open8 勉強会で発表したレビューの仕方と心理的安全性の話しです。
コードレビューの目的と考え方 - osa_k’s diary
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
Java初心者時代にコードレビューで指摘された悪しき習慣 - Qiita
Java初心者だった新入社員の頃、先輩にコードレビューで指摘された事を思い出してまとめてみた。 追記：本記事に関しては賛否含め、多くの有益なコメントを頂いています。本記事をお読みになる際は、是非コメント欄も併せてご覧下さい。 2018/04/26 コメントを参考に「何でも定数にしようとする」の見出し・本文を修正しました。@kagilinn さん、ありがとうございました。 2018/04/30 サンプルコードの判定バグってたので修正しました。@y_miz さん、ご指摘ありがとうございました。 コメントの誤記、用語誤りを修正しました。@scivola さん、編集リクエストありがとうございました。 不要なインスタンス変数を作ってしまう インスタンス変数は状態が保持されるので、バグを作り込みやすい。 「これローカル変数でよくない？」ってよく指摘された。 インスタンス変数を作る前に、ローカル変数で実
「速」を落とさないコードレビュー
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/
[翻訳] コードレビューについて
この記事は::..: glen.nu :.: ramblings :.: on code review :.::の意訳記事です。@9len氏の許可を受けて投稿しています。誤り・修正などがありましたら、@iwashi86までご連絡いただけますと幸いです。 This article originally appeared in English at :..:: GLEN D SANFORD :.: RAMBLINGS :.: ON CODE REVIEW ::..: and has been translated with @9len’s permission for posting to this blog in Japanese. この記事は2014年3月に書いている。Twitterでユーザ検索チームを私が率いていたころの話だ。この記事は、コードレビューに関するセオリー・アプローチを体系化
![[翻訳] コードレビューについて](https://cdn-ak-scissors.b.st-hatena.com/image/square/4b2b513cd4b9941cd623836a282bad7afa76c330/height=288;version=1;width=512/https%3A%2F%2Fiwashi.co%2Fassets%2Fimages%2Fogp-min.png)
つらくないコードレビューの運用 - Speaker Deck
All slide content and descriptions are owned by their creators.
ソシャゲエンジニアの自分がコードレビュー時に重視する箇所33選 【随時追加】 - Qiita
コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、（主に土日に）サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 【ステキポイント】 ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます（4歳の息子談） 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです！ チェックするポイントは5つ コードレビューを行うにあたり、「どんなところをチェックすればいいのか分か
気軽にコードレビューするならGitHubではなくRefactor.ioでも良いと思った - Qiita
2016年に流行りそうだけどまだ殆ど知られていないエンジニア向けサービス10選を見ていたら、Refactor.ioというサービスがあって気になったので軽く使ってみた。 https://www.refactor.io/ Refactor.ioとは コードレビューやリファクタリングを気軽に依頼できるサービス。依頼したいコードを投稿するとレビュー用のページが作成され、そのページのURLを依頼者に共有、もしくはそのページを訪れた人にコードレビューやリファクタリングをしてもらう事ができる。 何ともシンプルなUI。画面右上に「GitHub Login」というリンクがある通り、GitHubとも連携出来る。連携の設定をしておくことで依頼したコードにコメントが入るとその旨をメールで受け取ることが出来る。対応言語は以下の通り。 ・JavaScript ・JSX ・CoffeeScript ・LiveScrip
チームのみんなで成長できるコードレビュー コメントの方法編 - Qiita
mixi Advent Calendar の17日目です。 今までまともにコードレビューをしたことがなかったエンジニアが、半年前からコードレビューを経験し始めて、チームの雰囲気が良くなった（と思っている）レビューの仕方をご紹介します。 私は株式会社ミクシィのグループ会社である株式会社 Diverse へ出向して、そこでデーティングサービス YYC の Android クライアントを開発しております。 現在、 YYC の Android クライアントは大規模な改修を行っていて、それに合わせて開発チームの再編成・開発フローの改善などいろいろな試行錯誤をしています。 その試行錯誤のうちの一つとしてコードレビューでの取り組みをご紹介します。 ここで説明すること、しないこと ここでは以下のことについて説明します。 コードレビューの雰囲気を良くする（良く保つ）方法 自分やチームメンバーの成長を促すため
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
男ばかりの会社に ｶﾜ(・∀・)ｲｲ!! 指摘ちゃんを採用しよう。萌えキャラによるコードレビューの自動化 on GitHub - SideCI Blog
こんにちは。 私達が運営しているSideCIは、RuboCopやBrakeman、PHP_CodeSnifferなどの静的解析ツールを利用したGitHub連携のコードレビュー機能を提供しています。 コードレビュー機能をONにした状態でPullRequestをOpenすると、すぐにコードレビューが実行されます。 ところで、こういった自動コードレビュー機能、皆様はどのようにお使いでしょうか？ SideCI Sign Up直後のGitHubの状態 普通に自身のアカウントでSign Up、設定するとPull Requestはこのような感じになります。 いつもの開発者アイコンがコメントするのは、なんだか面白く無いですね。 Pull Requestへのコメントは毎日見るものです。毎日顔を合わせるアイコンだからもっと大切にしたい！ また、これはbotなのかそれともエンジニア自身なのかが分かりづらいです。
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
コードレビューに費やす時間を短くする - クックパッド開発者ブログ
はじめに こんにちは、広告事業部の芳賀（@func09）です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ１年になるのですが、初めはエンジニア以外の人（営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます）と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTGや相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。
コードレビューをし合える文化がチームを強くする - ppworks.jp
コードレビューしてますか？ 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
アジャイルチームでコードレビューを実施する上での障害と対策 - 何か着ていればいいよ
このエントリは アジャイルCasual Advent Calendar 2014 の 3 日目のエントリです。 前日はa_suenamiさんのPDCAに関するお話でした。 "アジャイルチームでコードレビューを実施する上での障害と対策" ということで、現場で自分が今まで試行錯誤をさらしてみようと思います。 プロジェクト中にコードレビューを行って、実際に困った事とそれに対して試行錯誤しながら行ってきた対策をあげていきます。 どのようなレビューを行っているのか いきなりレビューがうまくいかない話をする前に、どんなコードレビューをしているのさ？って話を少々。 チケット駆動で開発する タスクはコーディングチケットとレビューチケットの二つがセット *1 レビューはコードを書いた本人以外が行う 他にも細かく書くと色々あるけれど、ざっくりいうとこんな感じになります。 障害その1 『レビューの工数が取れない
クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
デキるプログラマだけが知っているコードレビュー7つの秘訣
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。Read less
コードレビューについて : 小野和俊のブログ
伊藤直也さんが「些末なコードレビュー」というエントリを書いて話題になっている。このエントリで伊藤さんはコードレビューの話と、はてなのJavaScriptの話と2つの話題に触れている。前者のコードレビューについてはアプレッソでは8年ほど前から「コードレビューを通っていないコードはコミット不可」というルールですべてのソースコードに対してコードレビューを必須にしてきた関係で私も思うところがあるので、エントリを書いてみようと思う。 伊藤さんが例示しているように、インデントやreturnの省略などの話は好みの問題であり、議論してもソフトウェアの改善につながらない。なのでコードレビューでこうした宗教論争が起こるようなら、コーディング規約を見直すべきだ。「無駄に悩んだり議論したりすることを減らす」ことはコーディング規約の主たる効果のひとつだと言える。 コードレビューに慣れないチームが、何の考えもナシにコ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビューのススメ
コードレビューガイドライン #loupestudy
