コードレビューでよくお願いする、コメントの追加のパターン7選
同僚が書いた Go初学者へのコードレビューでよくあったコメント20選 では、Go初学者へのコードレビューでよくあったコメント20選を紹介しました。 今回は私が コードレビューでよくお願いするコメント追加のお願い について紹介します。 前提：コメントを書いて欲しいわけ コードレビューでコメントを書いて欲しい理由は以下の通りです。 プロダクト、サービスの持続可能な開発を支えるため 人が入れ替わっても開発の迷いを可能な限り減らすため 具体的なコメントの追加パターン ①変数やパラメーターの説明を書く コードを書く人にとっては必要があって構造体や変数を定義しているので自明ですが、第三者からすると解釈に悩むことがあります。 そのため誰が見ても自明でしょうという変数以外については注釈をいれます。 たとえば、User 構造体における ID は自明（どのような採番ルールか？みたいな疑問は出るが、ID を入力
Go初学者へのコードレビューでよくあったコメント20選
はじめに こんにちは、ソーシャルベッティング事業本部 海外ベッティング事業部の山崎です。 本記事では、Effective GoやGoogle のスタイルガイド、Code Review Commentsといった公式資料、Future Architectの記事などを参考に、Go を初めて触る開発者を対象にした汎用的なレビューコメントの 20 選を紹介します。 大きく以下の４つのセクションに分けました 言語仕様に関わる内容 標準パッケージの使い方 エラーの扱い方 単体テスト Linter の活用について 可能な限り lint で自動化して人の手が加わる前に静的解析でできればベターです。 特にこの記事で紹介するような汎用的なコメントについてはいくつか反映できる lint もあると認知しております。 そのような設定の lint config サンプルをまとめようとも思いましたが、実際に運用まで至って
消耗せずに「良いコード」とはなにかを考える
次の記事が最近公開されたので、読んでみました。 結論としては、例えば同著者の「良いコード／悪いコードで学ぶ設計入門」という書籍と比較すると、だいぶ受け入れやすい主張になっていると感じました。（以前の書籍についてのコメント記事へのリンク） ところで、私は「良いコード」についての議論や指摘や検討を積極的にやったほうがよいと思っていますが、主に「消耗しない」という観点でこの記事についていくつかの構造理解やテクニックの部分で補足できそうだったので、以下補足していきます。 ざっくりとした主張でいうと、 トレードオフに見える部分は学習・教育で解決できるケースも多くある 品質特性への還元が難しいがコードの良し悪しを定める概念がある Webアプリにおいても再利用性は必要だし、モバイルアプリでも再利用性を求めて失敗することがある 再利用性というよりは、現実に即した概念の線をどこで引くかのバランスを大事にする
プログラミングの原則：構造化テキストを文字列結合で作らない、置換でいじらない - Uzabase for Engineers
こんにちは、ソーシャル経済メディア「NewsPicks」のむとうです。 先日から『Ghost of Tsushima』の開発者が書いた『ルールズ・オブ・プログラミング』という本をちょっとずつ読み進めていて、プログラミング熱が高まっています。この本は大きな指針を示すだけで具体の話をするものではないのですが、読み物として面白いので私も似たようなことをやってみたくなりました。 何年もこういう仕事をしているとバグが入るパターンというのが見えてきます。そしてだいたいどこに行っても何の仕事でも似たようなことをすることになるのですが、今回の話もその一つです。 構造化テキストを文字列結合で作らない、置換でいじらないというのはこれだけみると何のことか分かりづらいかも知れませんがSaaS Product Team セキュアコーディングの啓蒙 第2回 （SQL インジェクション編）の内容とある面では同じ話です。
プログラミングの原則：enumの比較はすべてバグ - Uzabase for Engineers
こんにちは、ソーシャル経済メディア「NewsPicks」のむとうです。 この記事は NewsPicks アドベントカレンダー 2023 の3日目の記事です。 昨日は@J_Nakagawa(隼佑 中川)さんによる『LambdaレスポンスストリーミングとAWS-SDKを使ってSlackに進捗バーを表示させる』でした！ 世の中には再現が難しく一見してバグがありそうに思えないコードもありますが、一方でプロダクションコードの中にはひと目見てバグが有りそうなコードもまた多いものです。いくつかの特定のパターンをとる文字列(環境名など)やenum(以下どちらもenumと表現します)に関する条件分岐もその一つです。プルリクを見てこのようなパターンがあれば、バグの疑いが強くなります。周囲を見渡すと、大抵すでにバグっているか潜在バグを含むコードが見つかります。すべてバグというのは言い過ぎにせよ、わかりやすさと変
特に個人開発者向け！CodeRabbit(自動レビューツール)を使えばコードの健康まで得られることに気づいた話
特に個人開発者向け！CodeRabbit(自動レビューツール)を使えばコードの健康まで得られることに気づいた話 ↑by Image Creator from Microsoft Bing CodeRabbitのレビュー もう初回コードレビューはAIに任せる時代になった - CodeRabbit -を読んだ。レビューはとても負担が多く、時間もかかる。これをAIがやってくれたら、こんな有難いことはない。というわけですぐに使ってみた。 CodeRabbitを使った結論 結論から書くと、レスポンスも速く、技術レベルも高く、気を使う必要もない上に、コミュニケーションも出来る。若干問題に対して答えを言いすぎるキライはあるが、これも使い方に依る。さらにレビューを意識することでコードの健康まで得られてしまう。良いことしかない。 CodeRabbitの価格体系 気になっていたのはやっぱり価格だが、調べてみた
コミットメッセージを書く時にgitmojiを使うのをやめた話 - Pepabo Tech Portal
はじめに こんにちは、minne事業部でwebアプリケーションエンジニアをしているkazuです。今回の記事は、コミットメッセージを書く時に、自分がこれまで愛用してきたgitmojiをやめた話をします。 そもそもminneの開発チームにおけるコミットメッセージのルール minneの開発チームでは、コミットメッセージのルールは特にありません。 私がペパボに入社した当初、「逆か」というコミットメッセージもあったりなどして、意外とみんなカジュアルにコミットメッセージを書いているなと思っていました。なるべく実際に開発をする中でのプロセスをありのままに残していきたいという思いがあるのかなと思っています。 gitmojiとは 特にコミットメッセージのルールがないということで、これまで自分が個人開発などでは使ってきたgitmojiをminneの開発チーム内でも使っていました。 gitmojiとは、gitの
コードレビューをAIに手伝ってもらい楽をしてみる - 技術探し
GitHub Next GitHub Next investigates the future of software development この機能の登場により、PR でのレビューのオーバヘッドを少なくすることが期待されます。この PR では何を変更したのかを説明したり、更には review の依頼を投げることもできます。 また、Issue でも AI にどうしたらよいか？を聞くこともできるそうです。詳しくは公式の動画を見てください。 How many times have you submitted a change and forgot to update the unit tests? Or the documentation? Or introduced linter errors. Perhaps we can fix that for you….watch this spa
設計/コードレビューで"常に"心がけるポイント - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
同僚のコードレビューでこんなにクラスの設計が良くなったという話 - Qiita
弊社では、案件とは関係のないプロジェクトでも業務時間中にみんなにコードレビューを依頼できる時間が確保されています(参加は任意)。案件のコードレビューを依頼したり、ちょっとした個人の制作物を見てらったりと使い方は色々です。 先日、TypeScriptの練習にQiitaのAPIを叩いていて記事を表示するブログウィジェットを作成しました。このウィジェットのレビューを依頼したところ、クラスの設計について具体的な指摘と、それに対する改善を経験できたのでこの記事に記載します。 今回作ったQiitaWidgetの要件 Qiitaの公式APIV2から記事とユーザー情報を取得し、HTMLテンプレートに表示する 投稿の合計いいね数を算出するために、あるユーザーの投稿を全件取得する (このために複数回リクエストの送信とレスポンスデータの結合を行う) パラメータによってユーザー、いいね数によるソート、表示件数、ラ
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
コードレビューに費やす時間を短くする - クックパッド開発者ブログ
はじめに こんにちは、広告事業部の芳賀（@func09）です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ１年になるのですが、初めはエンジニア以外の人（営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます）と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTGや相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。
コードレビューについて - (define -ayalog '())
普段お仕事している中で何故かコードレビューをしている時間がわりとあって、暇さえあれば(暇がなくても)コードレビューしている。 そんな中でどういうところを見たらいいのか、あるいは見るべきなのかというのが自分の中である程度蓄積された気がするので書いてみる。あと最後に普段考えていることを少し書いた。 前提 現在の僕の参加しているプロジェクトはこんな感じ Rails プロジェクト( AngularJS 使ったりしている) Git 使ってる( Pull Request ベースの開発で以下が merge 条件) 2 人以上に approve される テストが通ること(継続的インテグレーションの実施) 静的コード解析は導入している( Rubocop, jshint, pre-commit など ) テストのカバレッジは計測していない(月一くらいで測ってるらしいんだけど、だからどうっていう話はない) プ
コードレビューをする話を新卒研修で話しました。 - パルカワ2
今いる会社には、新卒研修で座学と呼ばれるものがあって、先輩エンジニアがある程度好き勝手に話したいことを1時間ほど話す時間があります。 そんな最高の学習環境である座学で、コードレビューについて話してきました。 テーマは、 https://github.com/kenchan/keynote-theme を使いました。 内容についての補足 iOSとか出来ないので、そのあたりの説明が出来ない 最近コードレビュー全くしてない 相手によってはLGTM画像が嫌いな場合がある TPOがあるよね コンテキストが違う人にいきなりはキビシイ 海外の人にアニメ画像は使わないほうがよさそう 英語だと横向きの顔文字とかよく見る ;P 美女LGTM画像は会社で使ったことない スライド作る時に気をつけたこと 6個のステップ、3つの目的とか個数を言うようにした。 新卒氏たちに今やるべき事を認識してもらう 新卒氏たちにも出
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Anthropology of Code Reviews - Adi Mor
【IMO】コードレビューって難しいよね.pdf
コードレビュー研修
http://post.simplie.jp/posts/34
コードレビューガイドライン #loupestudy
デキるプログラマだけが知っているコードレビュー7つの秘訣（DevLove版）
