GoogleやMixiのように “全てのコードがレビューされていないとリリースできない” みたいな体制は(大変なので)できてないんですが、 “問題があるときだけレビュー” って何か嫌だな、というか “見てますよ!良いと思ってるから無反応なんですよ!” っていうのはこっちの都合の良い話で書いた方には伝わらないと思ったので、良いと思ったところに、 「nice.」 とだけ書く活動を始めました。
GoogleやMixiのように “全てのコードがレビューされていないとリリースできない” みたいな体制は(大変なので)できてないんですが、 “問題があるときだけレビュー” って何か嫌だな、というか “見てますよ!良いと思ってるから無反応なんですよ!” っていうのはこっちの都合の良い話で書いた方には伝わらないと思ったので、良いと思ったところに、 「nice.」 とだけ書く活動を始めました。
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をクリックする。 差分表示画
Python の親玉である Guido Van Rossum が, Google での初仕事(?) として Mondorian というコード・レビュー用ウェブアプリを 作ったよ, という話. ミーハー的に視聴. 前半はレビューとは何か, なぜそれが必要なのか, OSS でのレビューなどについて説明し, 後半から Mondrian 以前の Google 社内でのレビュー体制とその問題点を指摘, Mondrian の話と続く. Google では SCM に Perforce を使っており, レビューは patch + メールベース. Mondrian 以前は Perforce の CL クライアントをラップする g4 というスクリプトを使ってレビューを支援していた. これを使うと patch をメールでレビュアに飛ばしたりできる. その飛ばしたメールを起点にレビュアとレビュイが議論し, "l
「ウォークスルー」と「インスペクション」は,システム開発の早い段階で欠陥を発見・除去するための方法である。開発者自身やチーム内の「モデレータ」と呼ばれる調整役が自主的に運営することが特徴だ。今回は,品質向上に欠かせないウォークスルーとインスペクションの具体的な実施手順を解説する。 布川 薫/日本IBM 前回は,プロジェクト遂行段階における品質のトラッキング方法(品質保証活動)の概要を説明した。今回は,システム開発において最もポピュラーで効果的な品質保証活動の1つである「ウォークスルー」と「インスペクション」の進め方を,読者が今からすぐにでも実行できるよう,具体的に説明しよう。 欠陥の発見が遅れれば遅れるほど,修正作業の手間がいたずらに増えることは,この連載でも再三強調してきた。肝心なのは,設計・開発の初期段階から,頻繁に欠陥の発見・除去活動を行い,テストの段階までに持ち越される欠陥を最少限
変革の時代を迎えたソフトウェア産業 -開発の手戻りをしないために- ウォークスルーとインスペクション 日本アイ・ビー・エム株式会社 布川 薫 ウォークスルー(Walkthrough ) とインスペクション(Inspection )は、 欠陥の早期発見と除去を目的に、作 業工程そのものに組込まれる組織的 で効率よい検査・点検の方法である。 その狙いは、開発要員が欠陥を含 んだ成果物を作ることを未然に防止 することにある。発見/除去の対象 となる欠陥には、次のようなものが ある。 ・要件や仕様、コードやデータの矛 盾・不整合、欠落、重複、曖昧 さ・わかりにくさ ・技術面/コスト面/期間面での実 現性のなさ ・範囲外の要件・仕様、優先順位の 観点からのコントロールの欠如 ・キャパシティ/パフォーマンスの 観点からの問題 ウォークスルーやインスペクショ ンを実施することで、要件定義や設 計段階・作
Part5では,基本設計フェーズにおける成果物の品質を向上させる施策について解説する。カギは,欠陥を除去するとともに欠陥を防止する仕組みを確立すること。重要な成果物については有識者を交えて「インスペクション」を実施することも大切だ。 「考慮していない外部システムとの連携が詳細設計で見つかった」,「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても,その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し,進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。 そこでPart5では,基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「欠陥防止」を徹底する 改めて言うまでもないが,基本設計の成果物の品質を向上させるプロセスは,(1)設計作業を実施する,(2)成果物をレビューして欠陥を洗い出す,(3)
コンピュータサイエンス系の人たちの間では、サーチのテクノロジーで人気があるのはリリバンシー、次はバーティカルサーチ。 他の要素としては、クローリングとインデキシング、クラウド系というところらしい。 サーバをグリッド化(やや死語だな)して、、みたいなのは、コンピュータサイエンスというよりはエンジニアリング。 昔、シックスアパートの某Perlギークの人と話をしたとき、「自分はエンジニアリング系じゃないんで、、」と言っていた。そのときはエンジニアリングという言葉の定義がよくわからなかったけど、なんとなくわかってきたかも。 あ、全文検索とかマイニングとかも面白いといっていた。まあこれは要素技術だけど。Luceneを作った人が別で作ってる奴が結構良いって。なんだろ。SolrかHadoopか。 あと、エンタープライズサーチ。例えばメール。誰がどんな単語を多用しているかをサマリーしたり、検索させたり。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く