【IMO】コードレビューって難しいよね.pdfhttps://fortee.jp/phpcon-2021/proposal/5d39aa6d-aef2-4bed-8747-60b6d2f6adfe PHPカンファレンス2021の登壇スライドです
意識のズレを感じたら As-Is / To-Be がおすすめ ― チームでコードレビューに対する意識調査をした話 | Recruit Tech Blog
意識のズレを感じたら As-Is / To-Be がおすすめ ― チームでコードレビューに対する意識調査をした話 wakamsha As-Is / To-Be とは？ 現状と理想のギャップを的確に認識し、取り組むべき課題を抽出したうえで行動に移すためのビジネスフレームワークです。 As-Is: 現在の状態がどうであるかを表すもの。 To-Be: 理想の状態を表すもの。実現可能かどうかの制約を受けない純粋な理想（= あるべき姿）のことを指す。 主に計画や戦略の立案時に利用されるものですが、チームビルディングにおいても有効です。 理想のチームに到達するには解決すべき課題が多数存在するものですが、そういった課題が明確に把握されてることは稀です。解決するには対象である課題を明確に把握せねばなりません。 As-Is / To-Be モデルは、現状と理想とのギャップを洗い出すだけのツールです。しかし、
私的コードレビュー お作法
集団でソフトウェア開発をするときは、コードレビューをしたりされたりしながら進むのが当たり前となった昨今。 僕が自然と心掛けるようになったコードレビューお作法などをお気楽に書いてみます。 安易に「良い」とか「悪い」とか、一次元的な評価を下すのはよす他人のコードに対し、絶対的に「良い」とも絶対的に「悪い」とも、「大正義」とも言わないようにしている。 コードの書き方や設計の出来栄えは、評価するための色々な物差しがあって、「良い」「悪い」の2つに1つ、斬って捨てられるようなものではないと思う。(むしろ、そういう単純なものではないからこそおもしろいんじゃないだろうか……?) どのような指標をもちだすか、どういった利点/欠点に注目するのか、どんな畑で育ってきたプロダクトか、状況によって下すべき評価は変わるし、数えきれないほどある 設計パターンや慣習、従うべき原則、美的感覚のなかには、相反する「正しさ」
コードレビューで心がけている3つのこと【PHPカンファレンス協賛記念ブログ！】 - コネヒト開発者ブログ
こんにちは！エンジニアの @fortkle です。 あの伝説のゲーム「メダロット」のスマホゲームのリリース日がついに 2020年1月23日と発表がありました!*1 いまからワクワクしてきましたね！リリースしたらぜひロボトルしましょう！ さて、今回の記事は「コードレビュー」についてです。コネヒトに入社してから早4年、数百のPRをレビューしてきてだんだんと自分の中でコードレビューに対する接し方が定まってきました。今日は私がコードレビューで心がけていることについてご紹介できればと思います。 レビュワーとして ① "既存コード" の 歴史的経緯を素早く紐解く コードレビューは様々な目的で行われますが、「欠陥・バグを検出すること」「コードの改善」に期待をしていることが多いかと思います。 これらの目的を達成するためには、既存・変更後のコードの実装意図や背景を理解することがとても重要になります。特に長年
Google エンジニアリング・プラクティス ドキュメント
Google エンジニアリング・プラクティス ドキュメント このページは、Google Engineering Practices Documentation の非公式な日本語翻訳です。元のドキュメントは、クリエイティブ・コモンズの「CC-By 3.0」ライセンスで公開されています。 Google には、あらゆる言語・あらゆるプロジェクトをカバーする一般化されたエンジニアリング・プラクティスが数多く存在します。こうしたドキュメントは、私たちが長年に渡って開発してきたさまざまなベストプラクティスの経験が集結したものとなっています。オープンソース・プロジェクトやその他の組織でも、こうした知識から恩恵を受けられるかもしれません。そのため、私たちは可能な限り、この知識を公開するように努めています。 現在、以下のドキュメントが公開されています。 Google コードレビューガイドライン (Googl
役立つコードレビュー 8つのヒント | POSTD
役立つコードレビュー（CR）のコツは、学校では習いません。アルゴリズム、データ構造、プログラム言語の基礎は習っても、確実に役に立つフィードバックを返す方法をじっくりと教えてくれる人はいないでしょう。 コードレビューは優れたソフトウェアを作り出すには欠かせないプロセスです。レビューを通したコードは、そうでないコードよりも 質が高く、バグが少ない 傾向があります。健全なコードレビュー文化には、副次的な利点もあります。たとえば、 バス因子 を押しとどめる、新メンバーのトレーニングに最適なツールになる、など。また、コードレビューは優れた知識共有の手段でもあります。 前提 まずは、この記事のポイントの前提を提示する必要があるでしょう。それは以下のとおりです。 信頼のおける環境で作業をしている。あるいは、あなたとチームは、あなたの信頼性を高めることを目指して作業している。 コードではないシナリオでフィ
チームの振り返りとコードレビューの意外な共通点を発見した | mah365
先日とあるチームの振り返りにファシリテーターとして参加する機会があったのですが、そこでチームの振り返りとコードレビューの意外な共通点を発見したよ！というのが本日の主題です。 「お前は一体何を言っているんだ」と言わずに、聞いてくださいな。 例によって、いつも通りホワイトボードにそのチームの中から挙がる言葉を書きとめながら問題点を整理していたのですが、なんとなく、言葉の端々に遠慮している感覚があったのですよね。発言しかかって、止まってしまう人も多い。で、この遠慮している感覚はどこからきているのかな？と思って探りを入れてみると、 「そうは言っても自分でもできていないことは、なかなか言えないんですよね」 「言っても今更感があって、なかなか言い出せないんですよね」 という言葉が聞こえてきました。 なるほど、これは今チームのことを考えているのではなく、もしかすると「チームにおける私のこと」を考えている
無理をしないコードレビュー - クックパッド開発者ブログ
会員事業部の三吉（@sankichi92）です。 クックパッドでは、GitHub Enterprise の Pull Request を使ったコードレビューを広く実施しています。 この記事では、私がコードレビューすることに対する苦手意識をなくすために意識したことを紹介します。 クックパッドでは、テックリードや新卒、インターン、バイトといった肩書きに関係なく、誰もがレビュワー・レビュイーになります。 チームやプロダクトによって開発ルールは少しずつ異なりますが、私の所属する会員事業部では、PR を出したときに GHE やチャットで部内のエンジニアにメンションして、その時にレビューできる人がレビューするという形を取っています。 私は、昨年2017年に新卒入社したのですが、それまでは個人開発や研究用のコードしか書いたことがなく、短期インターンシップを除くチーム開発の経験がありませんでした。 配属当
「巨大プルリク1件vs細かいプルリク100件」問題を考える（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: 100 Duck-Sized Pull Requests 原文公開日: 2017/12 著者: Kurtis Funai 日本語タイトルは内容に即したものにしました。 2018/02/07: 初版公開 2022/02/24: 更新 Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 本記事では、昔ながらの問題である「巨大なプルリク1件と超細かいプルリク100件、どっちなら戦う気になれる？」に対する回答を示したいと思います。チームの一員としてよりよいコードを書くためのガイドラインについてもある程度解説します。今回の記事は、すべて以下のツイートから触発されました。 10 lines of code
人間らしくコードレビューするには(パート2) | Yakst
コードレビューの際に落とし穴にはまらずに、どのようにうまくコミュニケーションをとるか、に関する記事の後半部分です。著者がコードレビューで失敗した実例を元にお互いの衝突を避けるテクニックについて紹介します。 [プログラミング]原文 How to Do Code Reviews Like a Human (Part Two) - Silly Bits (English) 原文著者 Michael Lynch 原文公開日 2017-11-09 翻訳依頼者 翻訳者 taka-h 翻訳レビュアー doublemarket 原著者への翻訳報告 2151日前 メールで報告済み 2149日前 原著者承諾済み 編集 この記事はコードレビューの際に落とし穴にはまらずに、どのようにうまくコミュニケーションをとるか、に関する記事の後半部分です。今回はひどい衝突を避け成功裏にレビューを終わらせるテクニックに焦点をあ
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
人間らしくコードレビューするには(パート1) | Yakst
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
コードレビューを受けるのがつらくなったときは - めるノート
そういうときがよくあります。 コードレビューがある会社は今が初めてだけど、きっとこれから先もコードレビューがある限りは、なくならない気持ちなんだと思います。 だから、そんなときに振り返れるようなものを残しておきます。 「コードレビュー つらい」でググってみると、はてな匿名ダイアリーのこんな記事が見つかりました。 anond.hatelabo.jp さすがに、ここまでヒドいケースを経験したことはないし異常だと思ったけれど、以下のくだりは自分の胸にすごく刺さりました。 私はプログラマに向いていないんじゃないかと思う。よいプロダクトを作る上で強い言葉を交えた議論が必要不可欠ならば、それに強いストレスを感じてしまう私はプログラマとして適正がないのでは？ 刺さったのですが、それでも自分はここでやっていかなくちゃならないと思っているので、つらくなったときにいつでも読み返せるよう、見つけた記事・資料をま
チーム開発で暗黙的に行なわれている批評というプロセス - snoozer05's blog
Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。 Wikipediaでコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査（査読）を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。 2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Crit
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
余裕を生み出すコードレビュー 〜レビュイー編〜 / code-review-phpcon-2019
伝わるコードレビューのために