コードレビューの目的と考え方 - osa_k’s diary
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
レビューしやすいプルリクエスト | DevelopersIO
普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 割と大きめなソースコードに対するレビューの話が主となります。 ざっくりまとめ 本記事では以下のようなトピックについて記載しています。 差分の目的が1つ レビューをしながら「私はいま何のレビューをしているのか」のコンテキストスイッチが発生しないので嬉しい 何を達成したいのかがわかる レビューの多くは「やりたいこと」と「実現方法」のすり合わせなので、前者の精度を上げたい 分割されすぎていない 他のコードとの関連性や構造についてのレビューがしやすい レビューの強弱をつけるための情報がついている 機械的な変換の差分だったりした場合、それが事前にわかると嬉しい 検証結果が書いてある コードだ
チーム開発で暗黙的に行なわれている批評というプロセス - snoozer05's blog
Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。 Wikipediaでコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査（査読）を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。 2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Crit
コードレビューの高まった言葉 - 職質アンチパターン
ブログ間違った，普段こういう事はこっちに書いてます． http://moznion.hatenadiary.com 最近自分がコードレビューで使いがち，あるいは表立って使ってないんだけど内心評す時に使う言葉が色々とあり，まとめてみることとした．参考にしない方が良いと思う． 左は言葉，右は説明． 屈強 - コードが力強い時に使う．例えば長い一枚スクリプトとか，コメントが一切ないバッチ処理とか．やや批判的な意味合いで使うことが多い． マッチョ - 屈強と同じ文脈で使いがち 屈強だけどしなやか - 屈強だけどしなやかな時に使う．好意的な屈強さと言える． モノリス - 長大なトランザクションスクリプト見た時とかに使う．やや批判的． 言い訳ないですか - 後で直していくぞ！ というメンタルの時に書かれたコードのコメントが案外少ない時に使う言葉．言い訳は無いよりあった方が良い．実際には「もうちょっと言
[翻訳] コードレビューについて
この記事は::..: 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)
pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション - ppworks.jp
pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。（色んな使い方があります） 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった！まさにこれだ！と思いました。 よし、コードレビューをしよう！ 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/ /," ").split() 私は言った for文にナニカを感じた し、Cぽい！ search_word_arrays = param
ソニックガーデンで行われているコードレビューの具体例をお見せします (SonicGardn Study #11 の補足として) #sg_study - give IT a try
はじめに 2014年8月11日の晩に放送されたソニックガーデンのweb勉強会、SonicGardn Studyでは「いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜」というタイトルで、弊社ソニックガーデンの西見さん(@mah_lab)が講演してくれました。 デキるプログラマだけが知っているコードレビュー7つの秘訣 from Masahiro Nishimi いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜 - YouTube この放送の中でも触れられていたように、ソニックガーデンではコードレビューを大事にしています。 ただ、勉強会のスライドの中では具体的なコード例や指摘の例がほとんど出てこなかったので、「実際どんな感じなの？」という疑問を持った方もいたんじゃないかと思います。 そこで今回は「入社
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
レビュアーとレビュイーの関係に関して - 職質アンチパターン
感じていた違和感の正体がわかった． レビューにおいて，レビュアーとレビュイーの関係には上も下もない． レビューという場では，両者の立場は対等でなければならない．さもなければ，「このレビューおかしい気がするけれど，あの人は立場が上だから指摘しにくい」だとか，「相手は格下だから適当にレビューしても良い」だとか，そういう良くない雰囲気が形成されてしまう． 確かに，レビュアーというポジションはチームの技術力が高い人やそれに伴ってパワーのある人が担うケースが多いと思う．レビュイーはそれに萎縮してしまいがちというか，僕もその1人なんだけれど，そういうのは実際のところ保身でしかなくて，下手に意見言うとレビュアーとの関係悪くなりそう，みたいな卑屈な理屈に基づく駄目な萎縮な感じがする．こういう良くないところはちゃんと直して，健全化していかなければまずい． あとレビューされた内容は素直に受け入れるべきだと思う
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
先輩から教えてもらったコードレビュー