タグ

仕事と品質管理に関するt-murachiのブックマーク (4)

  • バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い

    バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
    t-murachi
    t-murachi 2016/05/18
    こういう現場が増えていってくれるとええな。
  • コードレビューについて - camlspotter’s blog

    このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや

    コードレビューについて - camlspotter’s blog
    t-murachi
    t-murachi 2012/08/15
    「# RV mimi: この辺要リファクタリング」「# murachi: 10年前の化石コードをいまさら…」「# mimi: 社長だろうと却下」「# murachi: ぁぃ、がんがる(;_;)/」<こんなんでよくね? >レビュワーに上下なし
  • 「ドラクエIX」発売延期の理由は 「油断していた」と和田社長

    スクウェア・エニックスの和田洋一社長は2月12日、決算会見の席で、ニンテンドーDS用ソフト「ドラゴンクエストIX 星空の守り人」の発売日を3月28日から7月11日に延期した理由について、「デバッグが間に合わなかったため」と説明した。 延期の理由を問われた和田社長は、「ドラクエは、(機能の実装が)できあがったため油断していた。傲慢(ごうまん)だったと反省している」と切り出した。 実装が済み、格的なデバッグに入った段階で「手強いバグがいくつもあることが判明した」という。バグの量は「とてもお客様に出せる状態ではない」ほど大量。「もう少しチューニングしようというレベルではなく、今出すべきでないことは明らかと判断した」 特に「ドラゴンクエストのチームとしては未開拓の通信分野」が強敵。「ゲーム全体でもまだまだバグは取り切れておらず、まして通信についてかなり掘り下げる必要があるため、十分な期間を取った

    「ドラクエIX」発売延期の理由は 「油断していた」と和田社長
    t-murachi
    t-murachi 2009/02/13
    めっさよくある話なんですが…。本当に 4ヶ月弱の延期で間に合うのかなぁ…。人死にとかでなければいいけど…。
  • プログラマが仕様を決めればいい - GoTheDistance

    最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部

    プログラマが仕様を決めればいい - GoTheDistance
    t-murachi
    t-murachi 2008/04/11
    前にも書いたけど、分担するにしても、工程で人を分けるんじゃなくて、機能単位で分担すべきなんだよね。結果として人数が増えるか減るかは知らないけど、個々人の説明責任能力は格段に上がるし。
  • 1