コードレビューするのが怖いと思っていたエンジニアが半年間コードレビューを経験して思った 10 のこと - きょくちょ日記 -THERE'S ONLY MAKE!-
これは pepabo Advent Calendar 2016 - Qiita の14日目の記事です。 昨日は id:Fendo181 さんの 日報サービス「DuPo」を作った話でした！ それは、今からちょうど半年前のこと。 海の香りと共に暑い夏がやってくる ... 甘酸っぱい青春が再び来るのではないかと予感させる ... そんな季節でした。 開発チーム内で行っていたスプリントレトロスペクティブの時間に、チームメンバーから「そろそろコードレビューをやってみよう！」と提案があり、それから本格的にコードレビューをやり始めることになりました。 早いもので、あれから半年が過ぎました。 今宵は年の瀬ということもあり、ふりかえりを目的として半年間コードレビューを積み重ねたことで僕の中で起きた考えの変化や感じたことについて 10 個書き出してみることにしました。 教育関連に興味がある方や組織の成長を考え
コードレビューの高まった言葉 - 職質アンチパターン
ブログ間違った，普段こういう事はこっちに書いてます． http://moznion.hatenadiary.com 最近自分がコードレビューで使いがち，あるいは表立って使ってないんだけど内心評す時に使う言葉が色々とあり，まとめてみることとした．参考にしない方が良いと思う． 左は言葉，右は説明． 屈強 - コードが力強い時に使う．例えば長い一枚スクリプトとか，コメントが一切ないバッチ処理とか．やや批判的な意味合いで使うことが多い． マッチョ - 屈強と同じ文脈で使いがち 屈強だけどしなやか - 屈強だけどしなやかな時に使う．好意的な屈強さと言える． モノリス - 長大なトランザクションスクリプト見た時とかに使う．やや批判的． 言い訳ないですか - 後で直していくぞ！ というメンタルの時に書かれたコードのコメントが案外少ない時に使う言葉．言い訳は無いよりあった方が良い．実際には「もうちょっと言
気軽にコードレビューするならGitHubではなくRefactor.ioでも良いと思った - Qiita
2016年に流行りそうだけどまだ殆ど知られていないエンジニア向けサービス10選を見ていたら、Refactor.ioというサービスがあって気になったので軽く使ってみた。 https://www.refactor.io/ Refactor.ioとは コードレビューやリファクタリングを気軽に依頼できるサービス。依頼したいコードを投稿するとレビュー用のページが作成され、そのページのURLを依頼者に共有、もしくはそのページを訪れた人にコードレビューやリファクタリングをしてもらう事ができる。 何ともシンプルなUI。画面右上に「GitHub Login」というリンクがある通り、GitHubとも連携出来る。連携の設定をしておくことで依頼したコードにコメントが入るとその旨をメールで受け取ることが出来る。対応言語は以下の通り。 ・JavaScript ・JSX ・CoffeeScript ・LiveScrip
[翻訳] コードレビューについて
この記事は::..: 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でユーザ検索チームを私が率いていたころの話だ。この記事は、コードレビューに関するセオリー・アプローチを体系化することを狙いとしていて、いくつかの基本的なプラクティスの確立を狙っている。あな
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
コードレビューツール Review Board を使う - Qiita
# mysql mysql> CREATE DATABASE reviewboard; mysql> GRANT ALL ON reviewboard.* TO reviewboard@localhost; mysql> FLUSH PRIVILEGES; mysql> SET PASSWORD FOR reviewboard@localhost=password('reviewboard'); mysql> exit 3. Review Board 初期化 rb-site install /var/www/reviewboard 基本的に指示に従えばいいです。DBは先ほど作成した物を指定。 memcacheの選択肢が出てくると思いますが、入れていなくても動きます。数人で使う程度であれば、パフォーマンス上も問題は出ていません。 4. Apache設定 3.で作成したサイトにアクセスしたら諸
Review Boardならコードレビューを効率良くできる！
Review Boardならコードレビューを効率良くできる！：ユカイ、ツーカイ、カイハツ環境！（19）（1/3 ページ） “コードレビュー”やってますか？ “コードレビュー”は、ソフトウェア開発の重要なプロセスですが、往々にしておざなりにされがちです。 しかし、きちんとコードをレビューすることで、品質向上や、早期のバグ発見による後工程でのコスト削減につながります。また、病気や事故、他のプロジェクトへの突発的な火消し（！）などによる、開発メンバーの長期離脱時のリスク削減にもつながります。さらには、他の開発者が書いたコードを読んで学習することにより、コーディングスキルの向上にも役に立ちます。 今回は、「そうはいっても、現実的にコードレビューなんて無理……」という方のために、コードレビューを効率化する「Review Board」というツールを紹介します。 Review Boardの主な特徴5つ
コードレビューのツールについての調査 - Qiita
このドキュメントはコードレビューを支援するツールについての調査を行った結果を記述する。 ツールの紹介 Redmine Code Review プラグイン Redmineのプラグインとして動作する。 http://www.r-labs.org/projects/1/wiki/Code_Review インストール方法 通常のRedmineのプラグインと同様 使用方法 リポジトリ―でコミット済みのリビジョンの差分を取り、レビュー用のコメントを記述する。 作成したレビューはプロジェクトのコードレビュータブで一覧として表示される。 記述したレビューはチケットとして登録される。 そして、レビューで作成したチケットはリポジトリから返信とステータスの遷移が行える。 Trac Peer Review Plugin Tracのプラグインとして動作する。 http://trac-hacks.org/wiki/P
コードレビューをし合える文化がチームを強くする - ppworks.jp
コードレビューしてますか？ 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
エンジニアの面接でコードレビューさせてる
（あんま多くないみたいだから多分すぐ身バレしそうだけど書く） エンジニアの面接で実際にコードを書かせる会社が最近は多いみたいだね。でもウチでは特に面接で書かせない。というか今まで書いてきた、関わってきたコードなんて書類で大体分かるでしょ？ それよりも、ウチではコードレビューをさせてる。 選考用にわざと少し突っ込みドコロの多いコード（30〜50行程度のコードを3〜4ファイル）を渡して、もちろんファイル構成自体へのレビューも含めて、どんな意見をその人が出せるかを問う。 レビュー用のコードは複数言語用意してて、一番得意な言語を選んでもらってる。 時間は1時間。資料と赤ペン、そしてネットに繫がったパソコンを渡して、いくらでもググってもらって構わない環境でレビューを紙に赤して貰う。 「コードレビュー」ってものに対しての認識だとか、コードを管理するための能力もある程度分かるし、すごく良い選考制度だと思
初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
コードレビューをしよう - ppworks.jp
Sendagaya.rb #86 - Sendagaya.rb | Doorkeeperに参加してコードレビューについて思うところをみんなでディスカッションしたので、自分の思いをまとめておきます。（ポエム） ソニックガーデンの @mah_labさんのスライドにある7つの秘訣に同意です基本。あと、github上のプルリクでコードレビューするという前提でまとめます。 1. レビューの観点を明確に いま何の話をすべきかという状況を判断して、どの観点で物を言うのかっていうのはコードレビューだけに限らず打ち合わせ時にも大事ですね。今この観点で議論を進めますよ！ということを表明することで齟齬が防げます。 観点が明確だと議論のテーマが明確になるので、コードレビューで修正すべき点も分かりやすくなりますね。 コーディング規約の観点 セキュリティの観点 メンテンスの観点 設計の観点 リリース前にこれで出来るレ
デキるプログラマだけが知っているコードレビュー7つの秘訣
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。Read less
ソニックガーデンで行われているコードレビューの具体例をお見せします (SonicGardn Study #11 の補足として) #sg_study - give IT a try
はじめに 2014年8月11日の晩に放送されたソニックガーデンのweb勉強会、SonicGardn Studyでは「いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜」というタイトルで、弊社ソニックガーデンの西見さん(@mah_lab)が講演してくれました。 デキるプログラマだけが知っているコードレビュー7つの秘訣 from Masahiro Nishimi いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜 - YouTube この放送の中でも触れられていたように、ソニックガーデンではコードレビューを大事にしています。 ただ、勉強会のスライドの中では具体的なコード例や指摘の例がほとんど出てこなかったので、「実際どんな感じなの？」という疑問を持った方もいたんじゃないかと思います。 そこで今回は「入社
中規模iOS開発とコードレビュー
フリマアプリFrilのリニューアルを題材に、iOS開発でのコードレビュー事例を紹介します
モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Sider Review
https://www.sekai-lab.com/times/?p=3522
コードレビューの話
