Based on XKCD #1513, Code Quality, adapted and reproduced under CC BY-NC 2.5.The Internet provides a wealth of material on code reviews: on the effect of code reviews on company culture, on formal security reviews, shorter guides, longer checklists, humanized reviews, reasons for doing code reviews in the first place, best practices, more best practices, statistics on code review effectiveness for
新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。 日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング(ないし類似のプラクティス)に取り組んできました。 モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。 www.agilealliance.org ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高(大きな損失を生む問題・後からの修正が困難な問題) 優先度中 優先度低(システムに大きな影響を与えない問題・後からの修正が容易な問題) レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
1月末で約2年ほど働いたIndeedを退職して、UbieというAI×医療のベンチャーに転職します。せっかくの節目なので、社会人になってからを振り返りたいと思います。 目次 ・リクルートについて ・Indeedへの異動に向けて ・Indeedについて ・Ubieへの転職のきっかけ ・これから リクルートについてもともとは新卒でリクルートにデータサイエンティストとして入社して社会人生活を始めました。リクルートは様々なデータを保有しており、データ分析のしがいがありました。また、上司、同期、後輩は優秀な人ばかりで、常に学ぶことばかりでした。特に、データにどのように向き合って、仮説をたてて分析するのか、また、データの裏側にいる実際のユーザーやクライアントの課題を把握してどうしたら解決ができるのかといったスタンス面の土台がこの頃にできたように思います。技術面においても、GCPやAWSを使って機械学習プ
Steven J. Vaughan-Nichols (Special to ZDNET.com) 翻訳校正: 石橋啓一郎 2019-11-01 07:30 Linuxの生みの親であるLinus Torvalds氏は、もう講演はしていない。フランスのリヨンで開催された「Open Source Summit Europe」で同氏が行ったのは、友人であるVMwareの最高オープンソース責任者Dirk Hohndel氏との対話であり、同氏は以前もこの形式で登壇している。Torvalds氏はこの基調ディスカッションで、自分はもはやプログラマーではないと考えていることを明らかにした。 では、誰もが「プログラマーの中のプログラマー」だと考えている同氏は今、何をやっているのだろうか。Torvalds氏は次のように説明した。 もうコーディングは全然やっていない。私がコードを書くのは、ほとんどがメールの中だ。
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
The people you choose as code owners must have write permissions for the repository. When the code owner is a team, that team must be visible and it must have write permissions, even if all the individual members of the team already have write permissions directly, through organization membership, or through another team membership. About code owners Code owners are automatically requested for rev
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes 第42回 Googleのソフトウェア開発におけるコードレビューの役割 (中井悦司) 2018年7月 はじめに 今回は、2018年に公開された論文「Modern Code Review: A Case Study at Google」をもとにして、Googleのソフトウェア開発におけるコードレビューのプロセスを紹介したいと思います。Googleでは、オープンソースの開発で広く用いられる、変更リスト(Change List:CL)単位の軽量なコードレビュープロセスを採用しており、この論文では、1回のレビューにおけるコードの変更量や平均的なレビュアー数についての興味深い統計データも紹介されています。 コードレビュープロセスの概要 Googleのソフト
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
pre-commit A framework for managing and maintaining multi-language pre-commit hooks. Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer
大きいプロジェクトだとクラスとかメソッドがいっぱいあって、それぞれ呼び出し合ったりして、もー意味わかんない。構造を視覚的に追えると良いんだけど、クラス図とかコールグラフを手作業で作ってると埒があかない。 ということで、自動でドキュメント + クラス図やコールグラフを作ってくれるツール Doxygen と Graphviz がとっても便利だったのでメモっておく。 とりあえず説明する上での環境は Mac OS X 10.7 + Homebrew ということで。Doxygen と Graphviz 自体は、UNIX 系の OS ならどれでも動かせるんだと思う。 まずは Homebrew からインストールする。 # brew install doxygen graphviz インストールできたら、解析したいソースコードのあるディレクトリで Doxygen を使う。今回解析するコードは Java だ
lestrratさんがやってくれました。 ずいぶん前から、ソースコードを検索して読みやすいコマンドはないかなーと思っていました。個人的にはackで検索して見つかったファイルをlessで開いて再びキーワードを入れて当該行までジャンプしていたのですが、毎回毎回めんどくさい感じでした。コマンド一発でインクリメンタル検索してキーワード周辺のソースコードを読めるツールが欲しいなぁって思ってたんです。 とあるslackでお昼時に、mattnさんと「ほしいですよねー」という話から始まって、vimにあるgrepとかも物色しながら「いいのないねー」とか言ってたらkanさんが「@lestrrat 案件だ」って言い出して牧さんが召喚されてついさっきpecoに必要な機能が追加されてました。速いw ためしにpicotlsの開発ディレクトリでpecoの一行ラッパーperoを起動し、「EVP_Digest」を検索してみ
前回のネタの続きです。 前回では、以下のリンクを見て、ソースコードレビューソフトを入れてみました。 【レポート】オール・アバウト・Google Chrome - Google Developer Dayセッションレポート (2) http://journal.mycom.co.jp/articles/2009/06/15/gdd2/001.html Chromeの開発に使用されているツール・・・自動ビルド・自動単体テストのためにBuildbot、コードレビューのためにrietveldというツールが使用されている 今回は、実際に rietveld を入れて動かしてみます。 Google社内で使われているコードレビューシステムと同じようなソフトを手元で動かしてみるなんて、何かワクワクしますよね? 実際、下図のように、結構簡単に動かせますので、興味の沸いた方は、以下をどうぞ。 1 posted
Redmine Code Review プラグイン ダウンロード 正式公開版 開発版 使い方 レビューを書く レビューを読む Redmine Code Review プラグイン¶ Redmineのリポジトリブラウザにレビューを書き込むことができます。 レビューに返信することができます。 レビューが追加されたらメールで通知することができます。 レビューの状態(オープン中、クローズ済み)管理ができます。 登録されたレビューの一覧表示ができます。 ダウンロード¶ 正式公開版¶ http://code.google.com/p/r-labs/downloads/list 開発版¶ http://hudson.r-labs.org/hudson/job/Code%20Review%20Plugin/ 使い方¶ レビューを書く¶ リポジトリブラウザで更新情報を開き、diffをクリックする。 差分表示画
It's a bright day for code review! Still on pull requests? See why organizations upgrade to Review Board: Code review, document review, and image review, all in one place Your code and data stays private, secure, and in your control (Review Board won't mine your data for AI training or other purposes) Works with what you use today (such as Git, Mercurial, Perforce, ClearCase, Cliosoft SOS, or Azur
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く