GitHubと連係して動作するコードレビューツール「ReviewNinja」。あの欧SAPがオープンソースで開発中。しかもMEANスタック使用
GitHubと連係するコードレビューツール「ReviewNinja」がGitHub上で公開されています。開発しているのは欧SAP。あの業務アプリケーションで知られるSAPです。 Review Ninjaはまだ開発の初期にあるようですが、GitHub上で次のように解説されています。 ReviewNinja is a lightweight code review tool that works with GitHub, providing a more structured way to use pull requests for code review. ReviewNinjaは軽量なコードレビューツールで、GitHubと連係しています。これはコードレビューの場面でプルリクエストを用いてより構造的な方法を提供するものです。 （一部省略） ReviewNinja defines a clea
コードレビューについて : 小野和俊のブログ
伊藤直也さんが「些末なコードレビュー」というエントリを書いて話題になっている。このエントリで伊藤さんはコードレビューの話と、はてなのJavaScriptの話と2つの話題に触れている。前者のコードレビューについてはアプレッソでは8年ほど前から「コードレビューを通っていないコードはコミット不可」というルールですべてのソースコードに対してコードレビューを必須にしてきた関係で私も思うところがあるので、エントリを書いてみようと思う。 伊藤さんが例示しているように、インデントやreturnの省略などの話は好みの問題であり、議論してもソフトウェアの改善につながらない。なのでコードレビューでこうした宗教論争が起こるようなら、コーディング規約を見直すべきだ。「無駄に悩んだり議論したりすることを減らす」ことはコーディング規約の主たる効果のひとつだと言える。 コードレビューに慣れないチームが、何の考えもナシにコ
レビューでの欠陥検出シナリオ：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェアレビューにおいて、検出すべき欠陥を明確にした上で、欠陥検出をするとレビューアの責任分担や完了基準が明確になると考えています。これまで拙著「間違いだらけの設計レビュー」や日経SYSTEMSの連載、講演やセミナーにおいてもその話を伝えており、有効性に関して一定の反響をいただいています。また、検出すべき欠陥の見つけ方を検出シナリオとしてまとめておき、レビューの開始前に合意しておくことをお勧めしています。 検出すべき欠陥やシナリオはソフトウェアに求められる機能や提供する価値、開発チームの構成や体制にも依存するため、「どのようなソフトウェア、プロジェクトにおいてもこれを検出すればよい」というものはありません。抽象的ですが、そのソフトウェア、プロジェクトにおいてもっとも検出の価値が高いものになります。価値は得られるメリットのことで、たとえば、ソフトウェアの利用者の利便性が高まる、レビューで
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
コードレビューのポイント
すこし古いけどこちらを読んだ。 pull request を利用した開発ワークフロー // Speaker Deck 非常にわかりやすく読ませてもらったが、本筋とはちょっとずれるレビューの勘所の話がとても面白く参考になった。 レビューコメントにラベルをつける [MUST] 問題があり、必ず治す [IMO] 意見、緩やかな指摘。自分ならこう書くけどどう? [nits] ほんの小さな指摘。インデントやタイポ たしかに普段のコードレビューでも、特に意識せずこれらは使い分けていた。こうしてラベルとして明示することでレビュイーに意図が伝わりやすい。レビュアーもこうした観点からレビューを行える。なによりレビュアー・レビュイー双方にとって明確に、指摘事項に優先順位がつけられる。こうすることでレビューとその後のアクションをよりスムーズにすすめる手助けになっている。 いいレビューとだめなレビューというものは
ソフトウェアレビューの効果を高める秘訣2つ：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
仕事柄、多くの方に「ソフトウェアレビューがうまくいかない。どうしたものか」という相談をいただきます。多くの場合、レビューの目的設定が不十分、参加者のマインドが醸成されていないことが原因になっています。 レビューの目的設定が明確にされていないことは多く、レビュー会議がはじまっていくつか欠陥が指摘されると「このレビューって結局どんな欠陥を検出すればいいんだっけ？」という状況になることは少なくありません。各々のレビューアが自身の経験に基づいて欠陥を指摘すると、必ずしも開発しているソフトウェアに求められるような（早期検出すべき）欠陥ばかりになるとは限りません。たとえば、ユーザ数が5ユーザ程度しかおらず、同時アクセスの可能性がほとんどないシステムに対して、同時アクセスやそのときの性能問題を指摘することは、必ずしも適切とは限りません。それよりも指摘すべき（優先順位の高い）欠陥があることが多いからです。
汎用的な観点ではなく業務特化の観点でのレビュー実施の効果を予想した研究：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
2013/3/12に「業務観点でのレビューを目指した不具合情報の分析」というタイトルで情報処理学会ソフトウェア工学研究会で発表しました。論文PDFはこちら。（本著作物の著作権は情報処理学会に帰属します。本著作物は著作権者である情報処理学会の許可のもとに掲載するものです。ご利用に当たっては「著作権法」ならびに「情報処理学会倫理綱領」に従うことをお願いいたします。） レビューのコスト削減効果は、レビューで検出して欠陥を修正したときのコストとレビューで見逃して（あるいはレビューを実施せず）レビュー以降のフェーズで欠陥を検出し、修正したときのコストの差です。@IT情報システムマネジメントの記事「レビューを「数」だけで管理しているからコストが膨らむ」で解説しています。 レビューで検出することによってコスト削減につながる欠陥をつきつめると、どのようなものになるでしょうか。おそらく対象ソフトウェアにとっ
ソースコード変更波及解析の8カテゴリ - どのくらいご存知ですか？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
変更波及解析は既存のソフトウェアに変更を加えたら、どの場所に影響を与えるかを調べる方法です。影響は本来の意図であるものや本来意図していない副作用も含みます。変更波及解析が不十分だとデグレードする場合があります。 Steffen Lehnert氏のA Review of Software Change Impact Analysisという文献調査をしたテクニカルレポートがここで公開されています。調査対象の文献が182件ある大きめの調査です。網羅性や調査方法に関しても客観的な基準を与え、洗練した上で論文として公開されるのかもしれません。 このテクニカルレポートで紹介されている影響波及解析のカテゴリの一覧は以下のとおりです。10カテゴリのうち9番目は組合せ、10番目は「その他」なので、実質的には8カテゴリあります。どのくらいのカテゴリをご存知ですか？ いずれも完璧とはいかないまでも、変更波及解析
コードレビューやテストの優先順位付けに統計モデルが役立つか実際に試してみた論文：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
プログラムの規模が大きくなるとソースコードレビューやシステムテストをどこからはじめてよいか優先順位が付けにくくなります。優先順位は様々です。たとえば、欠陥を見逃した場合にリスクが大きくなるところからはじめる、多くのユーザが使う基本機能の正常動作からはじめる、依存関係が多く様々な部分から参照される共通モジュールからはじめる、今後も長期にわたって保守、拡張する部分からはじめるといった方針が考えられます。もちろん、できた部分から順番にという順位付けもあるでしょう。 優先順位のつけ方の一つとして、ソースコードの特徴から不具合がありそうなクラス、モジュール、メソッド、関数を予測する技法としてFault-proneモジュール予測という技法があります。過去の不具合のデータとソースコードの特徴を表わす数値をモデルに与え、不具合が起こりやすいソースコードの特徴を学習させます。数値は関数、メソッド、クラスとい
コードレビューツール 6選 どれが最適？ | Act as Professional - hiroki.jp by HIROCASTER
Pythonで書かれたレビューツールです。VMware社内で利用されていることで有名なツールです。 プレコミットレビューという概念のレビューツールです。つまり、コミット前にレビューをするという事が前提になっているツールです。よって、結果的に差分を重点的に確認していくツールのつくりになっています。 rietveld rietveld – Code Review, hosted on Google App Engine – Google Project Hosting Google社内で使われているコードレビューツールである「Mondrian」のオープンソース版です。基本的にGoogle App Engineで動くことが前提になっています。 GAEの上のコードのデータを置くということがオトナの事情的に難しいかもしれませんが、検討してみてください。 Phabricator Phabricator
検証II 定量的な観点絞り込みの効果
検証IIでは、定量的にレビューの観点を決めることのコスト効果を測定した。東芝デジタルメディアエンジニアリングの協力を得て、映像や音声などのデータ処理ソフト（Xとする）の開発プロジェクトにおける内部設計書をレビュー対象とした。このプロジェクトでは、開発済みのソフト（Yとする）を派生させてソフトXを開発する。 検証は、定量的に観点を決めることから始めた。その際、ソフトXの元になったソフトYの新規開発・派生開発プロジェクトにおけるテストの不具合管理票350件を、実績データと見立てて用いた。不具合管理票は「サブシステムカテゴリー」「開発担当者」「原因種別」「検査種別（テスト種別）」といった属性項目を備えているほか、「不具合の内容」、発生した「修正工数」などが記録されている。 この実績データを基に、数個の観点を設定する。そのために属性項目に着目した。属性項目ごとの、不具合の出現頻度（全不具合の何％が
本質的でないレビュー指摘を減らすための試行を紹介した日経ITproの記事：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
要求ドキュメントや設計ドキュメントをレビューにおいて、誤字脱字の指摘の割合が高く本質的な欠陥の指摘が少ないというのは、どのような組織、プロジェクト、チームにおいても共通の悩みでしょう。 そのようなレビューを改善することを目的として、レビューで検出すべき欠陥の条件を変えて実務者の方にご協力いただいて検出結果を比較する試行をしました。 結果は論文で報告しています（S. Morisaki Y. Kamei K. Matsumoto: Experimental Evaluation of Effect of Specifying a Focused Defect Type in Software Inspection: PDFはこちらから）。ほぼ同じ内容の記事を以前に日経SYSTEMS（雑誌）に寄稿していました。昨日Web記事として日経ITproのサイトにも掲載いただきました。こちらから読めます。
コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
BBIQ光の口コミや評判｜料金や速度など九州エリア限定のビビックを解説 – ネットログ
この記事では、実際のBBIQ光ユーザーの口コミ・評判を調査し、BBIQ光のメリット・デメリットをまとめました！ 「BBIQ光に契約して本当に大丈夫？」「BBIQ光はちゃんと繋がるの？」など、心配な方もいるでしょう。 BBIQ光は、九州電力グループの子会社株式会社QTnetが提供する光回線サービスです。九州地方限定で展開しているため通信速度が混雑しにくく、安定した高速回線が維持しやすい光回線です。 一方で、料金は平均でそこまで安いわけではなく、営業電話のスタッフの対応が悪いなどのデメリットがあります。 BBIQ光のメリット・デメリットを踏まえて、契約を検討してみてくださいね。おすすめのキャンペーンも紹介しているので、ぜひチェックしてみてください。 それではさっそく読んでいきましょう！
Scrum ではコードレビューをどうやっているか？ - haradakiro's blog
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象
目的を設定して検出のたびに確認するとレビューの結果が安定することを検証（若干堅苦しくなることも確認）：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
2011年8月に私の研究グループの論文で確かめた内容です。32人のソフトウェア開発の実務者の方に協力いただきました。5, 6人で1班を作り、全部で6班で目的設定のしかたが異なる3つのグループを作りました（1グループあたり2班）。それぞれのグループは以下のとおりです。特定の班に経験年数の高いエンジニアや相対的にスキルの高いエンジニアがかたまらないようにしました。 目的設定をしないグループ（1, 2班） レビュー開始前に目的設定をしてその目的に沿って欠陥を検出するグループ（3, 4班） 開始前に目的設定をし、欠陥を検出するたびに目的に沿っているかを確認しながら検出するグループ（5, 6班） ここでの目的設定は「どのような欠陥を検出すべきか」という欠陥種別の設定です。3～6班の目的設定はレビュー対象に合わせて各班で相談して決めていただきました。レビュー対象はWebブラウザをクライアントとする架空
レビュー改善に関する産学連携の取組みで受賞：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェアプロセス改善カンファレンス2011で細谷，吉岡，森崎「産学連携によるデザインレビューの改善事例」が実行委員長賞を受賞しました。発表は細谷氏（三菱電機）。アブストラクト、発表スライド、発表とも細谷氏が中心に実施くださいました。発表スライドはここ(ソフトウェアプロセス改善カンファレンス2011のサイト)で公開されています。 社内で使うレビューのガイドライン作成をご一緒しました。プロジェクトにあわせて選択しながら使えるようなガイドライン作成を目指しました。細谷氏、吉岡氏とも社内のプロジェクトをよくご覧になっていて、プロジェクト全体の特徴や傾向を踏まえた上で検討できました。 公開資料にも掲載されています検討結果の1つをここで紹介します。ガイドラインでは、ウォータフォール開発でのレビューを工程完了間際だけでなく、工程の早い段階、途中の段階でも実施するための方法を紹介しています。ただし同じ
漏れ、誤り、曖昧さを制約とする defect-based reading：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
レビューが難しい理由の1つは自由度が高いことだと思っています。何でも自由にやれるから問題ないよねと思ってしまいがちですが、自由度が高いことは必ずしもいいことばかりではありません。本エントリのタイトルは3種類の着眼点を制約とすることにより、自由度を少し制限してレビューアが立ち戻ったり現在の状況を顧みることで、結果として網羅的な欠陥の発見につなげようというものです。 「漏れ、誤り、曖昧さ」は本エントリ末尾の論文に読み進め方のシナリオとして記載されています。後にDefect-based readingと呼ばれるようになった手法です。3つについて細かくみていきます。私のお勧めは1. 漏れ、2. 誤り、3. 曖昧さの順で計3回レビュー対象をみるやり方です。 漏れ 本来書かれているべきものでありながら書かれていないものです。追加機能があるのに削除機能がない等です。 誤り 外部の定義または内部の定義との
Google製のGit用ソースコードレビューシステム·Gerrit MOONGIFT
ソースコードのレビューはシステムの品質を高めるのに大切な作業だ。GoogleやVMWareでも使われており、ブラウザを使って差分を確認してコメントができるようになっている。社内向けには拙作のSubversionソースコードレビューシステムの宍道湖がある（Rails製）。 Git向けソースコードレビューシステム この手のツールはSubversion向けのものが多かったが、Gitでも使いたいならGerritに挑戦してみよう。 今回紹介するオープンソース・ソフトウェアはGerrit、Git向けソースコードレビューシステムだ。 GerritはGoogleが大々的に発表している訳ではないが、Google社員が開発しておりAndroidのオープンソースプロジェクトにおけるソースコードレビューにも利用されている。他のシステム同様に差分を見て、そこにコメントすることが可能だ。 差分を見てコメントする 差分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー: 森崎修司 (著), 日経SYSTEMS (編集): 本
