特に個人開発者向け！CodeRabbit(自動レビューツール)を使えばコードの健康まで得られることに気づいた話
↑by Image Creator from Microsoft Bing CodeRabbitのレビュー もう初回コードレビューはAIに任せる時代になった - CodeRabbit -を読んだ。レビューはとても負担が多く、時間もかかる。これをAIがやってくれたら、こんな有難いことはない。というわけですぐに使ってみた。 CodeRabbitを使った結論 結論から書くと、レスポンスも速く、技術レベルも高く、気を使う必要もない上に、コミュニケーションも出来る。若干問題に対して答えを言いすぎるキライはあるが、これも使い方に依る。さらにレビューを意識することでコードの健康まで得られてしまう。良いことしかない。 CodeRabbitの価格体系 気になっていたのはやっぱり価格だが、調べてみたらオープンソースであれば無料！だった。また有料も以前はOpenAPIのトークン使用量が別途かかっていたようだが、
週に一度まとめて更新のようなパターンだと、体調が悪いときなどにその週はスキップされ、また次の週も更新しようとして偶然タイミングが合わなかった場合などに、1ヶ月更新が止まるみたいな状態は起きやすいです。 1ヶ月更新を止めてしまうと、そこで更新する習慣が失われて、この書籍でいう逆戻りが起きるのかなと思っています。 そのため、JSer.infoではタスクを細分化して進められる時にやっていけるような形を作っています。 ライブラリのメンテナンスのリズムをツール化する JavaScript周りは顕著ですが、ライブラリが細かく分かれていることが多いため、リポジトリの数も多いです。 そのため、リポジトリのCI設定や依存ライブラリのアップデートなどをメンテナンスするだけで無限の時間がかかります。 このメンテナンス作業を手動で毎回やるととても疲れるので、自分の場合はツール化していることが多いです。 作ったり、
「気に入らないコード」をレビューする際にRed Hatのエンジニアはどうしているのか：10個のヒントとは？ プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合はどうしたらよいだろうか。Red Hatのソフトウェアエンジニアが、コードレビューを行うに当たって念頭に置くべき10のヒントを解説した。 Red Hatでソフトウェアエンジニアを務めるデビッド・ロイド氏は2019年7月8日（米国時間）、コードレビューを行うに当たって念頭に置くべき10のヒントを同社の開発者向け公式ブログで解説した。プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合に役立つ指針だ。コントリビューター側としても参考になる。 これらのヒントは、客観的で的を射たレビューを行い、プロジェクトとその参加者を前進させるという観点からまとめられている。 （1）
How to do a code review
How to do a code review The pages in this section contain recommendations on the best way to do code reviews, based on long experience. All together they represent one complete document, broken up into many separate sections. You don’t have to read them all, but many people have found it very helpful to themselves and their team to read the entire set. The Standard of Code Review What to Look For
1月末で約2年ほど働いたIndeedを退職して、UbieというAI×医療のベンチャーに転職します。せっかくの節目なので、社会人になってからを振り返りたいと思います。 目次 ・リクルートについて ・Indeedへの異動に向けて ・Indeedについて ・Ubieへの転職のきっかけ ・これから リクルートについてもともとは新卒でリクルートにデータサイエンティストとして入社して社会人生活を始めました。リクルートは様々なデータを保有しており、データ分析のしがいがありました。また、上司、同期、後輩は優秀な人ばかりで、常に学ぶことばかりでした。特に、データにどのように向き合って、仮説をたてて分析するのか、また、データの裏側にいる実際のユーザーやクライアントの課題を把握してどうしたら解決ができるのかといったスタンス面の土台がこの頃にできたように思います。技術面においても、GCPやAWSを使って機械学習プ
コードレビューの思想や心構え - Qiita
株式会社ブレインパッドでデータサイエンティストをしているasanoです。 この記事はBrainPad Advent Calender 2023 1日目の記事シリーズ2です。 ※シリーズ1は@fuyu_quantさんの入力プロンプトを復元する技術 #ChatGPTです！ 今日はコードレビューの思想や心構えについて書きます。 はじめに コードレビューをより生産的に進めるには単にコーディングのスキルだけでなく、そもそものコードレビューに対する思想や心構えについても一定のリテラシーを求められると考えています。 コードレビューはどうしてもロジカルな話になるため伝え方にも気を付けないとモチベーションの低下に繋がりやすいと考えています。 そうなると当然パフォーマンスも下がってしまいます。 これを防ぐために自分は「コードレビューの思想・心構え」をまとめてチームのガイドラインとして使っています。 あくまで主
はじめに こんにちは！Google Cloudでオブザーバビリティの担当をしているものです。CVE-2021-44228のおかげでバタバタしていますがみなさんはお元気ですか？ このエントリーはpyspa Advent Calendar 2021の15日目の記事です。昨日は @moriyoshit さんの「Goのロギングライブラリ 2021年冬」でした。めちゃめちゃ調べてあって良い記事でした。Goでログライブラリの選定をする際にはこちらをまず読むと良さそうです。 2021.12.21 追記: 穴が空いていたのでGo Advent Calendar 2021 その1の14日目の記事にもしました。 さて、今日は本当は「Goならわかる確定申告第三表」という記事を書こうと思ったのですが、まだ確定申告の時期ではないのでそれは辞めにします。そのかわり、今日はGo 1.18がめでたくベータ版リリースとなっ
English version is available here: https://blog.ryotak.net/post/homebrew-security-incident-en/ (公式インシデント報告はこちらから読むことができます: https://brew.sh/2021/04/21/security-incident-disclosure/) はじめにHomebrewプロジェクトはHackerOne上で脆弱性開示制度(Vulnerability Disclosure Program)を設けており、脆弱性の診断行為が許可されています。 本記事は、当該制度に参加し、Homebrewプロジェクトのスタッフから許可を得た上で実施した脆弱性診断行為について解説したものであり、無許可の脆弱性診断行為を推奨することを意図したものではありません。 Homebrewに脆弱性を発見した場合は、
データ分析者たちのコードレビュー #とは - 散らかったJupyter notebookを片付けるかどうするか問題を考える - JX通信社エンジニアブログ
JX通信社シニアエンジニアの@shinyorkeです. 最近はチームの朝会でよく着ているTシャツにツッコミを受けてます.*1 JX通信社では, いい感じにデータを整備・運用しているデータ基盤を駆使して, BI（Business Intelligence）文脈でのデータ分析・可視化. ダッシュボード作ったり. 機械学習的なアプローチを使ったR&Dと機能開発（分類タスクなど） といった業務・タスクを社員・インターン問わず行っています. データ分析でSQLを書いたり, 「新しいアルゴリズム試すやで！」的なノリでPythonのコードをゴリゴリ書く・動かして結果を見て振り返ってまた臨む...って楽しいですよね. チームの皆さんも, もちろん私もモチベーション高くやってるわけですが！？ あれ, notebookどこ行ったんや...🤔 よくありますよねー（震え） 自分もチームメイトも, 前のめりになっ
@koic です。 運用上の作業を開発者が行うというのは、昨今の DevOps ではよく見る光景だと思います。そして、運用手順の実施などにおいてダブルチェックというものを聞いたことあるでしょう。いや、むしろプロジェクトのルールで必要とされ、聞いたことがあるというレベルではないケースもあると思います。 そんなダブルチェック文化について、個人的には「ダブルチェックと聞いたらまず必要性を疑って判断する」という立ち位置で、本稿はそういった音楽性の人が書いた記事となります。 なお、一口に「ダブルチェック」といっても定義は広いため、「リアルタイムでの2人以上の指差し確認」を本稿でのダブルチェックの定義として位置付けます。 そもそも人間は間違えうるもの 本番環境へのショートサーキット 👿 Ops でも Dev のレビューフローにする 👼 形骸化したただの着席プロセスになっていないか疑う そもそも人間
こんにちは！エンジニアの @fortkle です。 あの伝説のゲーム「メダロット」のスマホゲームのリリース日がついに 2020年1月23日と発表がありました!*1 いまからワクワクしてきましたね！リリースしたらぜひロボトルしましょう！ さて、今回の記事は「コードレビュー」についてです。コネヒトに入社してから早4年、数百のPRをレビューしてきてだんだんと自分の中でコードレビューに対する接し方が定まってきました。今日は私がコードレビューで心がけていることについてご紹介できればと思います。 レビュワーとして ① "既存コード" の 歴史的経緯を素早く紐解く コードレビューは様々な目的で行われますが、「欠陥・バグを検出すること」「コードの改善」に期待をしていることが多いかと思います。 これらの目的を達成するためには、既存・変更後のコードの実装意図や背景を理解することがとても重要になります。特に長年
この記事は、開発生産性 Advent Calendar 2022の3日目の記事です。 2日目の記事はnaoto_pqさんの「PR数は開発生産性のセンターピンかもしれない」でした。PR数を増やすことにフォーカスすることで、Four Keysの向上やベロシティが安定したという学びが深い記事でした。 私は開発の生産性向上施策の１つとして、コードレビュープロセスの負荷や時間を減らすために取り組んでいる10のTipsを紹介します。 ぜひ、面白いなと思ったTipsがあれば、トライしてもらい、コードレビューの効果や効率を高めていただければ嬉しいです。 Tipsを紹介する前に コードレビューは、開発プロセスの早い段階で欠陥を発見できる有効な開発プラクティスとして多くの開発チームで実施されています。 しかし、プルリクのレビュー依頼をしてからレビューが返ってくるまで1日以上かかったり、その後、レビューの対応か
Code improves with multiple reviews and revisions, and this process isn’t something that can be done alone. Spotting errors in code design is difficult at the best of times — and the closer you are to the work, the harder it can be to critique. That’s where code reviews come in. The beginning: introducing code reviewsWhat is a code review? Code improves with multiple reviews and revisions, and thi
わたくし@yimajoが仕事のコードレビューで気をつけていることを書いておきます。特にiOSアプリ開発をしているので内容はiOSアプリ開発におけるコーディングやStoryboardについて書いていますが、その前提やメンタル面の話が多めです。 ちなみにiOSアプリのコードレビューで見ているポイント 2020年5月版にインスパイアされて書いてみました。 前提 レビュー時にリスクや課題、問題という言葉を意識して使い分ける 「このコードは問題です」という指摘をするとき、「問題」という言葉の意味をなるべく共通の理解を持つ 問題 現在起こっている正常でない状況 例: 仕様を表現できていない 例: 不具合がある 課題 問題を整理/分割したもの 例: deprecatedなAPIを使っている リスク 時間の経過もしくは何かの要因によって課題や問題になってしまう事柄 例: テストコードが書けていないので手を
コードレビューが怖かった私の、レビューへの向き合い方が変わった話 ソニックガーデンジムに参加してコードに対する向き合い方が変わった話 登川氏の自己紹介 登川仁至氏：じゃあ始めていきたいと思います。「ソニックガーデンジムに参加してコードに対する向き合い方が変わった話」という長めなタイトルなんですが、そのまんまの感じになります。 まず自己紹介から言っていきます。ソニックガーデンジム7期生。前期ですね。プログラマー歴も2、3年ぐらいですね。今はWebアプリケーション開発をしています。沖縄に住んでいて今日はすごく暑くて半袖でもぜんぜんいけました。すごく暖かいです。「白くま」が横なのは、あんまり気にしないでください（笑）。ちなみに名前は「ノボ」です。よろしくお願いします。 本セッションで話すこと 今回何を話すのかです。タイトルどおり、「ソニックガーデンジムに参加してコードに対する向き合い方が変わった
はじめに銀座にうまいラーメン屋が多くて感動している岩下（@jaxx2104）です！これまでリクルートライフスタイルにて飲食業務支援アプリの開発をしていましたが、8 月からリクルートとサイバーエージェントのジョイントベンチャーである株式会社ヒューマンキャピタルテクノロジー(HCT)の開発チームリーダーとしてジョインしました 💪 従業員のコンディション可視化・改善ツール「Geppo」は回答画面と管理画面を WEB アプリケーションとして提供しており、Vue.js で作られています。 そんなフロントエンドにジョインして 1 ヶ月の改善の取り組みについて紹介したいと思います。 フロントエンド課題に取り組む技術レイヤーから開発フローまで業務上の課題を開発メンバー全員にヒアリングして課題設定をしました。 「問題に対する解をすぐ出せる」「自分の仕様把握になる」の二点を重視して、自分が元々フロントエンド
Supercharge your entire team with AI-driven contextual feedback & smart chat
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つである連合機能の実
はじめに こんにちは、minne事業部でwebアプリケーションエンジニアをしているkazuです。今回の記事は、コミットメッセージを書く時に、自分がこれまで愛用してきたgitmojiをやめた話をします。 そもそもminneの開発チームにおけるコミットメッセージのルール minneの開発チームでは、コミットメッセージのルールは特にありません。 私がペパボに入社した当初、「逆か」というコミットメッセージもあったりなどして、意外とみんなカジュアルにコミットメッセージを書いているなと思っていました。なるべく実際に開発をする中でのプロセスをありのままに残していきたいという思いがあるのかなと思っています。 gitmojiとは 特にコミットメッセージのルールがないということで、これまで自分が個人開発などでは使ってきたgitmojiをminneの開発チーム内でも使っていました。 gitmojiとは、gitの
Google が How to do a code review のドキュメントを公開しました。いくつかのセクションのうち、レビュアーのための1つ Speed of Code Reviews を読んで、読み取ったものをメモします。 ※ 日本語に翻訳されたプロジェクトがあります: Google エンジニアリング・プラクティス ドキュメント | eng-practices なぜコードレビューは早くするべきか？ Googleは、”個人”の開発者のコードの書く早さを最適化するのではなく、開発者の”チーム”が一緒にプロダクトを作る早さを最適化する。個人の早さは重要だが、チーム全体のベロシティほど重要ではない。 レビューが遅いとき、次のことが発生する: チーム全体の速度が低下する レビューにすぐに反応しない人は個人として別の仕事を完了できる。ただし、他のチームメンバーの機能開発やバグフィックスは、レビ
The Standard of Code Review The primary purpose of code review is to make sure that the overall code health of Google’s code base is improving over time. All of the tools and processes of code review are designed to this end. In order to accomplish this, a series of trade-offs have to be balanced. First, developers must be able to make progress on their tasks. If you never submit an improvement to
コードレビューのスピード
コードレビューのスピード なぜコードレビューは早くなければならないのか？ Google では、開発者のチームが1つの製品を協力して開発する速度を最適化しています。これは、個人の開発者がコードを書くことができる速度を最適化するのとは逆です。個人の開発者の速度が重要なのは確かですが、チーム全体の速度と同じくらい重要というわけではありません。 もしもコードレビューが遅かった場合、以下のような問題が起こってしまいます。 チーム全体の速度が低下してしまう。たしかに、ある個人がレビューに速やかに返事をしなかったとしても、他の仕事を進めることはできます。しかし、各 CL のレビューや再レビューの遅れが積み重なれば、チームの残りのメンバーが行う新しい機能やバグの修正に、数日、数週間、数ヶ月の遅れが生じてしまいます。 開発者がコードレビューのプロセスに抵抗するようになってしまう。もしもレビュアが数日に1回し
チーム開発実践入門──共同作業を円滑に行うツール・メソッド WEB+DB PRESS plus 目次 目次 はじめに コードレビューツール GitHub Redmine Code Review プラグイン Review board Upsource Crucible コードレビューで注意すべきこと レビュワーは完璧主義にならない 可能であれば、コードレビューを開始する前にレビュワーを選び、大まかな設計方針を決めておく できるだけ良い部分は褒める コードレビューのサイズはできるだけ小さくする コードレビューの反応はできるだけ早くする コードスタイルはスタイルガイドに従う レビュワーがレビューで、確認すべきこと コメントは論理的に、そして礼儀をもって 良いコードレビューの作り方 コードレビューでよく使われる言葉 PR LGTM IMO Nit TL;DR. 参考資料 MyEnigma Supp
自分のプロジェクトで Code Climate を使ってみた時の話をします。 Code Climate とは？ コードの品質とかを測れるサービス OSS なら無料で利用可能 使ってみた結果 私のコードに対して、下記のような指摘が来ました。 Function toCommandSections has 29 lines of code (exceeds 25 allowed). (toCommandSectionsメソッドが29行あるから、25行以下にしてくれ) About 1 hr to fix (1時間あれば直せる) こちらは分かりやすい指摘です。 ただ"1時間で直せる"とは誰がどういう見解で言っているのか納得行きません。 Function read has a Cognitive Complexity of 8 (exceeds 5 allowed). (readメソッドの Cogni
コードレビュー依頼されたときのフローチャート 現時点の私のマインドです。※今後、みなさんのフィードバックを得て更新することもあります。 心がけているいること A. リアクションする レビュー依頼されたらすぐにリアクションをします。 これは依頼者に「あ、レビュー依頼伝わってる」と安心してもらうためです。 これがないと、「気づいてるかな？」とモヤモヤさせてしまい、依頼者が集中できる環境を作ることができません。 また、複数人のレビュワーがいた場合、自分が見ることを分かるようにする意図もあります。 これをすることで、他のレビュワーが忙しいときは「あ、◯◯さんが見てくれてるから滞ってない」と安心してもらえます。 B. レビューの難易度を判断する 私がレビューを受け取ってからすぐにするのは下記の2点です。 issueの内容と振られているweightを確認する diffのファイル数を確認する diffが
What to look for in a code review Note: Always make sure to take into account The Standard of Code Review when considering each of these points. Design The most important thing to cover in a review is the overall design of the CL. Do the interactions of various pieces of code in the CL make sense? Does this change belong in your codebase, or in a library? Does it integrate well with the rest of yo
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Maintainer Month: オープンソースをメンテナンスするコツ
「気に入らないコード」をレビューする際にRed Hatのエンジニアはどうしているのか
Indeedを退職してUbieに入社します｜masa_kazama
Goのリリースプロセスとブランチ戦略 - YAMAGUCHI::weblog
HomebrewのCaskリポジトリを介した任意コード実行
ダブルチェックを低減する技術 - ESM アジャイル事業部 開発者ブログ
コードレビューで心がけている3つのこと【PHPカンファレンス協賛記念ブログ！】 - コネヒト開発者ブログ
コードレビュープロセスの負荷や時間を減らすために取り組んでいる10のTips - Qiita
Code Reviews 101 - The Basics | Sema
自分がコードレビューで気をつけていること（2020.5 iOSアプリ開発版 ）
コードレビューが怖かった私の、レビューへの向き合い方が変わった話
ジョインして1ヶ月 Geppo のフロントエンドにおける改善の取り組み｜jaxx2104
AI Code Reviews | CodeRabbit | Try for Free
Bluesky、AT Protocol開発助成金を発表――招待制廃止、連合機能の実装に続き、オープンな開発エコシステムによる成長がさらに加速 | gihyo.jp
コミットメッセージを書く時にgitmojiを使うのをやめた話 - Pepabo Tech Portal
Speed of Code Reviews を読んでのメモ - miso_soup3 Blog
The Standard of Code Review
チーム開発初心者のためのコードレビュー入門 - MyEnigma
Cognitive Complexity で、コードの読みやすさを定量的に計測しよう - Qiita
コードレビュー依頼された時に心がけていること - Qiita
What to look for in a code review
akina2.ue.bulog.jp
kai-you.net
www.kyoto-np.co.jp
mainichi.jp
togetter.com
www.asahi.com