コードレビューの設定について Team のノイズを減らし、pull request レビューに対する個人の責任を明確にするには、コード レビュー設定を構成します。 Teamの通知 自動割り当て Team通知について リクエストされたTeamメンバーにのみ通知されるようにした場合、TeamにPull Requestのレビューがリクエストされても、そのTeam内の特定のメンバーにもレビューがリクエストされていたなら、Team全体への通知送信は無効化されることになります。 これは、リポジトリでTeamがコードオーナーとして設定されているものの、しばしば特定の個人が自分たちのPull Requestに対する適切なコードレビュー担当者となるだろうことをリポジトリのコントリビューターたちが知っている場合に、特に役立ちます。 詳しくは、「コードオーナーについて」を参照してください。 自動割り当てについて
コードレビュー時に「強い言葉を使わない」とか「命令ベースではなくお願いベース」とか「コメントは優先度をつける」とかそういう当たり前を当たり前にやってほしいのだがなあ。なんでも正確な言葉使いで正確に書けばいいと思ってるのは小学生までだと思うので小学生にマジレスはしないが…。
cargo crev でコードレビューをしてみたらバグを見付けた話など Rustの依存関係の信頼性を検証する (crev) - Qiita という記事を読んで、面白そうだったので cargo-crev を実際に使ってみた。 これはコードレビュー自体を完全に自動化するためのものではなく、前準備、結果の公開・共有・利用などを支援するツールなので、コードレビュー自体は自力で行う必要がある。 そんなわけで、基本的な概念の紹介と、実際にいくらかコードレビューをしてみたところ unsafe 絡みのバグを見付けたという話と、ツールを使っての所感なんかを書く。 この記事の半分は雑な日記みたいなものなのでスッ飛ばすのが良い。 というかあまりにダラダラ書きすぎたので、後でいろいろバッサリ削る可能性もある (←放置フラグ)。 前提 このセクションは、わかっている人は読み流しても問題ない。 依存とコードへの信頼
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
Misoca のコードレビューで教えてもらった RSpec マッチャまとめ - mallowlabsの備忘録
この記事は Misoca+弥生 Advent Calendar 2019 の7日目の記事です。 はじめに Misoca に入社して1年とちょっとが経ちました。 Misoca は Ruby がメインの会社です。 私のキャリアはずっと Java だったので、特に RSpec の知識が貧弱で、RSpec は「expect って書くのは知ってる…」ぐらいの知識でした。 RSpec のマッチャは数も多く、いったいどこから勉強したらよいのか…というままテストコードを書いたため、コードレビューでよりよい書き方を教えてもらいつつやってきました。 そこで、同じ指摘をもらわないように自分用にまとめつつ、同じような境遇の人に少しでも役に立つように、Misoca のコードレビューで教えてもらった RSpec の書き方を紹介します。 注意事項として、以下で書き換え前と後のコードが出てきますが、どちらが良い悪いという
技術力を見える化する！オブジェクト指向コードレビューの実践 - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに こんにちは akihiyo76 です。現在、私のチームではレビューガイドラインを明文化して、レビュアーはガイドラインに従ってコードレビューを行なっています。このガイドラインは、チームで運用を開始して２年になりますが、チームでも浸透しレビュー時に必ず利用するようになりました。 はじめに コードレビューの課題感 課題改善に向けて 採用したコードレビュー観点 1. Design（設計） 定義 具体例 2. Simplicity（理解容易性） 定義 具体例 3. Naming（命名） 定義 具体例 4. Style（コードスタイル） 定義 具体例 5. Functionality（機能要求） 定義 具体例 6. Test（テスト） 定義 具体例 7. Document（文章） 定義 具体例 指摘対応の要否 具体的な利用方法 指摘例 最後に コードレビューの課題感 私は現在モバイル開発チー
コードレビューの上達を早くするには？｜森崎 修司
コードレビューでやっていることをつきつめると「欠陥を見つける」「将来読むことを想定して、読みにくい部分をみつける」「代替案がないか確かめる」というくらいになります。では、これらがうまくなるには、どうしたらよいでしょうか。これまでたくさんのレビュー指摘をみたり、レビューしたりされたりしてたどりついた私の答えは、対象コードに合わせた読み進め方を選んで、問題がある部分を見つけることです。 まずは、コードレビューでは何をしているか説明します。 欠陥を見つけるのは、本来あるべき実装方法とコードを突き合わせてズレがないかを探しています。ありがちな間違いを覚えていて、そのパターンがあてはまるところを見つけていると言えます。そうしたパターンも「こういうふうに実現しないといけない」と「コードとしてこう書かれている」というズレを見つけていると言えます。 もっともイメージしやすいのは、仕様を「こういうふうに実現
はじめに こんにちは、品質改善チームのrjgeです。 RubyKaigi 2019のレポートぶりに担当が回ってきたので、チーム活動の一環として行なっていたソースコードレビューのお話をしようと思います。 そもそもの発端 品質改善チームでは、ANDPADの開発で使用している開発言語やフレームワークのアップデート、パフォーマンスチューニング、自動テストの実装・環境整備など、新規開発を行う際に置いてけぼりにされやすい箇所のフォローを主に行なっています。 ANDPADは比較的新しいプロダクトなどの新規開発箇所についてはレポジトリが徐々に分かれてきているのですが、本体レポジトリはそれなりの規模の入り組んだソースコードになっています。 このレポジトリ、実は私の入社当時（2018年夏頃）は自動テストがほぼなく、そもそも実行しても動かない状態でした。自動テスト書いてるよ！と面接の際に会話したのですが、動かな
コードレビューで使われる NIT / NITS の意味と、その語源を整理します。 はじめに NIT / NITSの意味 NIT / NITSの語源 おわりに 参考 はじめに コードレビューなどで、"NIT / NITS"という略語が使われることがあります。 意味は知っていてもその語源はよく知らなかったので、深堀してみました。 NIT / NITSの意味 まず NIT / NITS は、細かい話だけど、の意味です。 typoやコードスタイルの細かい指摘をするときに、nit: XXX...のように使われたりしますね。 NIT / NITSの語源 では NIT / NITS の語源は何でしょうか。 これは、nitpick が語源のようです。 私が資料を探したなかで最も明示的に整理していたのは、ChromiumOS Docsでした。 nit: short for “nitpick”; refers
DeepMindのAlphaシリーズ最新作「AlphaCode」が、競技プログラマーの標準レベル（Codeforces TOP 54%）に達したとの発表がありました。 AlphaCodeは今をときめくTransformer系のディープラーニングで、課題文を入力すると解答プログラムを出力する自然言語処理を行います。そうです、これはすなわちプログラミングをするプログラムです。マジかよ……。 詳しい手法については公式ブログや論文を参照してほしいのですが、DeepMindは別途いくつかの解答例について正誤あわせて確認できるデモサイトも用意していて、これがめちゃくちゃ面白いです。 ええ、こちとら天然物のプログラマーです。人工知能とやらが絵や写真を自動生成しはじめたあたりはまだ笑って眺めていられましたが、我々の崇高なるプログラミング領域を侵されるとなってはたまりません。いうて大したことないやろ的な、上
こんにちは。クックパッドの新規事業「クックパッドマート」を運営する買物プロダクト開発部 部長の勝間です。プロダクト開発中心に事業全体を見つつ、エンジニア採用に力を入れています。 以前はオンラインペアプロの案内を行いました。 今回はまだ見ぬエンジニアと出会うために、コロナ禍でも知的好奇心の高いエンジニアの方と交流できる新しい方法を用意しました！ ずばり 🎉🎉🎉🎉コードレビュー実践会実施します！🎉🎉🎉🎉 📃📃📃📃📃📃応募フォーム📃📃📃📃📃📃📃📃📃📃 https://cookpad.com/ct/196484 📃📃📃📃📃📃📃📃📃📃📃📃📃📃📃📃📃📃📃📃📃📃 コードレビュー実施会皆さんはクックパッドのエンジニアに対してどんなイメージを持たれているでしょうか？ ・とにかく技術が大好きそう？ ・設計をかなり細かく
今月末に開催されるソフトウェア工学の国際会議 ICSE にて、Journal-First Track という「論文誌に採択されたが国際会議では未発表」という原稿について、私たちの研究室から１件発表があります。 arxiv.org この論文は、オープンソースソフトウェアプロジェクトで行われているコードレビュー活動を調査し、「誰に依頼すると、引き受けてもらえるのか」を機械学習で予測する方法を考えた論文です。データセットには、Android, LibreOffice, OpenStack, Qt プロジェクトに投稿されたパッチ 230,090 個を使っています。 この論文では、コードレビューは誰でも引き受けてくれるわけではなく、16％から66％のパッチで、レビューのお願いに反応してくれないレビュアーが 1人以上いることを報告しています。引き受けてくれないことがあるからと多数の人に依頼を出すのは迷
ChatGPTでコードレビューが可能？ChatGPTはOpenAIが提供しているテキストベースの対話型AIです。このツールはAIツールとして世界的に有名なため、すでに利用したことがある方も多いでしょう。 そんなChatGPTは、実はコードレビューにも活用できます。 本記事では、ChatGPTをコードレビューで利用するメリットや、利用方法、よくある疑問についてまとめました。エンジニアの方や、現在プログラミング言語を学んでいる方は、ぜひ参考にしてください。 【参考】：ChatGPT公式
みなさん普段開発していて、お昼ごはんを食べに外に出たとき、急なコードレビューが必要になったり、病院の待ち時間でコードレビューを片付けちゃおうと思った経験はありませんか？僕はけっこうあります。こういうとき、 GitHub の公式サイトを開いてちまちまレビューしていたのですが、レスポンシブ対応しているものの基本的にブラウザー向けに作られた UI なのでやりづらいという問題がありました。 が、昨日モバイルアプリがリリースされたとのアナウンスがありましたので、こういった問題点が改善されていないかを早速試してみました。 iOS 版のファーストインプレッションですので、 Android を常用されている方の感想をお待ちしています！ GitHub モバイルアプリとは 公式ページによると、 issue の確認や整理がしやすい点が前面に打ち出されています。 https://github.com/mobile
コードレビューで何を期待するべきか
コードレビューで何を期待するべきか 注意: 以下の各ポイントについて考えるときは、必ずコードレビューの基準を考慮するようにしてください。 設計 レビュー中に取り上げるべき最も重要なことは、CL の全体的な設計をどのようにするかということです。CL 中のさまざまなコードのインタラクションは意味のあるものですか？ その変更はコードベースかライブラリ、どちらに帰属するべきものでしょうか？ システムの残りの部分とよく統合されていますか？ その機能を追加するのは本当に今が適切なタイミングですか？ 機能性 その CL は開発者が意図した通りのことを行っているでしょうか？ 開発者は、そのコードのユーザーにとって、どんなよいことがあると考えていますか？ ここで言う「ユーザー」とは、通常エンドユーザー (もし変更がエンドユーザーに影響する場合) と開発者 (将来このコードを「使う」必要があるユーザーのこと)
概要 GitHub上にコミットが行なわれたタイミングで静的ファイル化したStorybookを閲覧できるようにする方法をまとめました。 これを行なうことでコードレビュー時にUIの変更点を確認がやりやすくなります。 Storybook公式 で紹介されている方法です。 今回は実際に自分が 友人 と開発・運用しているサービス LGTMeow にこれらの設定を追加したので、実際の設定内容を踏まえて解説します。 対象読者 GitHub上でコードレビューを用いた開発手法を実践している人（もしくは実践したいと思っている人） Storybookを利用したことがある人 筆者のバックグラウンド エンジニア歴はもうすぐ8年程です。 バックエンドやクラウドがメインでしたが、ここ1年半ほどはフロントエンドメインです。 業務でも個人開発でもNext.jsを利用しています。 ちなみに最初にこの方法を知ったのは READY
こんにちは。リンクウェル対面診療システムチーム、テックリードの山本です。 今回はコードレビュー時に開発部で実施しているコメントタグのご紹介です。 多分イケてる開発チームではすでに取り組んでいる試みだとは思いつつも、今回はなぜ必要なのかを改めて考えてみたいと思います。 GitHubのプルリクレビューについて 弊社のコードレビューではまず第一に「要求を満たすよう動くこと」が重視されます。その上で次のような点に注視しながら指摘を行います。 外部サービスの特殊な挙動やセキュリティ機構などが考慮されているか。 不具合が発生した時に検知できるようになっているか。 将来的に修正しづらくなる構造になっていないか。 N+1問題などパフォーマンスに問題がないか。 その上でコメントを書く際に次のようにタグを付けて分類しています。 must: 絶対に直して欲しいとき。強い指摘になるので言葉遣いに気をつけるべき i
機械学習でコードレビューを自動化 ! Amazon CodeGuru 3 分間クッキング - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
アプリケーション開発に携わっている方であれば、誰もがコードレビューを実施する、あるいはコードレビューを受けるという立場として、コードレビューを経験したことがあるのではないでしょうか。コードレビューのプロセスは、プロダクトの欠陥を無くすという観点と、組織としてのエンジニアリング力を維持するという観点で不可欠です。 しかし、コードレビューを行う人材の確保が難しいケースも存在すると思います。レビューを行うにあたっての知識を備えていることがまず前提としてあり、更にプロダクト全体に対する理解も必要とされます。そして、いざコードレビューとなると、時間を確保する必要があります。開発が活発なほどコードレビューの時間も比例して増えてしまうので、レビュアーの負担増にも繋がります。コードレビューがネックになってリリースが遅延してしまうのでは本末転倒ですよね。よって、コードレビューの自動化はこれまでも非常に注目を
2024.02.15 エンジニア辞典 プログラミング ソフトウエア開発において、コードレビューは品質向上のために欠かせない工程の一つです。日常的にプログラムを書いているエンジニアでも、完成したプログラムにバグがないか、最適な書き方であるかなどを客観的に見ることは難しいでしょう。 そこで、プログラムの作成者とは別の人物がプログラムの品質をチェックするコードレビューが重要視されています。しかし、コードレビューは簡単なものではないため、適切なやり方に悩むエンジニアも少なくないかもしれません。 この記事では、コードレビューの概要や重要な観点、具体的なやり方、注意点まで詳しく解説します。 コードレビューとは、プログラムのソースコードを作成者とは別の人物が検証することです。 プログラムの作成者でありソースコードの検証を受ける「レビューイ」は、検証を行う「レビュアー」を選定し、コードレビューを依頼します
はじめに 「コードレビューは自分にはハードルが高いなー🙁」、「知識ないから、先輩のPRにコメントするの恐れ多い😨」などと思っていませんか？ 自分は普通に思っていました〜 特に、自分の書くコードにすら自信がないのに、突然レビューしようとしても、難しいですよね💦💦💦 自分は、プログラミング初めてまだ1年半であるため、先輩エンジニアやチームメンバーのコードをレビューするのは恐れ多く、ワンステップ先だと思っていました。🤔 最近は、全く完璧ではなく、なんちゃってですが、積極的に行なっているつもり、、、 ですが、『どこを見たらいいんだろう？🤔』、『これレビューできているんだろうか？😟』と思うことが多くあります。 そんなコードレビューについて、先輩エンジニアやCTOから多くのアドバイスをいただいたので、記事にしたいと思います！ ※記事では、プルリクエストのことをPRと書いてます！ 対象読
他にもSHOULDを使う例をよく見かけますが、対応すべきかどうかが曖昧なのでMUSTかIMOに寄せるべきだと私は考えています。 2. コメントの仕方に気をつけるソースコードレビューのコメントはコミュニケーションでもあるので、コミュニケーションが円滑になるよう絵文字などを交えて投稿した方がいいと思います。 3. よいところもコメントする2と同じ理由ですが、ソースコードレビューはコミュニケーションであるので、相手をほめることも意識した方がいいと思います。また、よいところをコメントすることはメンバーの学びにもつながります。 4. 根拠を示すコメントが「こうすべき」だけだと、レビュイーは「なぜ？」と思ってしまいます。その根拠として、参考文献などをリンクで示すと親切です。 5. 進捗に応じて見るポイントを変える作業中のソースコードをWIPとして先にプルリクエストを出すやり方もあります。WIPのときは
週報 2022/02/06 コードレビューはコミットを新しい順に読むとわかりやすい説, アファンタジア被験者に応募した - しゅみは人間の分析です
近況 ワクチン接種3回目 近所の病院でモデルナが捨てるほど余っていると聞いたので打ちに行った。ワクチンを捨てるなんてとんでもないことだ。手元にはまだ接種券が来ていなかったが、2回目の接種証明書があれば打てるそうなので打つことにした。そういえば1回目と2回目もこうやって急に決まった気がする。 前回はファイザーだったのだが今回はモデルナになった。副反応がきついという噂は聞いていたのでしっかり準備をしたが、それでもつらい思いをした。一番つらかったのは悪寒で眠れなかったことだ。手足は冷え体は震えていたのに、頭は半分寝ているので対処ができない。そのまま数時間過ごしたのちに、なんとか起き上がってたくさん着込んだり薬を飲んだりしたら、やっと眠れた。 熱は最高で38.2度ぐらいまで上昇したが、熱が上がってからは割と楽だった。大事なのはしっかり食べてしっかり寝ることだと思う。我々の体は物理法則に従っており、
こんにちは！リンクアンドモチベーションのモチベーションクラウド開発チームで、バックエンド開発をしている谷です。 エンジニアなら誰しも、改修が終わって自信満々で出したプルリクエストに、尋常でない数の指摘がついてしまい、落ち込んだ経験があるのではないでしょうか。 また、そのような話を周りから聞く中で、自分のプルリクエストに自信が持てず、「レビューに出すのが怖い！」という新人エンジニアの方もいらっしゃることと思います。 今回はコードレビューに苦手意識のある方向けに、私自身も経験した「ありがちな失敗」と、その対策としてチェックすべきポイントをまとめてみました。 ※この記事は モチベーションクラウドシリーズ Advent Calendar 2021 の9日目の記事です。 TL;DR レビュワーがレビューできるように、前提情報を共有しよう プルリクエストの単位は、できるだけ細分化しよう 当たり前のこと
lint：コンパイラやインタープリタよりも厳しくソースコードをチェックするプログラム linter：エディタ上で lint に引っかかるようなコードの書き方が良くない部分を指摘してくれるもの コードフォーマッタ：コードを lint に従って自動整形してくれるもの 複数人でのソフトウェア開発プロジェクトなどでは，統一的な書き方をして品質向上やレビューコストの削減をするために，コーディング規約を設定することがある．あまりにも細かい書き方の指定を考えて共有するのは大変なので，最低限統一したい部分は言語の開発元や大企業などが公開している linter を使用すると良い． 例えばコミット前にはコードフォーマットして linter のエラー表示がない状態にするなどを規定するだけで，ソースコードを最低限統一された状態にできるので，書き方ではなく処理内容にレビューのコストを集中させることができる． 個人レ
GithubやGitを使っていなかった時期、自分はsvnでみんなでmasterにpushしまくっていた
コードレビューでprivate methodを使い倒しつつSingle Level of Abstractionを意識してみる
どうも、株式会社プラハCEOの松原です 先日プラハチャレンジのメンターセッションの一環でアプリケーションのコードレビューをしていた時に「そういえば自分は新規プロジェクトのコードを読むときによくprivate methodを使って処理を抽象化しているから、これを記事にしたら誰かの役に立つかも」と思い、筆を取りました。 対象読者 新しく参画したプロジェクトで複雑なコードをレビューしたり、仕様を追う必要がある Single Level of Abstraction Principle(SLAP)が気になる private methodを使い倒してみたい 題材 実際のコードを見ながら紹介した方が分かりやすいと思うので本人の同意を得てコードを提供していただきました。 さて今回の題材はプラハチャレンジというオンラインブートキャンプです。今回のコードに関連する仕様は以下の通り： 複数のUserがPair
コードレビューのコメントの書き方
コードレビューのコメントの書き方 まとめ やさしさを持ちましょう。 あなたの考えの論理を説明しましょう。 問題を指摘して明確な方向性を示すことと、開発者自身に決定させることのバランスを取りましょう。 レビュアのあなただけに複雑なコードの意味を説明させるのではなく、代わりに開発者に対して、コードをシンプルにしたりコードにコメントを追加してもらうようにしましょう。 礼儀 一般に、コードをレビューしている開発者に対しては、非常に明快な態度を取り、助けに満ちた気持ちを示すとともに、丁寧に、尊敬の気持ちを持って接することが大切です。このことを実践する方法の1つは、決して開発者についてコメントをしないで、必ずコードについてコメントをすることを忘れないことです。このプラクティスには必ず従わなければならないというわけではありませんが、このように話さなければ相手を怒らせてしまったり、争いのもとになってしまう
TypeScriptのプログラムのコードレビューでanyで記述された箇所を例を添えた上で極力anyは使わないようにと指摘するとスピード感が落ちると苦言を呈されました。彼はリーダーなので従うべきですか？
回答: そもそもなぜ Typescript に any があるかというと、彼のような人にも使ってもらうためです。 なので、彼のいう事は間違ってないし、 Typescript の正当な使用法です。 同時に、質問者さんのレビューもまた正しい。 any を全て無くし、正しい型もしくは unknown に書き換える事が、typescript のゴールの1つです。 現実には、どの程度の any を許容するかはそのプロジェクトの現在状況に依存します。長期的には any を減らしていくべきですが、後回しに出来ることは出来るだけ後回しにした方が良い (YAGNI) という原則もあります。その舵取り...
VSCodeでAzure OpenAI ServiceのChatGPT拡張機能を使ってコードレビューやバグ発見をしよう - Qiita
VSCodeでの開発速度が爆上がりすると評判のChatGPT拡張機能 ChatGPT - Genie AI がAzure OpenAI Serviceに対応しました。VSCode上でChatGPTを使いたいけど、OpenAIだと…という人も安心して使えます。 VSCode の ChatGPT拡張 Genie AI が Azure OpenAI にも対応したっぽいなhttps://t.co/bEPpYZbhtm — TK (@TaigoKuriyama) April 6, 2023 設定方法 VSCodeにGenie AI拡張機能をインストールします。 インストールした ChatGPT - Genie AI の設定画面を開きます。 拡張機能の設定画面でAzure OpenAI Serviceの設定情報に書き換えて設定します。 例には https://your-endpoint-base.op
フィードバックは私たちにとってソフトウェア本体同様に、個人的にも業務的にも重要です。GitLabではフィードバックのすべてではないにしても、ほとんどのコードレビューを使うことで相互に交換します。コードレビューに関してなら、ツールベルトに追加できるツールをいくつか共有しています。今回は、コード作者とレビュアーのためのコミュニケーション戦略について紹介します。 覚えておくこと：セルフレビューで詳細は重要です GitLabにおいて、コードの責任はマージリクエスト作者にあります。コード作者はレビューを依頼する前にチェックリストを作成して、細部を確認することをおすすめします。マージリクエストのチェックリストの例を示します。 すべてのフィードバックサイクルの前に： すべての行を読み返す コードをローカルでテストする すべての変更（またはできる限り）のためのテストを書く マージリクエストに明確な説明を記
コードレビューでの指摘で傷ついたことはありますか？
回答 (3件中の1件目) ありますよ。 自分が傷ついたことも、また、傷つける意図はないのに相手が怒る事もありました。 他の人が他の人にイライラするのも見かけます。 コードレビューというとほとんどがテキストベースのコミュニケーションになります。 メールやLINE(スタンプなしとすると)でのコミュニケーションで失敗したことのない人はいないと思います。テキストベースのコミュニケーションの難しさです。 そして、加えてプログラマの仕事として最も大事なモノの否定になりかねないのですから、気をつけなければいけません。レビュー者がまともなら相手を傷つけないように気をつけなければいけなく、また、...
コードレビューをする時に心がけている3つのこと
1. 否定しない 否定的なコメントは避けるようにしています。 わざと悪いコードを書こうとする人はいないと思っています。レビュイーが自分で考えた最善のコードを書いてくれていると思い、敬う気持ちを忘れないように心がけています。
エディタやコンパイラ、デバッガなど、使い慣れた開発関連ツールを統合した快適な開発環境は整っている。それなのに、思っていたよりも生産性や効率が上がらない。むしろ、煩雑な作業に時間を奪われることが増え、本来やるべきクリエイティブなコーディングが満足いくほどできず、疲弊するばかり。そんな悩みを解消して「アツいIDE環境」に作り替えるCodeStreamの魅力について、New Relicのソフトウェアエンジニア、齊藤恒太氏が語る。 New Relic ソフトウェアエンジニア 齊藤恒太氏 IDEから離れず、コード起点でプルリクやレビューができるCodeStream 日々の業務を効率よく進めるには、作業しやすい開発環境が必要だ。New Relicのソフトウェアエンジニア、齊藤恒太氏も、大好きなもの作りのために生産性も効率も爆上がりする、イケてる開発環境を求めてアップデートを欠かさないと明かす。だが、こ
こんにちは、SaaS Productチームの比嘉です。 私たちSaaS Product チームは常日頃からペアプログラミングを行っています。 チームペアプロの細かい流れは過去に鈴木さんが紹介しています。 tech.uzabase.com そんな中、あるときエンジニアの友人から質問されました。 「ペアプログラミングではいつコードレビューするの？」 話を聞いてみると、その会社ではペアプロを導入し始めたのですが、従来から行なっているコードレビューと役割が重複していることに気づいたそうです。 そこで今回はペアプログラミングとコードレビュー*1について書いてみようと思います。 時世を鑑みてリモートペアプロ中 なぜコードレビューを行うのか？ ペアプロはいつコードレビューしている？ ペアプロでコードレビューできてる？ SaaS Product チームの場合 まとめ なぜコードレビューを行うのか？ なぜコ
CodeGuruにコードレビューされてみたらBoto3の便利機能Waitersを知った話 | DevelopersIO
こんにちは。AWS事業本部のKyoです。 スクリプト、便利ですよね。私も先日「CloudFrontのオリジンを別のものへ変更する」というPythonスクリプトを書いていました。主要な部分は、以下のような形です。 update_distribution 待機 create_invalidation（キャッシュクリア） update_distributionはアップデートのリクエストになるので、レスポンスが返ってきた後、各エッジロケーションにアップデートされた設定がデプロイされるのを数分程度待つ必要があります。ここを待たずにInvalidationを行うとアップデート前の情報が再びキャッシュされる可能性があります。 そんなわけで以下のような実装になりました（簡略化しています）。 client = boto3.client('cloudfront') # CloudFront distribut
マクニカネットワークス、GitHubと連携するコードレビュー自動化サービス「Sider」を販売 | IT Leaders
IT Leaders トップ ＞ テクノロジー一覧 ＞ 開発ツール／プラットフォーム ＞ 新製品・サービス ＞ マクニカネットワークス、GitHubと連携するコードレビュー自動化サービス「Sider」を販売 開発ツール／プラットフォーム 開発ツール／プラットフォーム記事一覧へ [新製品・サービス] マクニカネットワークス、GitHubと連携するコードレビュー自動化サービス「Sider」を販売 2020年7月1日(水)日川 佳三（IT Leaders編集部） リスト GitHub Enterpriseを販売しているマクニカネットワークスは2020年7月1日、GitHubと連携して動作するコードレビュー自動化サービス「Sider」の販売を開始した。GitHubのPull Requestと同期して自動でコードをレビュー（査読）する。人が時間をかける必要のない簡易なコードレビューをSiderに任せ
プルリクエストの単位を小さくし、コードレビューの負荷とマージまでの期間を大幅短縮した話 - asoview! Tech Blog
これは アソビュー！Advent Calendar 2023のB面 19日目です。 🎄 今年のアドベントカレンダーは2面公開なので、ぜひそちらも御覧ください！ こんにちは、バックエンドエンジニアのアズマです。 今回は、プロダクトコードの品質に関わる話の1つで、プルリクエストの単位を小さくし、そのレビューにかかる負荷と、マージまでの期間を大幅に短縮した話をします。 弊社のタスクとコード管理 実際に起こった課題 例1 ちょっと多いかな？ 例2 ファイル数が爆発 例3 スマッシュ大作 ふりかえりと実施したこと 終わりに 弊社のタスクとコード管理 弊社では開発スプリントや修正タスクの管理はJiraで、コードの管理はGitHubで行っております。 新機能の開発、機能改修、不具合の修正、設定変更など、それぞれタスクの粒度は異なりますが、適宜対応するタスクにあわせてJiraのチケットを発行し、このチケ
プラットフォームってつくることより計測することが重要なんじゃないかという話 / Platform Engineering Meetup #8
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Amazon Web Services（AWS）は、アプリケーションの効率改善やコードの品質向上を支援する機械学習ツール「Amazon CodeGuru」の一般提供（GA）を開始したと発表した。 このサービスは、コードをレビューする際のバグの発見を支援する「Amazon CodeGuru Reviewer」と、AWS上で動作するアプリケーションで実行されているのコードのうち、もっともコストの高い部分を特定するツール「Amazon CodeGuru Profiler」で構成されている。 AWSは2019年12月にCodeGuruのプレビュー版を公開した。このツールは、顧客のコードレビューのプロセスを自動化してバグの発見を支援し、問題を修正
[速報]機械学習でコードレビューするCodeGuruでPythonをサポートしてSecurity Detector機能が追加されました #reinvent | DevelopersIO
こんにちは、臼田です。 みなさん、re:Invent楽しんでますか？(挨拶 Amazon CodeGuru待望のアップデートが2つも来ました！ CodeGuruアップデート内容 以下Keynoteのスクリーンショットですが、2つのNEWがあります。 Python対応 全国のPython利用者に朗報です。機械学習でコードレビューをしてくれるサービスであるAmazon CodeGuruがPythonもサポートしました！ これまでCodeGuru ProfilerがサポートしていたのはJava と Java virtual machine (JVM)のみでした。 これで一気にCodeGuru利用者が増えるのではないでしょうか？ 開発しているコードに対してリアルタイムにセキュリティのアラートを提供するサービスのようです。 これまでCodeGuruのコードのレビューはどちらかというとパフォーマンスの
![[速報]機械学習でコードレビューするCodeGuruでPythonをサポートしてSecurity Detector機能が追加されました #reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/1691f45c9a149fa23ecf71949f6c6eff39c1915c/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2020%2F11%2Feyecatch_reinvent-2020-breakingnews-sokuho.jpg)
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Teamのコードレビュー設定の管理 - GitHub Docs
コードレビュー時に「強い言葉を使わない」とか「命令ベースではなくお願..
cargo crev でコードレビューをしてみたらバグを見付けた話など
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ANDPADにおけるソースコードレビューのポイント - ANDPAD Tech Blog
コードレビューにおける"NITS"は何の略か - BioErrorLog Tech Blog
競技プログラミングAI「AlphaCode」のコードレビューをしてみた 😱 - Qiita
クックパッドエンジニアのコードレビュー実践会やります！｜クックパッドマート
コードレビューは活発に活動している人ほど引き受けてくれる - ソフトウェア工学研究の日々
ChatGPTでコードレビューができる？やり方や事例・VSCodeとの連携方法も解説
GitHub モバイルアプリを使ってコードレビューしてみた | DevelopersIO
Chromaticでコミット毎にStorybookをデプロイしてコードレビューを効率化する
コードレビューでコメントタグを使い、心理的安全性を担保しよう
コードレビューとは？ 手順や注意点、実施のメリットまで詳しく解説！ - エンジニアtype | 転職type
若手エンジニアのコードレビュー 〜斜め上のPRを見て学ぼう！〜 - Qiita
ソースコードレビューのやり方や観点のチェックリストを解説します
安心してコードレビューを出すために最低限やるべき4つのこと - Qiita
linter を使ってコードレビューのコストを削減する - Qiita
コードレビューは『目標をセンターに入れてスイッチ』ではない - keroxpのScrapbox
第3回 より思慮深いコードレビューを書くためには | gihyo.jp
コードレビューもトラブルシューティングもIDEで完結！ CodeStreamの実力とは【デブサミ2022】
ペアプログラミングではいつコードレビューするのか？ - Uzabase for Engineers
Compose Compiler Metricsを使った実践的なコードレビュー
AWSの「CodeGuru」、一般提供開始--機械学習活用のコードレビューやパフォーマンス改善