私のチームをドリームチームに変えたコードレビューのルール - Qiita
こちらの記事は、Elena Flat 氏により2020年4月に公開された『 How one code review rule turned my team into a dream team 』の和訳です。 本記事は原著者から許可を得た上で記事を公開しています。 本文 コードのレビューに費やす時間は、有意義な時間です。 次のシナリオを考えます。 プロダクトオーナーのボブは、3人の開発者（アリス、ケイス、デューク）のチームに、彼らが提出したばかりのコードに関して急速な修正のお願いをSlackで伝えています。 翌日の午前10時にクライアントとのミーティングがあり、ボブがデモできるように修正されていないといけません。 今は午後6時です。 アリスは退社していて、ケイスは別荘に行く途中です（彼女は休暇を取りました）。 しかし、デュークは偶然にも彼のノートパソコンの前にいます。 次に何が起こるか デュ
知識が無いからこそコードレビューで指摘をしよう - Qiita
初めに 私は他人にダメ出しできるほど優秀なプログラマーではありません。おわり。 先進めなくなるので続けます。チームで開発するようになって約３年。自分ダメダメだなーとは思いつつも、自身の成長を一番感じたのがコードレビューだったのでこんな記事を書くことにしました。 個人で開発している方や、各々が完ぺきなコードを書けるチームにいる方、１分１秒の時間が惜しいプロジェクトにいる方(そこまで行くとコードレビューちゃんとされているかわかりませんが)には向かない内容となります。また、捉え方によっては馬鹿が優秀な人の足を引っ張ることにも見えますので、自分の環境に合わないと思う方は参考にしないでください。 とおもったら、会社としてやってるところもあるんですね。 https://qiita.com/awakia/items/8344ba751426e386e0f5 他にも、かっちりしたレビュー記事はたくさんある
レビュー再定義 / Redefinition of Review #jasst #jasstreview - Speaker Deck
2018年12月14日（金）開催のJaSST Review'18の講演資料です。
コードレビューのやり方、基礎の基礎 - コード改善に重要なレビューの基本的な考え方を学ぼう - エンジニアHub｜Webエンジニアのキャリアを考える！
コードレビューのやり方、基礎の基礎 - コード改善に重要なレビューの基本的な考え方を学ぼう コードレビューとは？レビューで問題を見つけて指摘するには？レビューをされる側の心構えとは？ソフトウェアレビューを研究する名古屋大学の准教授 森崎修司さんが、コードレビューの考え方を解説します。 はじめまして森崎です。大学でソフトウェアレビューの研究をしています。さまざまな組織との共同研究、調査、議論を通じて、レビューの原理・原則や体系的な考え方・知識を明らかにしようとしています。大学で研究に従事する前にソフトウェアエンジニアとしてインターネットサービスの開発をしていたため、研究として価値があり、実務としても役に立つ研究を目指しています。 レビューは、とにかく多くの経験をつまなければ上達しないという先入観を持たれがちです。その先入観をなくして、レビューの上達やソフトウェア品質の向上につながるしくみや活
コードレビューの観点を4つ紹介！新人エンジニア向けに具体的な項目を解説します
多くのWeb系企業では、新人、ベテラン関係なく他人のレビューをする機会があります。 しかし、コードレビューのやり方は教わることがなく「何を見たら良いのかわからない」と悩む方もいるのではないでしょうか。
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
コードレビューで心がけている3つのこと【PHPカンファレンス協賛記念ブログ！】 - コネヒト開発者ブログ
こんにちは！エンジニアの @fortkle です。 あの伝説のゲーム「メダロット」のスマホゲームのリリース日がついに 2020年1月23日と発表がありました!*1 いまからワクワクしてきましたね！リリースしたらぜひロボトルしましょう！ さて、今回の記事は「コードレビュー」についてです。コネヒトに入社してから早4年、数百のPRをレビューしてきてだんだんと自分の中でコードレビューに対する接し方が定まってきました。今日は私がコードレビューで心がけていることについてご紹介できればと思います。 レビュワーとして ① "既存コード" の 歴史的経緯を素早く紐解く コードレビューは様々な目的で行われますが、「欠陥・バグを検出すること」「コードの改善」に期待をしていることが多いかと思います。 これらの目的を達成するためには、既存・変更後のコードの実装意図や背景を理解することがとても重要になります。特に長年
コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
Code Health: Respectful Reviews == Useful Reviews
Interesting. I would caution that some of the tips are very culture-dependent. For instance, the example of not criticizing the person - I would rather have someone tell me straight in my face "Your approach is adding unnecessary complexity" than go around in circles and word-dancing around it, I would appreciate the honesty and the respect for my time (the 2nd way of phrasing is longer. but more
コードレビュー現場でのコミュニケーション - Tech Blog
Timers Tech blog での2回目の投稿となります。 サーバエンジニアの長南です。 先日弊社CTOのアマドの「コミュニケーション能力はエンジニアにとって必要不可欠な能力である」という記事がありました。 techblog.timers-inc.com 考えてみると、開発の現場はコミュニケーションの連続です。UI/UXは開発者とエンドユーザの間でのコミュニケーションの場ですし、この Blog を表示されるために行われる HTTP や HTTPS、よりレイヤーの低い TCP/IP といったプロトコルもコミュニケーションのひとつの形です。そもそもコードを書くということ自体が人間とコンピュータの間のコミュニケーションと言っていいでしょう。 実際の開発現場、コードレビューの現場でどのようなコミュニケーションをとればよいのかということを紹介します。 コードレビュー 一般企業では外部に提出する書
How to do a code review
How to do a code review The pages in this section contain recommendations on the best way to do code reviews, based on long experience. All together they represent one complete document, broken up into many separate sections. You don’t have to read them all, but many people have found it very helpful to themselves and their team to read the entire set. The Standard of Code Review What to Look For
Code review guidelines – Part 1
Last updated on 27th of January. Please also read Code Review Guidelines Part 2. What is a Code Review? Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills. Why Reviews are important? Quoting from Code
Effective Code Reviews Without the Pain | Developer.com
Code reviews in most organizations are a painful experience for everyone involved. The developer often feels like it’s a bashing session designed to beat out their will. The development leads are often confused as to what is important to point out and what isn’t. And other developers that may be involved often use this as a chance to show how much better they can be by pointing out possible issues
guides/code-review at main · thoughtbot/guides
Accept that many programming decisions are opinions Discuss tradeoffs, which you prefer, and reach a resolution quickly. Ask good questions; don't make demands "What do you think about naming this :user_id?" Good questions avoid judgment and avoid assumptions about the author's perspective Ask for clarification "I didn't understand. Can you clarify?" Avoid selective ownership of code "Mine", "not
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Alex Hill | The Art of Giving and Receiving Code Reviews (Gracefully)
レビューの仕方
https://slideship.com/users/@massa142/presentations/2020/07/45muxmQzWHqr4iZYR73wBM/
ホーム - CloneTracker
コードレビューのススメ
Redirecting...