コードの健全性: 礼儀正しいレビュー == 役立つレビュー
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
[翻訳] コードレビューについて
この記事は::..: 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)
コードレビューの極意。それは「自分のことは棚に上げる」こと！！ - Qiita
はじめに：コードを良くするためなら遠慮は不要 昨日Twitterに投稿した内容が思った以上に拡散されていたので、タイムラインに流れてしまわないようにQiitaにも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん！って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、コードを改善できるせっかくのチャンスが失われてしまいます。 「自分ができているかどうか」と「そのコードを改善すること」は、それぞれ別の問題です。 なので、レビューする人は自分のことを棚に上げてでも、コードの問題点を指摘する必要があります。 また、レビューされ
別に、プルリクレビューの前にレビューしてもらっていいんだからね - jfluteの日記
レールに乗るとレールに乗らない？ 昨今身の回りだと、すっかり Github のプルリクベースの開発で、「プルリク出して Github 上でみんなでレビュー」そんなやり方が当たり前になってきました。 レビュー制度自体が崩壊しがちな開発現場で、このレールに乗ったやり方で、どこの現場も安定してレビューライフを導入できているように思います。 ただ、どんな話でも共通ですが、レールに乗ると、レールに乗らないものを忘れがちだと。 盛大な手戻りストーリー レビューイー 「さあ、プルリクーしたーぞー」 レビューワー１ 「それ全然作り方ダメじゃない？」 レビューワー２ 「その実装だとパフォーマンス悪いね」 レビューイー 「めっちゃ手戻りー（＞＜」 程度の差はいろいろあれど、なんかこういうケースをよく見かけるなぁと。ある程度は仕方ないけど、あまりに大きい手戻りがなんども連続して続くと、プロジェクト的にはつらいで
コードレビューを会話しながら行う取り組み - Hatena Developer Blog
こんにちは。アプリケーションエンジニアの id:itchynyです。 今回は、コードレビューを会話しながら行う取り組みについて紹介します。 コードレビューは大事なコミュニケーションの場です。 コードレビューの効用としては、単純なミスがあるコードをリリースしない・プロダクトのコードの品質をよりよくしていく、あるいはその方策を模索するといったことが挙げられます。 こういったことは当然のことですが、なによりもまず、レビューというのは一緒にプロダクトを作っている仲間とのコミュニケーションの場だと思います。 多くの人は、プロダクトのコードをよくしていきたい、読みやすいコードを書きたい、分かりやすいコードで目的の機能を作りたいといった共通の思いを持っていることでしょう。 コードを書いた人の思いを汲み取りながら、共感したり、譲歩したりしながら、よりよい方法を提示していきます。 それでも時には、どういうコ
つらくないコードレビューの運用 - Speaker Deck
All slide content and descriptions are owned by their creators.
[翻訳] コードレビューについて
この記事は::..: glen.nu :.: ramblings :.: on code review :.::の意訳記事です。@9len氏の許可を受けて投稿しています。 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でユーザ検索チームを私が率いていたころの話だ。この記事は、コードレビューに関するセオリー・アプローチを体系化することを狙いとしていて、いくつかの基本的なプラクティスの確立を狙っている。あな
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
DevLove現場甲子園2014 東日本大会で天使コードの話をしてきました（そしてMVPを頂きました！） | mah365
昨日8/23（土）はDevLove現場甲子園2014 東日本大会というイベントで天使コード（※1）についてのお話をさせていただいてまいりました。会場は日本オラクルさんで、過去に同会場でいろいろな研修を受けていた身としては少し感慨深いものがあります。そしてありがたいことに、講演の人気投票で見事トップを勝ち取り、MVPとしてラストに表彰をいただきました。いやー、びっくりだ・・・。 ※1 例の単語を「しずかったー」で綺麗な言葉に変換すると、天使コードになります。 8月上旬にSonicGarden Studyでお話したものを、更にブラッシュアップしてお話をさせていただきました。基本骨子は変わっていないのですが、「7つの秘訣」をコードレビューの心技体のうち、＜心＞と位置づけたところが大きく違う部分です。 心構えだけでコードレビューができるはずもなく、もちろん実装技術が伴わなければレビューができません
コードレビューについて : 小野和俊のブログ
伊藤直也さんが「些末なコードレビュー」というエントリを書いて話題になっている。このエントリで伊藤さんはコードレビューの話と、はてなのJavaScriptの話と2つの話題に触れている。前者のコードレビューについてはアプレッソでは8年ほど前から「コードレビューを通っていないコードはコミット不可」というルールですべてのソースコードに対してコードレビューを必須にしてきた関係で私も思うところがあるので、エントリを書いてみようと思う。 伊藤さんが例示しているように、インデントやreturnの省略などの話は好みの問題であり、議論してもソフトウェアの改善につながらない。なのでコードレビューでこうした宗教論争が起こるようなら、コーディング規約を見直すべきだ。「無駄に悩んだり議論したりすることを減らす」ことはコーディング規約の主たる効果のひとつだと言える。 コードレビューに慣れないチームが、何の考えもナシにコ
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
コードレビューを円滑に行いたい (#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 それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
ソースコードの品質向上のための効果的で効率的なコードレビュー
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
レビューのアウトプットは、レビューアのレベルを超えない（2）: 柴田 芳樹 (Yoshiki Shibata)
開発組織としてメンバーのスキル向上を行うためには、経験豊富なエンジニアの知識をレビューという形式で伝えていくことが重要です。そして、たとえ初心者であっても、繰り返しきちんとしたレビューを受け続けることにより、成長させていく必要があります。コードレビューは、ソフトウェアの品質を作り込む場でもあるのですが、同時にエンジニアを教育する場でもあったりします。 しかし、開発組織がコードレビューに関して否定的だと、開発プロセスでレビューすることが規定されているというだけの理由で、初心者レベルのエンジニアだけでレビューを行わせたりします。ここで「初心者レベル」というのは、ソフトウェア開発経験年数が少ないという意味ではなく、きちんとしたコードを書くということに関して初心者レベルという意味です。 コードの品質に興味がない人がリーダとして開発チームをリーディングしている場合には、開発が遅れてくると大量に初心者
［ディスカッション］ソフトウェアインスペクション／コードレビューを成功させる方法（後編）
本エントリは「［ディスカッション］ソフトウェアインスペクション／コードレビューを成功させる方法（前編）」の続きです。 パネリスト（50音順） 越水喜之氏（日本IBM） 細川宣啓氏（日本IBM） 森崎修司氏（奈良先端科学技術大学院大学） モデレータ 新野淳一（前＠IT発行人、現Publickey編集長） 欠陥を指摘するためのテクニック 新野 ソフトウェアインスペクション／コードレビューの現状の分析をパネリストにしていただいたところで、次は、明日から使えるソフトウェアインスペクション／コードレビューのテクニックを紹介してもらおうと思います。 そういえばこのあいだ細川さんの情報処理学会の論文を読ませていただきました。で、そこにインスペクションのテクニックには2つある、って書いてあったんです。1つは発見するテクニック。もう1つは指摘するテクニックだと。指摘するテクニックってそのとき始めて知ったので
［ディスカッション］ソフトウェアインスペクション／コードレビューを成功させる方法（前編）
「ソフトウェアインスペクション」あるいは「ソフトウェアレビュー」とは、一般にプログラムが動作する以前の段階から問題やバグを発見することをいいます。ソースコードの静的解析やコードレビューは、ソフトウェアインスペクションの中でもよく行われていることの1つといえるでしょう。また、コード以前の要件定義や仕様書などもソフトウェアインスペクションの対象となります。 7月2日に、このソフトウェアインスペクションをテーマにしたイベント「ソフトウェアインスペクション・ワークショップ 2009」が行われました。ソフトウェアレビューやインスペクションの経験者を前提として参加者に集まってもらい、Javaソースコードのインスペクションを実際に実施することを目的としたこのイベントは、地味なテーマ設定のためそれほど参加者が集まらないのではないか、と予想されていました。 しかし実際には約115名もの応募が寄せられ、定員で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビューの話
コードレビューガイドライン #loupestudy
