「AWS Well-Architected フレームワーク」の「レビュープロセス」資料がとても良かったので紹介したい - Qiita
はじめに 仕事の品質を高める上で、知見のある方にレビューをしてもらうプロセスは欠かせません。 ただこのレビュー、やり方や意見の伝え方によっては、期待した効果が得られなかったり、ネガティブな効果を生み出しかねません。そうした結果、レビューという行為自体が開催されにくくなることは、チームにとって非常にマイナスです。 全員のレビューへの期待を整えておくために、レビューの心構えや望ましい運営方法などを、レビューに関わる全ての人が共通認識化しておくことは、非常に重要だと考えています。 今回、このレビューを効果的に進めるポイントをまとめた、とても良い資料を見つけたのでご紹介します。 レビュープロセス - AWS Well-Architected フレームワーク この資料をおすすめしたい方 エンジニアに限らず、仕事で他者の成果物をレビューをする人、および他者からレビューを受ける人（そう考えると、仕事をす
レビューでも褒めてくれたっていいじゃない - ＷＩＣの中から
何らか開発をやっている人なら、開発物が一定のレベルに達した段階でレビューを受けることになります。ソフト開発ならコードレビュー、僕のようなハードウェア設計開発だとデザインレビュー(以下、DR)です。 前の会社でも今の会社でもレビューイ(レビューされる側)として幾度となくDRを経験しました。どの会社、どのプロジェクトでもDRは例外なくキツく、精神に堪えます。 なぜかというと、DRはムチでひたすら打たれるだけでアメが貰えないんですよね。 DRは欠点探しの場 DRの目的は不味い箇所を探して改善項目を挙げることです。ちょっとでも目に付く形状があると「ん？」とレビュアー(レビューする側)の皆様が首を傾け、追及が始まります。 レビューイとして、ツッコミ入りそうな箇所にはそれなりの理屈は用意しておくわけですが、数多のレビュアーから時には論理的に、時には感覚(経験)的に、これはダメだという結論に収束させられ
WEB+DB PRESS Vol.99の「良いコード」を本気でコードレビューしてみた - give IT a try
はじめに Twitterを見てたら、気になる雑誌の特集を見つけました。 WEB+DB PRESS Vol.99の「Rubyで学ぶ！良いコードって何だろう？」という特集記事です。 WEB+DB PRESS Vol.99 作者: ?橋健一,谷口禎英,井本大登,山崎勝平,大和田純,内村元樹,坂東昌哉,平田敏之,牧大輔,板敷康洋,大?浩崇,穴井宏幸,原口宗悟,久田真寛,ふしはらかん,のざきひろふみ,うらがみ,ひげぽん,池田拓司,はまちや2,竹原,片田雄樹,渋江一晃,WEB+DB PRESS編集部編出版社/メーカー: 技術評論社発売日: 2017/06/24メディア: 大型本この商品を含むブログを見るRuby大好き！きれいなコード大好き！！な僕にとっては、この特集は読まずにはいられません！ 早速買って読んでみました。 お～、なるほど、たしかにいいことが書いてある！ うんうん、そうそう・・・あれ？この
自分の言葉で書かれたコミットメッセージが好き
誰にも質問されていないけど回答すると、ぼく個人としては「レビュー指摘事項を反映」的なコミットメッセージにはやんわり否定派で、どうしてそう変更すべきと思ったのかを自分の言葉で書く方がベターと思っています。 — juné29💩公式アカウント (@june29) January 11, 2017 140文字には納まらないな、と思ったのでちゃんとエッセイを書く人間になろう！ たとえばぼくがレビューを担当させてもらって「ここはAの方がよいと思いました」とコメントしたとして、そのときに「レビューで指摘された箇所を修正」というメッセージ付きのコミットが追加されたとする。そのあとぼくが思い直して「いや、他の箇所も考慮すると、やっぱりBの方がよさそうです」とコメントしたとする。また「レビューで指摘された箇所を修正」というコミットが追加される。 こういうやりとりだと、「レビュー」というプロセスというよりは「
コードレビューをより効果的にする方法
ツールに任せることができないどんなことを人間は指摘できるのだろうか？ 驚くほど多数の事柄があることがわかっている。この記事の残りで幅広い重要事項のリストに触れ、2つの特定の領域、パフォーマンスとセキュリティに関してはもう少し深く言及する。 設計 新しいコードは全体アーキテクチャに適合しているだろうか？ コードはSOLID原則、ドメイン駆動設計、もしくはチームが採用する他の設計手法に従っているだろうか？ 新しいコードでデザインパターンは使用されているだろうか？これらは適切だろうか？ コードベースの標準や設計スタイルが混合されている場合は、新しいコードは現在の原則に従っているだろうか？コードは現在の方向性を引き継いでいるか、徐々に除去される古いコードの例に従っているだろうか？ コードは正しい場所に配置されているだろうか？例えば、コードが注文に関係する場合は、それは注文サービスの中にあるだろうか
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://post.simplie.jp/posts/34