Pull Requestのレビュー負荷を軽減し、開発生産性を向上するためにチームで取り組んだこと - ZOZO TECH BLOG
はじめに こんにちは。WEARフロントエンド部Webチームの藤井です。私たちのチームでは、WEARのWebサイトのリプレイスと新規機能の開発を並行して進めています。これらの開発を推進する中で、Pull Requestのレビュー負荷を軽減し、開発生産性を向上させるための取り組みを行なってきました。本記事では、その中で効果的だった取り組みについてご紹介します。 目次 はじめに 目次 背景と課題 レビューの体制の薄さ スコープの広さ 仕様把握の負担 対応内容についての説明不足 処理の複雑性 仕様の抜け漏れ 動作確認の手間 課題解決に向けた取り組み レビュー体制の見直し Pull Requestを小さくする Issueを小さくする Pull Requestの粒度について明文化する 機械的なチェックの拡充 ESLintルールの拡充 Visual Regression Testの拡充 Pull Req
レビュアーとして早く成長する3つの方法 停滞を打ち破り、効率良く成長している実感を得るためのヒント レビュアーとして成長するには 橋本氏の自己紹介 橋本遼太氏：今日は「レビュアーとして成長するには」というテーマで発表していきたいと思います。 今日話すことは、レビュアーとして早く成長する方法です。新人プログラマーは、自分の成長の方法の一例として、ベテランの方は「若手をこうやってレビュアーとして成長させれば」という育て方の一例として参考にしてもらえればなと思っています。 軽く自己紹介をします。橋本遼太なので、「はっしー」と呼ばれています。2023年で27歳になります。（スライドを示して）出身地はこんな感じで、今は岡山市に住んでいます。 趣味はいろいろあるんですが。あっ、イメージですね。今は金髪でひげも生えちゃって……。この時の僕はどこに行っちゃったのか（笑）。 そんな感じで、プログラマーが最初
はじめに 以前からGitHubのプルリクにAIサポート、Copilotがあればいいのにと思っていました。 Github Copilot for Pull RequestもありますがCopilot Enterpriseに登録した企業のみなので シンプルかつ個人でも始められそうなChatGPT CodeReviewを導入してみます。 ChatGPT CodeReviewを導入する OpenAIの作業 1. OpenAIアカウントに登録、ログインする 2. 課金する Setting - Billingを選択します。 Add to credit balanceを選択して、クレジットカードを登録します。 ミニマム$5〜から課金を行います。 3. APIKey作成 API Keysを選択します。 Create New Secret keyを選択してAPI Keyを作成します。 API keyを安全な場
Bluesky、AT Protocol開発助成金を発表 ――招待制廃止、連合機能の実装に続き、オープンな開発エコシステムによる成長がさらに加速 2024年3月6日、分散型SNS「Bluesky」は、同サービスの根幹となるオープンプロトコル「AT Protocol」の一層の開発拡大・促進を目指すために、AT Protocol開発を対象とした助成金を発表した。 開発促進のエコシステムとしての助成金 Blueskyは、2023年1月にiOS/Android版アプリとしてリリースされた分散型SNSの1つ。元々、Twitter共同創業者の1人であるJack Dorsey氏らが集まって始まったプロジェクトで、リリース当初は招待制のSNSとして、熱量の高いユーザを中心に限定した中でサービスが動いていた。 その後、後述のように招待性が廃止、さらにBlueskyの注目機能の1つである連合機能の実
CSRF対策のやり方、そろそろアップデートしませんか / Update your knowledge of CSRF protection
PHPerKaigi 2024 • Day 1での登壇資料です。 https://phperkaigi.jp/2024/ https://fortee.jp/phperkaigi-2024/proposal/0d0f8507-0a53-46f6-bca6-23386d78f17f ※ Authorizationヘッダーを利用したBearerトークン等の活用については言及していません。
Google、次世代AIモデル「Gemini 1.5」を発表 「10万行のソースコードから修正を提案するデモ」も公開
Googleは2024年2月15日（米国時間）、同社の大規模言語モデル（LLM）「Gemini」の次世代モデルである「Gemini 1.5」を発表した。 Geminiは、テキスト／画像／音声／数値など複数の種類のデータ（モダリティ）を処理できるマルチモーダルAI（人工知能）モデル。Googleは、Gemini 1.5の初期テスト用モデルとして「Gemini 1.5 Pro」の提供を開始している。Gemini 1.5 Proは、12万8000トークンのコンテキストウィンドウを持つ中規模のマルチモーダルモデルだ。 一部の開発者と顧客は「Generative AI Studio」「Vertex AI」を通じて、最大100万トークンのコンテキストウィンドウを持つ限定プレビュー版のGemini 1.5 Proを試すこともできる。Gemini 1.5では、より少ないコンピューティングでも、Gemini
コードレビューが怖かった私の、レビューへの向き合い方が変わった話 ソニックガーデンジムに参加してコードに対する向き合い方が変わった話 登川氏の自己紹介 登川仁至氏：じゃあ始めていきたいと思います。「ソニックガーデンジムに参加してコードに対する向き合い方が変わった話」という長めなタイトルなんですが、そのまんまの感じになります。 まず自己紹介から言っていきます。ソニックガーデンジム7期生。前期ですね。プログラマー歴も2、3年ぐらいですね。今はWebアプリケーション開発をしています。沖縄に住んでいて今日はすごく暑くて半袖でもぜんぜんいけました。すごく暖かいです。「白くま」が横なのは、あんまり気にしないでください（笑）。ちなみに名前は「ノボ」です。よろしくお願いします。 本セッションで話すこと 今回何を話すのかです。タイトルどおり、「ソニックガーデンジムに参加してコードに対する向き合い方が変わった
良いソフトウェアとコードレビュー / Good software and code review
Scala + Caliban で作るGraphQL バックエンド / Making GraphQL Backend with Scala + Caliban
＼スニダンを開発しているSODA inc.の Advent Calendar 10日目の記事です!!!／ こんにちは！！！！SODA開発部の矢野です！！！ はじめに 私のチームでは一年前からコードレビューを最優先に実施するという取り組みをしています。この取り組みを継続した結果開発生産性にも良い影響を与えてくれたかもしれないので記事にしようと思います！ ちょうどこの記事を作成しているときにX(旧Twitter)で「PRのレビューを最優先にしたらチームの生産性が上がった」の投稿にたくさんのいいねがついていたので、コードレビューを最優先に取り組んで効果を実感している組織やチームが多いのかもしれないですね。 レビューを最優先にした結果 結果から書くと、 「コードレビューを最優先にする」取り組み前後の「レビューからアプルーブまでの平均時間」を比較すると6.5時間から2.5時間に縮まりました（本当かな
Linuxの生みの親であるLinus Torvalds氏は、ここしばらく表舞台に顔を見せていなかった。しかし、Linux Foundationのが開催したOpen Source Summit Japanでは、久々に多くの聴衆がいる場に姿を見せ、同氏の友人であり、Verizonのオープンソース責任者を務めるDirk Hohndel氏を相手に対談を行い、Linuxの現状について語った。 2人はまず、次のLinuxカーネルリリースである「Linux 6.7」について話した。Torvalds氏は、日本に向かう直前に、Linux 6.7の4番目のリリース候補版をリリースしたところだった。順調に行けば、クリスマス頃にLinuxカーネルの次のバージョンがリリースされても不思議ではないペースだ。 このようなスケジュールになったのは、Torvalds氏が「マージウィンドウをクリスマスの時期に持ってきて、クリ
コードレビューの思想や心構え - Qiita
株式会社ブレインパッドでデータサイエンティストをしているasanoです。 この記事はBrainPad Advent Calender 2023 1日目の記事シリーズ2です。 ※シリーズ1は@fuyu_quantさんの入力プロンプトを復元する技術 #ChatGPTです！ 今日はコードレビューの思想や心構えについて書きます。 はじめに コードレビューをより生産的に進めるには単にコーディングのスキルだけでなく、そもそものコードレビューに対する思想や心構えについても一定のリテラシーを求められると考えています。 コードレビューはどうしてもロジカルな話になるため伝え方にも気を付けないとモチベーションの低下に繋がりやすいと考えています。 そうなると当然パフォーマンスも下がってしまいます。 これを防ぐために自分は「コードレビューの思想・心構え」をまとめてチームのガイドラインとして使っています。 あくまで主
こんにちは、ソーシャル経済メディア「NewsPicks」のむとうです。 この記事は NewsPicks アドベントカレンダー 2023 の3日目の記事です。 昨日は@J_Nakagawa(隼佑 中川)さんによる『LambdaレスポンスストリーミングとAWS-SDKを使ってSlackに進捗バーを表示させる』でした！ 世の中には再現が難しく一見してバグがありそうに思えないコードもありますが、一方でプロダクションコードの中にはひと目見てバグが有りそうなコードもまた多いものです。いくつかの特定のパターンをとる文字列(環境名など)やenum(以下どちらもenumと表現します)に関する条件分岐もその一つです。プルリクを見てこのようなパターンがあれば、バグの疑いが強くなります。周囲を見渡すと、大抵すでにバグっているか潜在バグを含むコードが見つかります。すべてバグというのは言い過ぎにせよ、わかりやすさと変
プログラミングの原則：構造化テキストを文字列結合で作らない、置換でいじらない - Uzabase for Engineers
こんにちは、ソーシャル経済メディア「NewsPicks」のむとうです。 先日から『Ghost of Tsushima』の開発者が書いた『ルールズ・オブ・プログラミング』という本をちょっとずつ読み進めていて、プログラミング熱が高まっています。この本は大きな指針を示すだけで具体の話をするものではないのですが、読み物として面白いので私も似たようなことをやってみたくなりました。 何年もこういう仕事をしているとバグが入るパターンというのが見えてきます。そしてだいたいどこに行っても何の仕事でも似たようなことをすることになるのですが、今回の話もその一つです。 構造化テキストを文字列結合で作らない、置換でいじらないというのはこれだけみると何のことか分かりづらいかも知れませんがSaaS Product Team セキュアコーディングの啓蒙 第2回 （SQL インジェクション編）の内容とある面では同じ話です。
"コード品質向上のいろは - 先達に学ぶ実践例 Lunch LT" の資料です。 https://findy.connpass.com/event/300912/
「コードがむずかしい」からの脱却
コード品質向上のいろは - 先達に学ぶ実践例 Lunch LT https://findy.connpass.com/event/300912/
特に個人開発者向け！CodeRabbit(自動レビューツール)を使えばコードの健康まで得られることに気づいた話
↑by Image Creator from Microsoft Bing CodeRabbitのレビュー もう初回コードレビューはAIに任せる時代になった - CodeRabbit -を読んだ。レビューはとても負担が多く、時間もかかる。これをAIがやってくれたら、こんな有難いことはない。というわけですぐに使ってみた。 CodeRabbitを使った結論 結論から書くと、レスポンスも速く、技術レベルも高く、気を使う必要もない上に、コミュニケーションも出来る。若干問題に対して答えを言いすぎるキライはあるが、これも使い方に依る。さらにレビューを意識することでコードの健康まで得られてしまう。良いことしかない。 CodeRabbitの価格体系 気になっていたのはやっぱり価格だが、調べてみたらオープンソースであれば無料！だった。また有料も以前はOpenAPIのトークン使用量が別途かかっていたようだが、
はじめに Gitのステージングエリアにあるファイルを対象に、レビュー結果をSlackに通知するアプリケーションを作成しました。 開発環境のターミナルで指定したコマンドを実行するだけで、Slackにレビュー結果が送信されます。 ソースコードは以下です。 こんな人におすすめ コードレビューを受ける前に自分で事前チェックをしたい方 一人でコードを書くことが多く、レビュワーがいない方 どうせなら楽しくレビューしてもらいたい、好きなキャラクターにレビューしてもらいたい方 アプリケーションの構成 レビュー依頼の手順と流れ 以下のような手順と流れでレビュー結果を得ることができます。 レビュー対象のファイルをステージングエリアに登録する（複数ファイルの登録が可能です） ローカルのターミナルでaireviewコマンドを実行 Slackに必要な情報が送信される レビュー結果を確認する スレッドにレビュー結果が
認知負荷および認知負荷理論 (Cognitive Load Theory) をもう少し正確に理解するための心理学研究・知見の紹介
認知負荷および認知負荷理論 (Cognitive Load Theory) をもう少し正確に理解するための心理学研究・知見の紹介 この記事の目的 ここ数年で、ソフトウェア開発やプログラミングの文脈で、「認知負荷」 および 「認知負荷理論」 という用語をよく見聞きするようになりました。私が今思い出せるだけでも、以下のような書籍や Podcast で重要なキーワードとして取り上げられています。 A Philosophy of Software Design, 2nd Edition チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ fukabori.fm 102. A Philosophy of Software Design (3/3) w/ twada この「認知負荷」ですが、少なくとも近年見聞
どんな人向けの記事？ レビューによって心理的なダメージを受けやすい方 非エンジニアだが、エンジニアチームがどんな機能を作っているか知りたい方 業務が溜まっていて、レビューに割く時間を捻出するのに苦労している方 コピペできるコードも公開します 初回レビューをAIに任せると、いろんなロールの人の役に立つ レビューは得意ですか？ 優秀なエンジニアしかいないチームであれば、PRは1トピックに絞って小さく明確なコミットによって作成され、適切な要約とともに提供されることでしょう。 しかし、実際にはいろいろな制約から、PRが想定よりずっと大きくなってしまったり、関連トピックと異なるコードが混じってしまうこともあります。 実際のところ、大きなPRを適切にレビューするのは難しいことです。また、自分が詳しくない領域のレビューを行わなければいけない機会もあります。 今回の記事は、レビューを作成してくれるAI C
dmm.go #6 の登壇資料です。 https://dmm.connpass.com/event/295065/
はじめに こんにちは、minne事業部でwebアプリケーションエンジニアをしているkazuです。今回の記事は、コミットメッセージを書く時に、自分がこれまで愛用してきたgitmojiをやめた話をします。 そもそもminneの開発チームにおけるコミットメッセージのルール minneの開発チームでは、コミットメッセージのルールは特にありません。 私がペパボに入社した当初、「逆か」というコミットメッセージもあったりなどして、意外とみんなカジュアルにコミットメッセージを書いているなと思っていました。なるべく実際に開発をする中でのプロセスをありのままに残していきたいという思いがあるのかなと思っています。 gitmojiとは 特にコミットメッセージのルールがないということで、これまで自分が個人開発などでは使ってきたgitmojiをminneの開発チーム内でも使っていました。 gitmojiとは、gitの
Supercharge your entire team with AI-driven contextual feedback & smart chat
チームでのアジャイル開発において、コードレビューは最も重要な工程の1つです。『アジャイルプラクティスガイドブック』（翔泳社）では、その目的が「ソースコードを書いた人の持ち物から、チームの共同所有物にする」ことだとされていますが、メンバーの考え方が違ったり責任の所在が曖昧になったりと、トラブルの種となることも少なくありません。今回は本書から、コードレビューで建設的なコミュニケーションを行うための心構えを紹介します。 本記事は『アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知』（著者：常松祐一、監修：川口恭伸／松元健）の「第2章 「実装」で活用できるプラクティス」から一部を抜粋したものです。掲載にあたって編集しています。 コードレビューの目的 【プラクティス】ソースコードの共同所有 筆者はコードレビューの一番の目的を「ソースコードを書いた人の持ち物から、チームの共同
はじめに こんにちは、まつけんです。 早いもので、Webエンジニアになって、10ヶ月経とうとしています。 先月末、僕の職場に参画していたフリーランス歴20年の強強エンジニアCさんが卒業されました。（以降Cさんと称します） Cさんには、いつも迅速かつ丁寧なレビューをしていただいてました。 たまに補助で僕のプルリクにコミットを積んでもらうことなどもあり、お世話になった記憶が大半です。 今回はそんなCさんから受けたコードレビューから、今後どう改善していくのかアウトプットして学びを深めたいため、こちらの記事を書きました。 ペアプロしている時の参考になったこともおまけで書いてます。 ※こちらの記事に出てくるコードに関しては全てRubyです。実務で学んだことなので、出てくるコードは全てフィクションです。(実際のサービスのコードではないです) レビュー1: migrationファイルを追加する時「db:
私は長年 Pull Request のコメント数が多くて何回もレビューを往復することが多くて大変つらかったが最近ものすごく単純なコツに最近きづいたのでそのことをシェアしようと思う。 Pull Requestレビューの悩みこれはならない人はならないので、共感してもらえる人は少ないかもしれないが自分の悩みは Pull Requestのコメント数でこれが本当に多い。何がつらいって、レビューのコメントが多いという事は、マージに時間が掛かるということだ。最初にコードを書いてテストして完成させるのは２時間もかかってないのに大抵レビューで何往復もして時間を取られるのが本当につらいし、進捗がでないもの嫌だし、時間かかるし、自分が最近解決したい問題の中でも筆頭の問題だった。 何が悪いのだろう？すごく嫌なので物凄く考えたがうまくいかなかった。例えば、英語のスペルミスも良くしたし、ログやコメントの英文にレビュー
コドレビューの観点 コドレビューの観点をまとめてみました。チェックリスト的なものになりますた。 機能性 コードが設計通りの機能を有するか？ データの流れ、取得方法は、設計と一致するか？ データのチェックの漏れはないか？ データの生成、修正、加工は、設計と矛盾がないか？ ループの中で更にSQLなど重い処理を発行するなど、パフォーマンスの懸念はないか？ 必要な場合、国際化の対応しているか？ コネクションやリソースは適切な方法で閉じられているか？ NULLとなる場合や値が取れない場合を考慮しているか？ NULLをある程度許容したコードになっているか？ 読みやすさ 名前の付け方は、共通認識の範囲か？ スタイルガイドにそっているか？ ループ、分岐等の処理記述方法は同じか？ コード設計 パラメータ、プロパティなど正しく機能区別されて実装されているか？ インスタンス等の上書き、重複など考慮されているか？
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
コードレビュー時のコメントの意図を明確にする
コードレビューあるあるなんですけど、レビューする時に「これってなんでこうしてるんですか？」みたいなピュアなコメントを書いてしまうと、その意図がレビュイーに伝わらなくて、「詰められてる」「コードに疑念を持たれている」「修正依頼をされている」「純粋に質問されている」という解釈のブレを生んでしまって物事が円滑にいかないみたいなことは発生します。 コメントする側からするとただ単に質問しているだけなのにどうして・・・と思いがちなのですが、コードレビューに慣れていない人はこういう重要度や意図がはっきりしないコメントをたくさん書いてレビュイーを困惑させがちというのはあるんじゃないでしょうか。 重要度や意図がはっきりしないコメントを書くのが常になってしまうと、GitHubでPRを出してレビューをしてもらってマージするという開発者が何度も何度も回していくワークフローに滞りが発生してしまう、もしくはそれどころ
コードレビューの「純粋に質問ですが」は「勝手に指摘だと受けとってよくわからん修正するんだろ？質問なんだよ！修正すんなよ！」という意思表示な説
やきにくのすえなみ @a_suenami コードレビューの「純粋に質問ですが」は表現を柔らかさ目的でなく、「お前は質問だって言わないと勝手に指摘だと受けとってよくわからん修正するんだろ？質問なんだよ！！修正すんなよ！」という意思表示で、むしろ元より殺伐となってる可能性すらあります。 2023-02-13 16:43:45
コードレビューコメントは純粋な質問でも詰問してるように聞こえたり嫌味を言ってるように聞こえたりするのでテキストコミュニケーションは難しい
Junichi Ito (伊藤淳一) @jnchito 「なぜここで1を加算してるんでしょうか？」 とか、 「シャドーイングってご存じですか？」 みたいなコードレビューコメントって、純粋な質問であっても受け取り方によっては詰問してるように聞こえたり、嫌味を言ってるように聞こえたりするので、テキストコミュニケーションって難しい。 2021-08-04 09:56:39 Junichi Ito (伊藤淳一) @jnchito コードレビューにおいて疑問文が詰問に聞こえちゃうパターンなので「純粋に質問」を冒頭に付けてみた。 「なんでtrueにしたんですか？」が「普通はやらないでしょ！💢」に聞こえてしまう日本語の難しさよ……。 pic.twitter.com/3hDi6sV6FP twitter.com/jnchito/status… 2023-02-13 11:14:48
DMMプラットフォームでプルリクエストのマージ時間を250時間から50時間に減らした話 / Developers Summit 2023
Developers Summit 2023 https://event.shoeisha.jp/devsumi/20230209/session/4187/
あなたの遅延はどこから？ SQLから！ 〜患部に止まってすぐ効くSQLレビューチェックリスト 年初め特大サービス号〜 - ANDPAD Tech Blog
あけましておめでとうございます！ 今年は異世界放浪メシのアニメが放送されるらしいので楽しみなバックエンドの原田 (tomtwinkle)です。 内部で運用しているSQLレビューチェックリストの一部を抽出し思いつきで追記して行った結果、結構な分量になってしまいました。 暇な時でも流し読みして頂けるとありがたいです。 Motivation SQLレビュー観点 大きくSQLが変更される修正の際にはEXPLAINをレビュー内容に加える 検索のキーにINDEXを使用しているか SQL発行回数がN+1(1+N)の構造になっていないか サブクエリを利用したSQLはパフォーマンス要チェック Viewの利用は基本的に禁止 CROSS JOINは禁止 WHERE句で十分に絞った検索をしているか 必要なcolumnだけSELECTしているか レコード数だけ必要な場合にCOUNT用のSQLを発行しているか 集計関
はじめに こんにちは。 プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow のエンジニアの藤井です。 エンジニアであれば誰しも日頃からコードレビューをしたり、されたりしていることと思います。 健全な開発組織を育む意味でもレビューの文化を根付かせることはとても大切ですが、小規模な組織の場合「レビューアが足りない」という問題が往々にして起こり得ます。 もちろん、特定のエンジニアにコードレビューが集中してしまうのを防ぐために、チーム全体で負荷分散を図るのが本質的かつ王道的なアプローチではあります。 しかしときには、とにかく個人の力で乗り越える、という状況も避けられないでしょう。 そこで今回はコードレビューの生産性を上げるための Tips をいくつかご紹介します。 自分でも開発をしなければならないが、その片手間で一日に何本ものプルリクエストを確認しなけ
みなさん、新機能は好きですか。ソフトウェアへの機能追加は、ユーザ目線で単純に考えると「できることが増えていくのでよい」という響きを帯びています。しかし実際は、長く使われるソフトウェアであればあるほど、新機能を追加すべきかどうかはものすごく気を使って決めるものであって、やればいいというものではないのです。この記事の目的は、新機能の追加には細心の注意が必要だとわかってもらうことです。おもな対象読者はソフトウェアを長期間メンテしたことがないかたがたです。 みなさんが使っているOSSに新機能を追加するPRを送った場合を考えてみましょう。ここで重要なのは、PRが送られてきたメンテナやコミッタといわれるコア開発者たちの立場になって考えることです。彼らの役割は、自分たちを含むユーザがそのソフトウェアを使い続けられるようにメンテし続けることです。このメンテのコストに注目すると、機能追加は基本的にコストを上
GitHub Next | AI for Pull Requests GitHub Next Project: AI for Pull Requests wants to make GitHub Pull Requests seamless, low burden an... この機能の登場により、PR でのレビューのオーバヘッドを少なくすることが期待されます。この PR では何を変更したのかを説明したり、更には review の依頼を投げることもできます。 また、Issue でも AI にどうしたらよいか？を聞くこともできるそうです。詳しくは公式の動画を見てください。 How many times have you submitted a change and forgot to update the unit tests? Or the documentation? Or introd
こんにちは、サーバーサイドエンジニア の 橋本 です。 この記事は Enigmo Advent Calendar 2022 の 14 日目の記事です。 はじめに エンジニアとして仕事をしているとコードを読むことが多いと思います。例えば、仕様調査、CSからのお問合せ対応、レビュー対応などがあると思います。 今年を振り返るとコードを書く以上に読むことが多く、コードをより正確かつ速く読むにはどうすればいいかを考えることが多くありました。 ということで、この記事では私個人がコードを読む時に意識していることを紹介していこうと思います。 いきなりコードは読まない 1つ目はいきなりコードは読まないことです。業務で使われているコードの量は1つの機能でもとても多いです。いきなり読み始めるととても時間がかかったり、迷子になってしまうかもしれません。なのでまずはシステム全体を把握してインプットとアウトプットが何
この記事はNuco Advent Calendar 2022の13日目の記事です はじめに 私は情報系の学部に通う大学４年生です。大学でプログラミングを学んだことをきっかけに、プログラミングを使用した実際の業務に取り組んでみたいと思いました。そして、株式会社Nucoさんで機会をいただき、現在インターン生として実務に参加させていただいています。 自分のように、プログラミングを学び、「実務の経験が積みたい」「インターンに参加してみたい」という方はたくさんいらっしゃるかと思います。この記事では自分が実際にインターン生として実務に参加し、コードレビューで指摘されたポイントを紹介します。 難易度、頻出度の目安を★の数で示しています。 ・難易度・・・それぞれの項目で指摘されないようなコードを書く難しさ。 ・頻出度・・・それぞれの項目のミスの起きやすさ。 難易度(低→高)、頻出度(高→低)の順番で紹介し
現代においてはソフトウェアの開発はチーム開発となることが多い。 つまりコミュニケーションが大切になる。 ソフトウェアエンジニアの各人はコミュニケーションについても意識的に気を付けていたり、場合によってはそれについて学んでいたりする人もいると思う。 しかしながらプルリクエストでのやり取りにおいては端的で目的だけを優先したコミュニケーションをする人が多い気がする。 たしかに間違っているところや、読みにくいところを修正して、バグの発生防いだり、メンテナンス性の確保、ひいては将来的に開発速度を保つための手段なのでそれでも間違っていないのかもしれない。 具体的にはレビュワーとしてはたんたんと指摘だけをしたり、問題なかったら無言で Approve だけしたり。 レビューとしても何の説明もなくコードだけぶん投げたり、コメントに特に返信せずに修正だけを入れる、そして無言でマージしたり。 ソフトウェアの健全
前職でフロントエンドチームのスペシャリストとして開発プロセスを考えるポジションにいた。そのときに試してみて良かったなと思えたのはAutoApproveという仕組みで、これは任意のPRにAutoApproveというラベルが付くとGithub Actions経由でPRがGithub BotにApproveされコードレビューなしでマージできるというもの。 コードレビューでは、プロダクトの規模が大きくなっていくにつれ認知的・時間的なコストが嵩む。レビュワーも広汎なドメインや設計レベルの知識が求められたり、人が増えると「これレビューする意味ある？」みたいなPRもレビュワーにバンバン飛んでくる。そうなると、全体的にさらっと見てApproveしたりする。これはもちろんレビューをされる側もそうで、コードレビューという仕組みがあるとなんとなくレビューをゲートキーピング的に捉えてしまいがちなところがある。 な
この記事は、開発生産性 Advent Calendar 2022の3日目の記事です。 2日目の記事はnaoto_pqさんの「PR数は開発生産性のセンターピンかもしれない」でした。PR数を増やすことにフォーカスすることで、Four Keysの向上やベロシティが安定したという学びが深い記事でした。 私は開発の生産性向上施策の１つとして、コードレビュープロセスの負荷や時間を減らすために取り組んでいる10のTipsを紹介します。 ぜひ、面白いなと思ったTipsがあれば、トライしてもらい、コードレビューの効果や効率を高めていただければ嬉しいです。 Tipsを紹介する前に コードレビューは、開発プロセスの早い段階で欠陥を発見できる有効な開発プラクティスとして多くの開発チームで実施されています。 しかし、プルリクのレビュー依頼をしてからレビューが返ってくるまで1日以上かかったり、その後、レビューの対応か
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レビュアーとして早く成長する3つの方法 停滞を打ち破り、効率良く成長している実感を得るためのヒント
Github プルリクエストにAIレビューを導入してみた - Qiita
Bluesky、AT Protocol開発助成金を発表――招待制廃止、連合機能の実装に続き、オープンな開発エコシステムによる成長がさらに加速 | gihyo.jp
コードレビューが怖かった私の、レビューへの向き合い方が変わった話
チームで1年間コードレビューを最優先に実施したら開発生産性に良い影響を与えてくれたかも
トーバルズ氏、Linux開発の現状や生成AIについて語る
プログラミングの原則：enumの比較はすべてバグ - Uzabase for Engineers
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
もう初回コードレビューはずんだもんに任せる時代になった
もう初回コードレビューはAIに任せる時代になった - CodeRabbit -
組織のコード品質を向上させる “レビューシステム”の取り組み
コミットメッセージを書く時にgitmojiを使うのをやめた話 - Pepabo Tech Portal
AI Code Reviews | CodeRabbit | Try for Free
アジャイル開発のコードレビューで、建設的なコミュニケーションを行うための心構え
フリーランス歴20年の強強エンジニアからのガチコードレビュー集 - Qiita
Pull Request のコメント数を減らすアホみたいなコツ｜牛尾 剛
コードレビューするときの観点 - Qiita
コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
コードレビューの生産性を上げるためのTips | Offers Tech Blog
機能は追加すればいいというものではない
コードレビューをAIに手伝ってもらい楽をしてみる - hiroppy's site
コードを読む時に意識していること - エニグモ開発者ブログ
知らないと恥ずかしいコードレビューで指摘されがちなポイント14選 - Qiita
コミュニケーションとしてのプルリクエストレビュー - ちなみに
コードレビューとオーナーシップ、できる限りコードレビューをしない - Runner in the High
コードレビュープロセスの負荷や時間を減らすために取り組んでいる10のTips - Qiita