コードレビューをAIに手伝ってもらい楽をしてみる - hiroppy's site
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
[速報]機械学習でコードレビュー!? Amazon CodeGuru がついに GA されました！ | DevelopersIO
re:Invent2019 で発表されていた機械学習でコードレビューをしてくれるサービス、Amazon CodeGuru がついに GA されました！ Amazon CodeGuru とは Amazon CodeGuru は、自動化されたコードレビューとアプリケーションパフォーマンスの推奨事項を提供する機械学習サービスです。アプリケーションのパフォーマンスを損なう最もコストがかかるコード行を見つけ、一晩中トラブルシューティングを続けるのに役立ちます。さらにコードを修正または改善するための具体的な推奨事項を示してくれます。 CodeGuru によるコードレビューはルールマイニングと、ロジスティック回帰とニューラルネットワークの組み合わせを活用した教師あり機械学習モデルを使用して行われます。CodeGuru の機械学習モデルには、Amazon 内部での数十万のプロジェクトと 10000 を超え
![[速報]機械学習でコードレビュー!? Amazon CodeGuru がついに GA されました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/3cd8e20259a86e231ed6daa151fd1bc59fa63c4a/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F11%2Faws-eyecatch.png)
下から目線のコードレビュー - steps to phantasien
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
コードの健全性: 礼儀正しいレビュー == 役立つレビュー
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
「気に入らないコード」をレビューする際にRed Hatのエンジニアはどうしているのか
「気に入らないコード」をレビューする際にRed Hatのエンジニアはどうしているのか：10個のヒントとは？ プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合はどうしたらよいだろうか。Red Hatのソフトウェアエンジニアが、コードレビューを行うに当たって念頭に置くべき10のヒントを解説した。 Red Hatでソフトウェアエンジニアを務めるデビッド・ロイド氏は2019年7月8日（米国時間）、コードレビューを行うに当たって念頭に置くべき10のヒントを同社の開発者向け公式ブログで解説した。プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合に役立つ指針だ。コントリビューター側としても参考になる。 これらのヒントは、客観的で的を射たレビューを行い、プロジェクトとその参加者を前進させるという観点からまとめられている。 （1）
コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
コードレビュー ありがちな問題への対処例 - Crieit
コードレビュー、これまでいろんなプロジェクトで経験して、意外と使われていないノウハウがあったり、風習が違ってつらみがあったりしたので、いろいろまとめてみる。 指摘事項について よくある話 - 駄目コードを憎んで人を憎まず。駄目なのはコードであって人格じゃない - 指摘する人は人格攻撃せずにコードのどこが悪いのかを指摘しましょう - 指摘される人も、言われているのはコードの問題であって人間の問題じゃないので、素直な心で受け止めよう この辺はみんな知ってると思うので略。ぼくが思う大事なルール コードレビューで指摘された内容は、対応必須ではない 理由： 対応必須にすると、「これ言ったらリリースできなくなるよね」みたいな忖度が発生してコメントできない人が出現するから。 絶対ダメとは言わないけど、あまりよくはない、みたいな指摘については、そのときは急ぐからリリースするけど、次回から気をつけるとかがあ
モブプログラミングとコードレビュー
特集1では，2人1組になってコードを書くペアプログラミング（ペアプロ）と，チーム一丸となってコードを書くモブプログラミング（モブプロ）について解説します。… この中で、モブプロは モブプログラミングの「モブ」とは群衆のことです。モブプログラミングでは、ペア（2人）ではなく、モブ（チーム全体）でプログラミングを行います。モブの人数は3人から5人くらいを想定しています。ペアプログラミングと同様に、コードを書くだけでなく、すべてをモブで行います。 と説明されています。 私がモブプログラミングという言葉を初めて聞いたのは、現マイクロソフト牛尾氏の以下のブログ投稿だったように思います。
新人プログラマをレビューで傷つけないために - Qiita
はじめに この半年くらいで初めて本格的にチーム開発を行い、今では日常的に GitHub の Pull Request を使っています。 チームの方々には、基本的なことから応用的な部分まで様々な観点からレビューをしてもらって、大いに勉強になりました。 ただ、時には「新人にとっては厳しいレビュー」をいただき、1 人で傷つきモチベーションを落とすこともありました。 もちろんそれは悪意のあるものではなくて、新人とレビュワーのスキルのギャップによって意図せず生み出されてしまうものです。 そのような不幸なレビューによって苦しむ新人が減ることを願って、新人を不用意に傷つけてしまう恐れのあるレビューをまとめていきたいと思います。 新人教育の場に少しでも役に立てていただけると嬉しいです。 前提条件 今回の対象とする「新人」は、本格的な開発経験が1年未満の方を想定しています。 個人で少しプログラミングはしてき
デキるプログラマだけが知っているコードレビュー7つの秘訣
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。Read less
コードレビューを支える『褒め文化』 - エムスリーテックブログ
コードレビュー、好きですか？ エンジニアリンググループの山口です。 クラウド電子カルテ「エムスリーデジカル」を開発しています。 今回は、チームに根ざしている『褒め文化』についてお話しします。 ※この記事は、エムスリー Advent Calendar 2018 13日目の記事です。 『褒め文化』とは 簡単に言えば、コードレビューで褒める文化です。 コメントに対してコメントしている様子 とても簡単です。 とても簡単なのですが、前職(SIer)ではこういった経験が全く無かったため*1、join直後は（良い意味で）驚いたのが印象に残っています。 とにかく褒める けっこう安易に安直に褒められますし、褒めます。 アカウント名は一部加工 思ったことを素直にコメントにしてしまいます。 褒め文化の効用 ここからは「※個人の感想です」になってしまいますが、こうした褒め文化は、レビュア・レビュイどちらの立場でも
開発現場に学ぶ、円滑なコードレビューに必要な8つの手法 ～手段から準備、実施時期まで徹底解説～｜ハイクラス転職・求人情報サイト AMBI（アンビ）
開発現場に学ぶ、円滑なコードレビューに必要な8つの手法 ～手段から準備、実施時期まで徹底解説～ コードレビューによって解決される問題とは？そして、実際にチームでコードレビューを実施する上で気をつけるべきこととは？ソニックガーデンの取締役プログラマー西見公宏さんが、コードレビューのポイントを、実践に基づき解説します。 ITを活用して事業の課題を解決するサービス「納品のない受託開発」を提供する会社、ソニックガーデンの西見公宏（にしみ・まさひろ／@mah_lab）です。お客様の「バーチャルCTO」として、サービスの企画からシステムの開発・運用まで、日夜幅広く関わらせていただいております。 皆さんは普段、ソースコードをどのくらい読んでいるでしょうか？ 普段からソフトウェア開発をしている人であれば、何か問題が起こったときの原因調査のために他の人が書いたコードを読んだり、はたまた自分の書いたコードを読
開発効率を上げる！コードレビュー自動化サービス4選を使ってみた【SideCI・Codacy・Hound・Scrutinizer】 - paiza times
(English article is here) こんにちは、吉岡(@yoshiokatsuneo)です。 昔はソフトウエア開発というとローカルのPCでやることが多かったですが、近年のWebサービス開発では、クラウド上で動作するサービスの利用が欠かせなくなっています。 たとえば、GitHubなどのソースコード管理サービスは広く普及していますし、デプロイ向けサービスのHeroku、継続的インテグレーションサービスのCircleCIといったものも多く使われてます。クラウド開発環境のPaizaCloudもそうですね。 こうしたクラウドサービスを使えば、個別のPC環境に依存せずに、すぐに必要なサービスが使えます。また、インストールやアップデートなどといった環境構築に関する手間も省けます。 さて、クラウド上で開発をサポートするサービスには、静的コード解析をクラウド上で行ってくれる自動コードレビュー
悪いコードを憎んで人を憎まず！ プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub｜Webエンジニアのキャリアを考える！
悪いコードを憎んで人を憎まず！ プルリク送付前に心がけたいコードレビューのコミュニケーション術 コードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、現役エンジニア・池田 惇さんの経験とともに考えてみます。 アプリエンジニアの池田 惇（いけだ・じゅん／@jun_ikd）です。 コードレビューとは、エンジニアにとって毎日発生する作業であり、「コードを書く」という行為と等しく重要なタスクの1つです。同時に、ただ漠然と「粗探し」をするだけがレビューの目的ではありません。特に若手のエンジニアにとっては、先達のエンジニアのコードにじっくりと触れ、学びを得て、さらにチームに自分の持つ知識・技術を還元する、大事な機会でもあるのです。 今回はコードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、私自
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レビューの仕方
コードレビュー研修
GitHub - reviewdog/reviewdog: 🐶 Automated code review tool integrated with any code analysis tools regardless of programming language
余裕を生み出すコードレビュー 〜レビュイー編〜 / code-review-phpcon-2019
デキるプログラマだけが知っているコードレビュー7つの秘訣（DevLove版）
