バグの重さを定量化したら話が早い - Qiita
バグ管理にまつわる困りごと 検出したバグを報告したは良いけど、その先の判断が役割によって意見が割れることってよくありますよね！ 優先度が高いと思ってたのに、「このフェーズでは対応しない」ってなっちゃった…大丈夫かな？？ 「ユーザーさんが困るのでは」って訴えたけど、本当にそうかな？？ そもそも、QAチームで検出したこのバグ、プロジェクトにとってどの程度のインパクトになるんだろう？？ バグが溜まりすぎてどこから修正すればいいか分からない！ こうなる原因は、プロジェクトや製品にとって何が大事なのか「認識が合っていないこと」です。 もっと深掘りすると品質の曖昧さ（主観的で相対的で変化する）が要因なのですが、それはまたいずれ別の記事で（書けたら書く）。 そして、この認識を揃えるためには手間ヒマをかけたチームビルディングが必要だったりします。 ……とはいえ、いま困ってるんだよなぁ。という過去の自分にオ
ブラックボックスデバッグ
はじめに デバッグというとデバッガを使ったりprint文を挿入するのが一般的です。しかし、現実にはそういった手法を取れない環境でデバッグする必要があることもあります。 例えば私の仕事はLSIの設計ですが、製造されたLSIの動作中に内部を見ることは当然できません。もし何らかの不具合が発生した場合、内部を観測することなくデバッグする必要があります。 こういったデバッグ手法をここではブラックボックステストにならって「ブラックボックスデバッグ」と呼ぶことにします。ブラックボックスデバッグはLSI固有の技法ではありません。例えばソフトウェアでもデバッガのアタッチやprint文の挿入で状態が変わってバグが再現しなくなることはあります。また大規模なネットワークインフラのデバッグでは対象が大きすぎて、実質的に詳細を観測できないこともあるかもしれません。 このようなブラックボックスデバッグは（おそらくドメイ
マーチン・ファウラー氏の新著「リファクタリング 2nd Edition」が完成、ほぼ全面的な刷新。日本でも11月22日発売
マーチン・ファウラー氏の新著「リファクタリング 2nd Edition」が完成、ほぼ全面的な刷新。日本でも11月22日発売 マーチン・ファウラー氏が約2年を費やして執筆してきた新著「リファクタリング 2nd Edition」が完成し、日本のAmazon.comなどで予約が始まりました。発売日は11月22日と表示されています（下記の表紙画像からもAmazon.comへリンクしています。記事執筆時点でのAmazon.comでの販売価格は7279円）。 「リファクタリング」とは、ソフトウェアの機能追加や変更、性能向上などに備えるため、開発されたコードの外部に対する振る舞いは変えずに、より整理された、あるいは洗練されたコードに書き換えること、あるいはその手法のことを指します。 いまでは開発者の間で広く知られているこのリファクタリングの意義や方法論をはじめて系統的に解説し、普及に大きな貢献を果たした
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
読みやすいコードってどんなものか考えてみた -抽象化と名前重要- - tumblr
あらすじ 人の綺麗なコードを読みまくると自分のコードも綺麗になっていくのに、イケメンを見続けても僕の顔が良くならないのは何故なの?? 2012-11-30 19:41:20 via web 今まであまり人のコードを読む習慣というか機会というかがあまりなかったのですが、最近になって、デスクの上がヨドバシのiMac売り場みたいと(僕の中で)話題沸騰中の@mitukiiiさんのコードを読む事があり、この人がまたすごく綺麗でスタイリッシュなコードを書くわけで、その時に、綺麗なコードというのはこういう感じに書くものなのかと結構な衝撃を受けたわけです。 またこれも最近なのですが、別の機会で、なんと言いますか、1つの関数が数千行あったり、しかもその内の大部分が共通処理として括り出せるような恐らくはコピペされたであろう部分が大量に入っていたりまぁ不可解な部分の多い、言うなればイケメンを見続けた僕みたいな、
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blk.jp/archives/765
GitHub Flow (Japanese translation)