アジャイル開発のコードレビューで、建設的なコミュニケーションを行うための心構え
チームでのアジャイル開発において、コードレビューは最も重要な工程の1つです。『アジャイルプラクティスガイドブック』（翔泳社）では、その目的が「ソースコードを書いた人の持ち物から、チームの共同所有物にする」ことだとされていますが、メンバーの考え方が違ったり責任の所在が曖昧になったりと、トラブルの種となることも少なくありません。今回は本書から、コードレビューで建設的なコミュニケーションを行うための心構えを紹介します。 本記事は『アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知』（著者：常松祐一、監修：川口恭伸／松元健）の「第2章 「実装」で活用できるプラクティス」から一部を抜粋したものです。掲載にあたって編集しています。 コードレビューの目的 【プラクティス】ソースコードの共同所有 筆者はコードレビューの一番の目的を「ソースコードを書いた人の持ち物から、チームの共同
承認ではなくて、よさそう、と思って暮らしている - hitode909の日記
普通に書いたdiffは、関心がさまざまなところに散らばっていたたり、書きかけだったりで、意味のまとまりがないもので、それを整形して、説明を書いたものがPull Requestであり、コードレビューは、そのまとまりごとに、他人から見て理解可能であるという承認する行為、という理解をしていた。 なので、レビューを通すことは、動くことに賭けて、以後、動かなかったら責任を取る、みたいなイメージはあまり持っていなかった。 レビュワーの責任をどこまでと規定するか考えて、責任が大きい順に並べていくと レビューを通した以上、以後は私の責任です、という態度 職人魂を感じる 見たところよさそうに思いました、という態度 通りすがり風情を感じる まったくの無責任なので、工数最小化のために何が来てもapproveする、という態度 やっつけ仕事 かるぱさんのチームでは1になっているのかな(追記)こうなっている、というこ
やらないなんてもったいない！チーム開発におけるコードレビューのススメ | クリエイターのための総合情報サイト CREATIVE VILLAGE
みなさんのチームでは、コードレビューは行っているでしょうか？ メンバーズエッジカンパニーではリモートチームによるアジャイル開発を行っており、自分のチームでは言語にPython、フレームワークにDjangoを使った、業務系システムを作っています。 自分のチームでもコードレビューを行っていますが、自分はチームの立ち上げから関わり、かつプログラマーとしての経験も長いため、レビューをする立場が多いです。 この記事では、チーム開発においてのコードレビューの意義と手段について紹介していきます。 池本 英貴（いけもと ひでき）氏 株式会社メンバーズ メンバーズエッジカンパニー Webエンジニア 2019年中途入社。 神戸オフィスにて1年間の修行後、愛媛県にてフル在宅勤務中。 好きなハードはNeXTcubeです。 コードレビューの意義 コードレビューをする意義は何でしょうか。自分は4つあると考えています。
データ分析者たちのコードレビュー #とは - 散らかったJupyter notebookを片付けるかどうするか問題を考える - JX通信社エンジニアブログ
JX通信社シニアエンジニアの@shinyorkeです. 最近はチームの朝会でよく着ているTシャツにツッコミを受けてます.*1 JX通信社では, いい感じにデータを整備・運用しているデータ基盤を駆使して, BI（Business Intelligence）文脈でのデータ分析・可視化. ダッシュボード作ったり. 機械学習的なアプローチを使ったR&Dと機能開発（分類タスクなど） といった業務・タスクを社員・インターン問わず行っています. データ分析でSQLを書いたり, 「新しいアルゴリズム試すやで！」的なノリでPythonのコードをゴリゴリ書く・動かして結果を見て振り返ってまた臨む...って楽しいですよね. チームの皆さんも, もちろん私もモチベーション高くやってるわけですが！？ あれ, notebookどこ行ったんや...🤔 よくありますよねー（震え） 自分もチームメイトも, 前のめりになっ
【クラウド録画サービス、Safie( セーフィー) 】リーダブルコードをプルリクレビュー改善に活用する - Safie Engineers' Blog!
こんにちは！セーフィー株式会社のサービス開発部 モバイルチームの北本です。 主にSafie ViewerのiOSアプリの開発を担当しています。 今回は、リーダブルコードを読んで、プルリクレビュー改善に活用する話をしたいと思います。 なぜリーダブルコードを読むのか リーダブルコードとは？ リーダブルコードに書かれていたこと 理解しやすいコードとは？ 表面上の改善（第Ⅰ部） 命名規則について コメントについて ループとロジックの単純化（第Ⅱ部） 関数から早く返す、ネストを浅くする 変数を用いて分割する 変数のスコープと変更 コードの再編成（第Ⅲ部） 無関係な下位問題を抽出する 一度にひとつのことを ロジックを明確に説明できるか？ 短いコードを書く さいごに なぜリーダブルコードを読むのか セーフィーモバイルチームは現在、チームビルディングを積極的に進めています。 ある日のミーティング時に、コー
レビューしやすいプルリクエスト | DevelopersIO
普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 割と大きめなソースコードに対するレビューの話が主となります。 ざっくりまとめ 本記事では以下のようなトピックについて記載しています。 差分の目的が1つ レビューをしながら「私はいま何のレビューをしているのか」のコンテキストスイッチが発生しないので嬉しい 何を達成したいのかがわかる レビューの多くは「やりたいこと」と「実現方法」のすり合わせなので、前者の精度を上げたい 分割されすぎていない 他のコードとの関連性や構造についてのレビューがしやすい レビューの強弱をつけるための情報がついている 機械的な変換の差分だったりした場合、それが事前にわかると嬉しい 検証結果が書いてある コードだ
GoでWebアプリ開発時にあるあるだったレビューコメント | フューチャー技術ブログ
The Gopher character is based on the Go mascot designed by Renée French. はじめにTIG DXユニット 1の真野です。 コードレビューについては3,4年ほど前に、コードレビューにおけるレビュアー側のアンチパターン って記事を書いたりもしました。当時はレビュアーの伝え方って大事だよなって話をしてました。いつしかレビュイーからレビュアーに比重が変わることが増えてきました。相互レビューは当たり前にしていますがが、比較的こうしたらもっと良くなるんじゃないかな？と提案される回数より、自分が提案する回数の方が増えてくるタイミングってありますよね？ そういうわけで、最近Goで主にバックエンドのWebAPIや、AWS Lambdaで動くETLアプリ、たまにCLIツールを開発する時に、2回以上同じ指摘したコメントをまとめてます。Go言語
自分より数段レベルが上のプログラマーが書いたプログラムのソースレビューは何をすればよいのでしょうか？
回答 (5件中の1件目) 既に良回答が出ていますが、別に気負うことなく、真摯にレビューに臨めばいいと思います。 わからないところは素直に聞けばいいですし、逆に相手も人間ですからポカミスや勘違いがないとは限りません。本人に気付かない事でも他人なら気づく可能性があるのでレビューをするわけで、レベルが高い人だからと言って、特に大きくスタンスを変える必要はないと思います。委縮してこの人なら間違いはないなどという思い込みでコードを見たりする方がかえってレビューの意味がなくなります。そこにあるものを出来るだけ客観的に見ることかと思います。 レビューはレビューであって、いちゃもんを付けたり粗探しの...
コードレビューで「違和感」という言葉を使わない - okuzawatsの日記
雑感です。カップ麺ができるまでに書き散らします。 コードレビューをする時、「違和感がある」というような言葉を使わないようにしています。「違和感がある」という言い方は便利なのですが、何がどうダメなのかを言っていないため、それをレビュイーに考えさせ、余計なコミュニケーションを取ることになる気がしているためです。 そのため、「違和感がある」というようなレビューをしそうになったときには、何についてどのような違和感があるのかを言語化して、具体的なコメントをするようにした方が良いと思います。 雑な例（適当に考えました）： before この処理をこのクラス内で行うのは違和感があります after このクラスの責務はhogefugaなので、この処理は新たにFooClassを作ってそちらで行うようにした方が良いと思います そろそろカップ麺ができるので、この辺で失礼します。
人の作ったWebアプリケーションのコードを見るときに注目しているところ - Runner in the High
普段見ているものをなんとなく書き出してみた。 インターフェイス あえてやってないとか、レイヤ的にやる必要がないというケースもある。しかし、ある程度の規模のソフトウェアには大抵インターフェイスが現れる。インターフェイスがないコードはユニットテストもないことが多い。したがって、インターフェイスが現れないコードは責務分離が行われてない可能性を感じたりする。 言語機能上インターフェイスがない動的型付け言語の場合には、ダックタイピングを意識したコードが書かれているかをチェックする。ダックタイピングでなくとも、例えばRubyだったら抽象クラスと実装クラスの分離が行われているかを見たりする。 バリデーションロジック すべてのバリデーションが、フレームワークの機能で実装されてたりしないかをチェックする。MVCとかクリーンアーキテクチャ的な実装であれば、それぞれのレイヤでどういうバリデーションをしているのか
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
より良いコードレビューをするために気をつけていること
Merpay Advent Calendar 2019 の22日目は、メルペイスマート払いチーム/Backend Engineer の @oinume がお送りします。今日はコードレビューについて自分が普段から実践していることを書いてみたいと思います。 はじめに 世の中にはコードレビューをする時の観点については数多く共有されていますが、より良いコードレビューをするためにはどうするのが良いか、というHOWについてのノウハウはあまりシェアされていないような気がしています。そのため、今日は自分なりに心がけているコードレビューのやり方と、ついでに気をつけている観点について書きたいと思います。 Slackを閉じる (これが本当に一番大事だと思っているので最初に持ってきたのですが)私は極端に集中力がないため、SlackのDesktop通知が来るとついついそれが気になって見てしまいます。コードレビューの
コードレビュー自動化、障害注入／分散トレーシング、マルチクラウドIaC――コンテナベースのCI/CDがもたらす新たな開発者体験とは
コードレビュー自動化、障害注入／分散トレーシング、マルチクラウドIaC――コンテナベースのCI/CDがもたらす新たな開発者体験とは：コンテナベースのCI/CD本番事例大解剖（終）（1/2 ページ） Kubernetes、コンテナ技術を活用したCI/CD基盤におけるサービス開発について、リクルートテクノロジーズの事例を基に解説する連載。最終回は、「プロダクト品質の磨き込み」「アジリティの向上への取り組み」の2つを中心に解説を進めます。 本連載「コンテナベースのCI/CD本番事例大解剖」では、リクルートテクノロジーズが取り組んだ事例を基に、Kubernetes、コンテナ技術を活用したCI/CD（継続的インテグレーション／継続的デリバリー）基盤におけるサービス開発について解説しています。 これまで3回にわたる連載では、アプリケーションエンジニアおよびインフラ／運用エンジニアの観点から、技術選定に
「割れ窓」を増やさないためのコード設計 / design not to broke additional window
PHPカンファレンス沖縄 2019で話したレガシーコード改善手法の一つについてです
Google エンジニアリング・プラクティス ドキュメント
Google エンジニアリング・プラクティス ドキュメント このページは、Google Engineering Practices Documentation の非公式な日本語翻訳です。元のドキュメントは、クリエイティブ・コモンズの「CC-By 3.0」ライセンスで公開されています。 Google には、あらゆる言語・あらゆるプロジェクトをカバーする一般化されたエンジニアリング・プラクティスが数多く存在します。こうしたドキュメントは、私たちが長年に渡って開発してきたさまざまなベストプラクティスの経験が集結したものとなっています。オープンソース・プロジェクトやその他の組織でも、こうした知識から恩恵を受けられるかもしれません。そのため、私たちは可能な限り、この知識を公開するように努めています。 現在、以下のドキュメントが公開されています。 Google コードレビューガイドライン (Googl
Googleがコードレビューのガイドラインなど、ソフトウェアエンジニアリング実践のためのドキュメント「Google Engineering Practices Documentation」を公開
Googleがコードレビューのガイドラインなど、ソフトウェアエンジニアリング実践のためのドキュメント「Google Engineering Practices Documentation」を公開 ライセンスはクリエイティブコモンズの「表示 3.0 非移植 (CC BY 3.0)」で、複製や再配布、営利目的を含めた改変や翻案が可能になっています。 Googleで一般化されたエンジニアリングプラクティス Googleはこのドキュメントを次のように紹介しています。 Google has many generalized engineering practices that cover all languages and all projects. These documents represent our collective experience of various best practic
私が（iOS エンジニアの）採用でコードチェックする時何を見ているのか - Qiita
2021-10-17 追加 弊社の Android 採用課題も公開されましたので、そのリンクを追加しました。 2020-05-18 追加 本日から弊社の採用課題がこちらに変更されました。これまではアプリをゼロから作成していただく課題でしたが、今後は既存のコードをリファクタリングしてもらう課題となりました。ただし我々が確認する項目はそれほど大きく変更するわけではありませんので、本記事の内容の多くは引き続き有効です。 ここ数ヶ月は、iOS のエンジニア採用のコードチェックにもよく参加していますので、そろそろ良さそうと思って、ここで私がコードチェックする時に一体何をチェックしているのかを共有し、皆さんの転職活動やキャリア設計に役に立てればと思います。 Disclaimer この記事の内容はあくまで株式会社ゆめみの iOS エンジニア採用のものです。弊社以外の iOS エンジニア採用や、弊社でも
「気に入らないコード」をレビューする際にRed Hatのエンジニアはどうしているのか
「気に入らないコード」をレビューする際にRed Hatのエンジニアはどうしているのか：10個のヒントとは？ プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合はどうしたらよいだろうか。Red Hatのソフトウェアエンジニアが、コードレビューを行うに当たって念頭に置くべき10のヒントを解説した。 Red Hatでソフトウェアエンジニアを務めるデビッド・ロイド氏は2019年7月8日（米国時間）、コードレビューを行うに当たって念頭に置くべき10のヒントを同社の開発者向け公式ブログで解説した。プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合に役立つ指針だ。コントリビューター側としても参考になる。 これらのヒントは、客観的で的を射たレビューを行い、プロジェクトとその参加者を前進させるという観点からまとめられている。 （1）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レビューの仕方
余裕を生み出すコードレビュー 〜レビュイー編〜 / code-review-phpcon-2019
