この記事は 一休.com Advent Calendar 2024 7 日目の記事です。 宿泊事業本部 ユーザー向け開発チームの原です。 一休.com と Yahoo!トラベルの主にフロントエンドの開発を担当しています。 今回は、普段の開発でコードを書き始める前段階で Design Doc を作ることで、円滑な開発を進められるようになったというお話をします。 チーム構成について まず、前提を共有するために私達が普段どのような体制で開発しているかを説明します。 私が所属している宿泊事業本部 ユーザー向け開発チームは、一休.com と Yahoo!トラベルの主に toC のユーザー向けの機能開発をしています。ユーザー向け開発チームのメインのミッションはユーザー体験を向上させることであり、そういった施策の機能開発を素早くリリースできることを大事にしています。 一方、プロダクト開発においては機能開
コードレビューする時、自分がどんなことに気を付けているか (本当は気をつけたいか)みたいなポイントをまとめてみた。 コードレビューの目的 プロダクトの品質を担保するため 人は基本的にミスをするもの 1人で考えたものより、2人、3人集まって考えたものの方が良いことが多い 知識をチーム内でシェアするため チームでコードに関する知識を常に共有し続けることで、「この機能はAさんしか知らない」といった属人化問題を防ぐ Aさんが有休取った時に限って障害が起きたりするんですよね。分かります 他の人が書いたコードを読み、さらに分からないことは質問できる、素晴らしい学びの場だと捉える 責任をチーム内でシェアするため 何か問題が起きた時に関連するコードを書いた人間だけが責められるようなことは決してあってはならない レビュー時 (又はそのコードがデプロイされるまで)に問題に気づけなかったチーム全体の責任なので、
こんにちは。コミュニケーションアプリ「LINE」のモバイルクライアントを開発している石川です。 この記事は、毎週木曜の定期連載 "Weekly Report" 共有の第 51 回です。 LINEヤフー社内には、高い開発生産性を維持するための Review Committee という活動があります。ここで集まった知見を、Weekly Report と称して毎週社内に共有しており、その一部を本ブログ上でも公開しています。（Weekly Report の詳細については、過去の記事一覧を参照してください） 確信的な質問 ある開発者が、以下の関数 getOnlineUserStates のコードレビューの依頼を受けた状況を想定しましょう。 fun getOnlineUserStates(userIds: Set<UserId>): Map<UserId, UserState> { if (userI
同僚が書いた Go初学者へのコードレビューでよくあったコメント20選 では、Go初学者へのコードレビューでよくあったコメント20選を紹介しました。 今回は私が コードレビューでよくお願いするコメント追加のお願い について紹介します。 前提：コメントを書いて欲しいわけ コードレビューでコメントを書いて欲しい理由は以下の通りです。 プロダクト、サービスの持続可能な開発を支えるため 人が入れ替わっても開発の迷いを可能な限り減らすため 具体的なコメントの追加パターン ①変数やパラメーターの説明を書く コードを書く人にとっては必要があって構造体や変数を定義しているので自明ですが、第三者からすると解釈に悩むことがあります。 そのため誰が見ても自明でしょうという変数以外については注釈をいれます。 たとえば、User 構造体における ID は自明（どのような採番ルールか？みたいな疑問は出るが、ID を入力
他人や自分など「ヒト」ではなく「コト」に向かうコードレビューについて考えてみる。 参考:「コトに向かう」について => DeNA南場智子さんの講演「ことに向かう力」がいい話だった｜narumi （本来の「コトに向かう」話とそれほど親和性のある話ではない気はしつつも、響きがいいので借用しています） このコードは良くないなと思ったとき 「ヒト」に向かうコードレビュー 「なんであなたはこんなコードを書いたの？」 原因の中心を個人のスキル不足に置く見方 わかっていないあなた vs わかっている私たち の構図になる 「コト」に向かうコードレビュー 「なんでわれわれのコードベースはこんなコードが書けてしまうんだ？」 原因の中心を環境（コードベース）のサポート不足に置く見方 問題 vs 私たち の構図になる コードレビューが「ヒト」に向かわないためにレビュイーができること 全力を尽くす コードレビューは
ソフトウェアエンジニアの 渋谷 です。 コードレビューを実際のプロジェクトでどのように活用しているかを紹介します。 今回は私が入社当初からお世話になっているプロジェクトマネージャー（PM）2名に協力いただき、特徴的なプロジェクトについてインタビューしました。 コードレビューの目的、方法などについては多くの記事で紹介されているため、この記事では省略いたします。 コードレビューについて知りたい方は私が参考にしている代表的な記事を2つ紹介するので、そちらを見てください。 第2章 3.ソースコードレビュー | アーカイブ | IPA 独立行政法人 情報処理推進機構 Google Engineering Practices Documentation 斉藤 さんからは2つのプロジェクトを紹介します。 WebAPI、Webクライアント保守プロジェクト(人数: 2人) モバイルアプリリニューアルプロジェ
コードレビュー開発者ガイド はじめに コードレビューとは、コードの作成者以外の人がコードを調べるプロセスです。 Google ではコードとプロダクトの品質を維持するためにコードレビューを実施しています。 このドキュメントは Google のコードレビューのプロセスとポリシーに関する正規の解説です。 このページでは私達のコードレビュープロセスを概観します。このガイドはさらに二つのドキュメントに分けられます。 コードレビューの仕方: コードレビュアーのための詳細なガイド CL 作成者のガイド: CL をレビューしてもらう開発者のための詳細なガイド コードレビュアーはどんな観点でレビューすべきか？ コードレビューは次の観点で見るべきです。 設計: コードはうまく設計され、そのシステムにとって適切か？ 機能性: コードは作成者の意図通りに動作するか？ユーザーにとってコードの挙動は適切か？ 複雑さ:
こちらはAI・機械学習チームブログリレー8日目の記事です。前回のブログは高田さんの「AI・機械学習チームで学んだ開発技法で趣味の通知系ツールを量産した」でした！ www.m3tech.blog エムスリーエンジニアリンググループ AI・機械学習チームでソフトウェアエンジニアをしている中村(po3rin) です。 「レビュー依頼の優先度」といえば自分の作業とレビューのどちらを優先するかという意味での「優先度」の印象ですが、今回は複数あるレビュー依頼の中で、どのレビューから見ていくかという意味での「優先度」の話をします。 レビューの優先度を考えていく中で、「これは自動化したら面白いのではないか」と思い立ち、レビューの優先度をスコアリングするツールを作ったので、その経緯を簡単に紹介していきます。 レビューの優先度の再考 先に見るべきレビュー依頼の観点 急ぎ系のマージリクエスト メンションされてか
はじめに 今回は、コードレビュー観点表を作った話について少し書かせていただきます。 社内ではGitHubを用いてコードレビューを行っていて、バックエンドの開発においては、コーディングガイドラインも策定しています。 しかし開発において、ガイドラインに書かれている事項が全てではないため、コードレビューを行う際のポイントが自分の中で綺麗に整理しきれていませんでした。 また、ガイドラインの重要なポイントを十分に把握できず、効果的なコードレビューができていない現状がありました。これを改善するために、コードレビューの観点表を作成したことで、コードレビューの質が上がった話についてお話ししようと思います。 問題となっていたこと 一貫性がないレビュー 毎回レビューを行う際に、自分の中のレビューポイントが明確に決まっていなかったため、的確にレビューができていないこと レビューにかかる時間が長い 自分の中でのレ
こんにちは。 LayerX バクラク事業部 バクラクビジネスカード開発チームEMの 高江（@shnjtk）です。 今回の記事では、先日開催された開発生産性Conference 2024にて私の登壇の中でご紹介したコードレビューガイドラインについて、登壇の中ではご紹介しきれなかった部分も含めてより詳しくご紹介いたします。 開発生産性Conference 2024 コードレビューガイドライン 策定の経緯 ガイドラインの内容 ガイドライン策定の目的 ガイドラインの位置付け コードレビューの目的 コードレビューの観点 レビュアーに期待すること レビュイーに期待すること レビュアーに期待しないこと セルフマージを許容するケース 策定の効果 おわりに 開発生産性Conference 2024 2024年6月28日〜29日に開催された、ファインディ株式会社様主催の開発生産性Conference 2024
■ 付記 注意点として、高い成熟度を目指すことが必ずしも望ましいとは限らない。 高い成熟度を目指すには、以下が必要になると思われる； lint といった静的解析をするツールや、テストを実行するツール リポジトリに関するドキュメントや、それを保守するフロー PR を作成するレビュイの／PR を読むレビュワの時間・体力 低い成熟度のレビューでも構わないのならば、PR を作成する／読む時間・体力は、比較的小さいものになるであろう PR を適度な粒度で作成することは、レビューの成熟度の高さに寄与するであろう（この詳説は次の節に譲る） PR を適度な粒度で作成しないと、チームとして目指せる現実的なレビューの成熟度の限界は 3, よくて 4 程度であるように感じる 詳細な要求仕様と、それを管理するためのツール これはトレードオフとも解釈でき、チームとしてレビューにどこまでを求めるかという判断でもある。
何故 Pull Request(以下、PR) を分割するのか？ レビュアーを疲弊させないため 自分が疲弊しないため レビューの精度/速度を上げるため PRを分割しないと、何が起きるのか 時折、それなりに規模の大きな機能を実装する必要がでてきたり、当初はそこまででもないと思っていたが、いざ実装し始めてみたら色々必要になり、結果大規模な作業内容になった、というケースが出てくる。 そうした状況で、諸々の作業内容をまとめて一つのPRとして作成すると、一旦どんな問題が起こるか。 以下、レビュアー/レビュイーの視点からまとめてみる。 レビュアーの視点から 1. 追加/変更ファイル数が多い 単純に圧倒される ファイル変更に伴う依存関係のチェックが大変 どこからどこまで変更が入ったのか、影響範囲がどの程度か、把握が大変 2. diffの量が数百行有って辛い 単純に死ぬほど見づらい diffが多いと目が滑る
この記事はスターフェスティバル Advent Calendar 2023 9 日目の記事です。 qiita.com 最近社内で可読性について会話をするタイミングがあり、可読性について思っていることを言語化してみるか〜と思ったので書いてみます。 可読性って難しいしよくわからないよね〜 この記事では、可読性という単語をコードの把握しやすさといった認知負荷的な意味だったり誤読しにくさみたいな意味で使っています。 メンタルモデルに起因するものなのか、そうではないのかを意識する メンタルモデル? メンタルモデルというものは「XXとはこういうもの」や「こうしたらこうなるはず」のような人それぞれが持つ思い込みみたいなものだと理解しています。 コードを読んで理解するときのメンタルモデルは、これまでのプログラミングに関する経験や知識、そのロジックが解こうとしている問題についての理解、自然言語自体の理解などの
雑感です。実力は同程度、または仕事が終わる人の方が能力値が低い状態を想定しています。 仕事が終わらない人の特徴 1回目のレビューが遅い。〆切ギリギリに出てくる。仕事がほとんど終わった後に初めて出てくる。 やり直しの幅が広いので直すのに時間がかかる。「何でそうするの？」の質問に答えられず詰められる。考えたときのことを忘れているので思い出さないといけない。 取り繕ったりすると矛盾が出て突っ込まれる。信頼度が下がってチェックが厳しくなる…。 という感じで悪循環が永遠に続く。 仕事が終わる人の特徴 次のタイミングでレビューを受ける。 取り掛かる前 進捗が1/3程度進んだとき 詰まって質問後、教えてもらった物を直したらすぐ 不安なところが出てきたとき。15分程度で考えをまとめてから とにかくやることや意図をまとめてすぐ見せる。じっくり見てくれる相手がいなくても「見える状態には」する。 戻しや方針転換
自分はDMMプラットフォームのマイクロサービスアーキテクトチームというチームのテックリードをしているが、 このチームが "DMMプラットフォームの組織的な技術戦略を策定、実行する" という目的を持っているということもあり、 普段の業務でDMMプラットフォーム内の各チームとやりとりすることが多い。 その中でも "成果物のレビュー" が自分の作業時間を圧迫し始めたので、同期レビューを導入した。 レビュー対象の成果物は? レビュー多すぎ問題 同期レビューとは? 同期レビューのメリデメ メリット デメリット そもそも守備範囲が広いのが問題 宣伝 レビュー対象の成果物は? 現在は主に以下をレビューしている。 DMMプラットフォーム内の Product Requirements Document(PRD), Design Doc 自チームの成果物 他チームのGoのコード PRD, Design Doc
前書き みなさま、プログラミングを楽しんでますか？ 私は1994年にプログラマーとして就職して以来、ずっと飽きることなくプログラミングを楽しんでいます。 今やアラフィフですが、iOSアプリ開発者として毎日バリバリコードを書いています。 …が、まだコードレビューで情けないケアレスミスの指摘をいただくことがあります。 本来コードレビューで議論すべき観点1に集中するために、コードレビューを依頼する前にケアレスミスがないかセルフチェックすることは大事ですよね。 ということで、自戒の念を込めて 「コードレビュー依頼前にケアレスミスを見つけるためのセルフチェックリスト」 を作成してみました。 「仕様に則していること」とか「規約に則していること」とかは自明なので割愛しています。 もし「こういうポイントもセルフチェックすべき」という項目がありましたらコメント等で教えていただけると幸いです。 チェックリスト
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
＼スニダンを開発しているSODA inc.の Advent Calendar 10日目の記事です!!!／ こんにちは！！！！SODA開発部の矢野です！！！ はじめに 私のチームでは一年前からコードレビューを最優先に実施するという取り組みをしています。この取り組みを継続した結果開発生産性にも良い影響を与えてくれたかもしれないので記事にしようと思います！ ちょうどこの記事を作成しているときにX(旧Twitter)で「PRのレビューを最優先にしたらチームの生産性が上がった」の投稿にたくさんのいいねがついていたので、コードレビューを最優先に取り組んで効果を実感している組織やチームが多いのかもしれないですね。 レビューを最優先にした結果 結果から書くと、 「コードレビューを最優先にする」取り組み前後の「レビューからアプルーブまでの平均時間」を比較すると6.5時間から2.5時間に縮まりました（本当かな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
