私のチームをドリームチームに変えたコードレビューのルール - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こちらの記事は、Elena Flat 氏により2020年4月に公開された『 How one code review rule turned my team into a dream team 』の和訳です。 本記事は原著者から許可を得た上で記事を公開しています。 本文 コードのレビューに費やす時間は、有意義な時間です。 次のシナリオを考えます。 プロダクトオーナーのボブは、3人の開発者（アリス、ケイス、デューク）のチームに、彼らが提出したばかりのコードに関して急速な修正のお願いをSlackで伝えています。 翌日の午前10時にクライアント
知識が無いからこそコードレビューで指摘をしよう - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初めに 私は他人にダメ出しできるほど優秀なプログラマーではありません。おわり。 先進めなくなるので続けます。チームで開発するようになって約３年。自分ダメダメだなーとは思いつつも、自身の成長を一番感じたのがコードレビューだったのでこんな記事を書くことにしました。 個人で開発している方や、各々が完ぺきなコードを書けるチームにいる方、１分１秒の時間が惜しいプロジェクトにいる方(そこまで行くとコードレビューちゃんとされているかわかりませんが)には向かない内容となります。また、捉え方によっては馬鹿が優秀な人の足を引っ張ることにも見えますので、自分
レビュー再定義 / Redefinition of Review #jasst #jasstreview - Speaker Deck
2018年12月14日（金）開催のJaSST Review'18の講演資料です。
コードレビューのやり方、基礎の基礎 - コード改善に重要なレビューの基本的な考え方を学ぼう - エンジニアHub｜Webエンジニアのキャリアを考える！
コードレビューのやり方、基礎の基礎 - コード改善に重要なレビューの基本的な考え方を学ぼう コードレビューとは？レビューで問題を見つけて指摘するには？レビューをされる側の心構えとは？ソフトウェアレビューを研究する名古屋大学の准教授 森崎修司さんが、コードレビューの考え方を解説します。 はじめまして森崎です。大学でソフトウェアレビューの研究をしています。さまざまな組織との共同研究、調査、議論を通じて、レビューの原理・原則や体系的な考え方・知識を明らかにしようとしています。大学で研究に従事する前にソフトウェアエンジニアとしてインターネットサービスの開発をしていたため、研究として価値があり、実務としても役に立つ研究を目指しています。 レビューは、とにかく多くの経験をつまなければ上達しないという先入観を持たれがちです。その先入観をなくして、レビューの上達やソフトウェア品質の向上につながるしくみや活
コードレビューの観点を4つ紹介！新人エンジニア向けに具体的な項目を解説します
多くのWeb系企業では、新人、ベテラン関係なく他人のレビューをする機会があります。 しかし、コードレビューのやり方は教わることがなく「何を見たら良いのかわからない」と悩む方もいるのではないでしょうか。
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
熟練レビュワーでもやりがちな失敗は、 その日の気分・体調によって、「読みやすい・読みにくい」の評価が変わってしまい、 レビューイがヘイトをため込んでしまうやつである。 機能性の「バグってる・バグってない」や「非機能性の例えば脆弱性がある・ない」は、 YESかNOか判定可能であるが、可読性や保守性とは程度であり、 基準が示されなければ、判定結果は「気分」と言われても仕方なく、実際気分で変わってしまう。 私は指摘内容が「気分」と言われたくなかったのと、 「だれだこのゴミソース書いたやつ⇒すまん俺だった」の常習犯だった自分自身を一番信用してなかったので、 以下の基準等を明示することにした。（ほかにもある） コード行数30行以内。20行以下推奨。 極力コンパクトにしておかないと全体把握にパワーを割かれ、 読み間違え、バグのリスクが高まるから 30行以内なのは、スクロールが必要かどうかを基準とする
コードレビューで心がけている3つのこと【PHPカンファレンス協賛記念ブログ！】 - コネヒト開発者ブログ
こんにちは！エンジニアの @fortkle です。 あの伝説のゲーム「メダロット」のスマホゲームのリリース日がついに 2020年1月23日と発表がありました!*1 いまからワクワクしてきましたね！リリースしたらぜひロボトルしましょう！ さて、今回の記事は「コードレビュー」についてです。コネヒトに入社してから早4年、数百のPRをレビューしてきてだんだんと自分の中でコードレビューに対する接し方が定まってきました。今日は私がコードレビューで心がけていることについてご紹介できればと思います。 レビュワーとして ① "既存コード" の 歴史的経緯を素早く紐解く コードレビューは様々な目的で行われますが、「欠陥・バグを検出すること」「コードの改善」に期待をしていることが多いかと思います。 これらの目的を達成するためには、既存・変更後のコードの実装意図や背景を理解することがとても重要になります。特に長年
コードレビュー虎の巻 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? レビューガイドライン(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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
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...
guides/code-review at main · thoughtbot/guides
