コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
僕がコードレビューの時に気をつけていること｜su-
いきなりがっつりとした記事を書くよりは慣れるために軽めの話を。 こんにちは、すーです。 今回は普段僕がコードレビュ(GitHubのPull Requestのレビュー)の時に気をつけていること、大切にしていることを書いてみます。 (※以降話は主にGitHubのPullRequest(PRと略します)上での話がメインだと捉えてもらえますと) 自分がレビューをするときまずは自分がレビュワーだった場合に、気をつけていることを。 ・ PRの概要、関連するIssueの内容をしっかり読む まずはじめにPRの概要や、関連するIssueの内容を確認します。 何も見ずにいきなりコードに目をやってしまうと的外れなレビューをしてしまう可能性もありますし、コードの善し悪しだけを追いがちになってしまいます。 どういう意図や背景があってこのPRが出されたのかを確認するのはとても大事になります。 ・ コメントに`[MUS
コードレビューのやり方、基礎の基礎 - コード改善に重要なレビューの基本的な考え方を学ぼう - エンジニアHub｜Webエンジニアのキャリアを考える！
コードレビューのやり方、基礎の基礎 - コード改善に重要なレビューの基本的な考え方を学ぼう コードレビューとは？レビューで問題を見つけて指摘するには？レビューをされる側の心構えとは？ソフトウェアレビューを研究する名古屋大学の准教授 森崎修司さんが、コードレビューの考え方を解説します。 はじめまして森崎です。大学でソフトウェアレビューの研究をしています。さまざまな組織との共同研究、調査、議論を通じて、レビューの原理・原則や体系的な考え方・知識を明らかにしようとしています。大学で研究に従事する前にソフトウェアエンジニアとしてインターネットサービスの開発をしていたため、研究として価値があり、実務としても役に立つ研究を目指しています。 レビューは、とにかく多くの経験をつまなければ上達しないという先入観を持たれがちです。その先入観をなくして、レビューの上達やソフトウェア品質の向上につながるしくみや活
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
コードレビューを受けるのがつらくなったときは - めるノート
そういうときがよくあります。 コードレビューがある会社は今が初めてだけど、きっとこれから先もコードレビューがある限りは、なくならない気持ちなんだと思います。 だから、そんなときに振り返れるようなものを残しておきます。 「コードレビュー つらい」でググってみると、はてな匿名ダイアリーのこんな記事が見つかりました。 anond.hatelabo.jp さすがに、ここまでヒドいケースを経験したことはないし異常だと思ったけれど、以下のくだりは自分の胸にすごく刺さりました。 私はプログラマに向いていないんじゃないかと思う。よいプロダクトを作る上で強い言葉を交えた議論が必要不可欠ならば、それに強いストレスを感じてしまう私はプログラマとして適正がないのでは？ 刺さったのですが、それでも自分はここでやっていかなくちゃならないと思っているので、つらくなったときにいつでも読み返せるよう、見つけた記事・資料をま
「速」を落とさないコードレビュー
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/
コードレビューをより効果的にする方法
ツールに任せることができないどんなことを人間は指摘できるのだろうか？ 驚くほど多数の事柄があることがわかっている。この記事の残りで幅広い重要事項のリストに触れ、2つの特定の領域、パフォーマンスとセキュリティに関してはもう少し深く言及する。 設計 新しいコードは全体アーキテクチャに適合しているだろうか？ コードはSOLID原則、ドメイン駆動設計、もしくはチームが採用する他の設計手法に従っているだろうか？ 新しいコードでデザインパターンは使用されているだろうか？これらは適切だろうか？ コードベースの標準や設計スタイルが混合されている場合は、新しいコードは現在の原則に従っているだろうか？コードは現在の方向性を引き継いでいるか、徐々に除去される古いコードの例に従っているだろうか？ コードは正しい場所に配置されているだろうか？例えば、コードが注文に関係する場合は、それは注文サービスの中にあるだろうか
仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;
これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな
ソニックガーデンで行われているコードレビューの具体例をお見せします (SonicGardn Study #11 の補足として) #sg_study - give IT a try
はじめに 2014年8月11日の晩に放送されたソニックガーデンのweb勉強会、SonicGardn Studyでは「いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜」というタイトルで、弊社ソニックガーデンの西見さん(@mah_lab)が講演してくれました。 デキるプログラマだけが知っているコードレビュー7つの秘訣 from Masahiro Nishimi いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜 - YouTube この放送の中でも触れられていたように、ソニックガーデンではコードレビューを大事にしています。 ただ、勉強会のスライドの中では具体的なコード例や指摘の例がほとんど出てこなかったので、「実際どんな感じなの？」という疑問を持った方もいたんじゃないかと思います。 そこで今回は「入社
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビュー自動化の最前線から