Redmondのバグ潰し月間 84
ストーリー by Oliver
旧知なIRCでBug-Squashing-Party 部門より
旧知なIRCでBug-Squashing-Party 部門より
yourCat 曰く、 "本家より、Goverment Computer Newsの記事によれば、Microsoftは同社のTrustworthy Computing Initiative部門において、2月末まで一切の新しいコードを書かず古いコードのバグ潰しに専念すると発表した。
「過去のバグ潰し」の機会なぞ今までにいくらでもあったと思うが、やらないよりはずっといい。普段からバグ潰しをしているはずなのでプロパガンダにも見えてしまうが、それでもバグ潰しに真剣に取り組もうという姿勢は好ましい。セキュリティーに対する取り組みも併せて、Microsoftは変わろうとしている。"
結果が楽しみだ。これを機会に開発者がこぞって休暇を取ってなければいいのだが。
1ヶ月以上IEのパッチが出ていない (スコア:3, 参考になる)
Re:1ヶ月以上IEのパッチが出ていない (スコア:2)
#セキュリティー・ホールとバグは厳密に区別されるべき、
#なんていう論説もしばしば見かけますが。
Re:1ヶ月以上IEのパッチが出ていない (スコア:1)
と発表するために、バグ溜めしているんじゃないですか?
それじゃ (スコア:1)
3日で十分。
Re:だって「仕様」でしょ? (スコア:1)
ということは、1ヵ月後、「この1ヶ月、バグつぶしに専念したが、ほんのわずかしかバグがないことが分かり、わが社の製品の優秀性が証明された。もちろん、そのわずかなバグについても、完全につぶし、今では製品の動作は完全に仕様に適合するようになった」とか言い出すかも、ってことかな。
Chinese New Year (スコア:2, おもしろおかしい)
そもそもこの期間に新しいコードは書けない。なので設定した。
…というのは邪推しすぎか?
わははは (^O^) (スコア:1)
#しかしアメリカの中国系のヒトって、元気ね。
ソルトレイクオリンピック Re:Chinese New Year (スコア:1)
char *A;
モータースポーツ部 [slashdot.jp]
バグ潰し (スコア:2, 興味深い)
・1ステップ操作する度に確認ウインドウが開く
・毎度責任がない事を使えるメッセージがでる。
この修正では?
または
・バグを潰すのではなくライバルの製品がある事が原因と考えよからぬ事を真剣に考えている。
・バグは当たり前と思わせれば修正できなかったとしても文句はないと思っている。
・実はマイクロソフトを止めたい
・パソコン画面に向かってバグを見ているだけで修正しない<新しいコード書かない為
当然サイトの更新も止まる。↑3月から修正が始まり、4月に別製品として発売される。(笑)
Re:バグ潰し (スコア:1)
で、XPSEプリインストールマシンが店頭に並ぶと同時に98SE以前のFIX提供が繰り上げ停止。
# こいつは売れるでしょうね。
open source野郎は日常茶飯事なのに (スコア:2, すばらしい洞察)
というか、しらずしらずのウチに/.でMicrosoftを宣伝していることに気付いてくれと言いたい。
Re:open source野郎は日常茶飯事なのに (スコア:1)
M$の宣伝戦略かも? (スコア:1)
ダラダラしてて、普段まともにコードなんて書いてないんですよ」ということを
印象づけるための戦略かも知れませんね。
「コード書きません!」って訴えるということは「それ以外の期間はマジメにやってます!」
っていうことになるじゃないですか!
信者のヒトはなおさら感心するでしょうよ、ったくもー。
とあるOpen Sourceなコード書きの例 (スコア:1)
自分の場合ですが、コードを書くのは1晩でできます。問題は、それをやることが正しいのかを確かめることです。この作業は例えば1週間、あるいは1カ月という単位でかかります。私が最近やった、pgrpおよびsessionの細粒度lockでは、同時に取りに行くlockの数を少しでも減らすため、lockの順序を3回変更しました。これで値を変更しない場合はlockが1つだけで済んでいます。
元記事も読んでみましたが、あくまでコードをさらうといっているだけで、その背後にある仕様やロジックに踏み込むとはいっていませんね。仕様書が与えられるだけの末端のプログラマに「仕様書を頭から信じて書け」というだけで1カ月終わる可能性もあります。
Re:open source野郎は日常茶飯事なのに (スコア:1)
それを言っちゃったら、一切のアンチ系意見は事実上発言不能に陥るんですけど?
#それでも別に構わないというなら(以下同文
うーむ。けなしたことが宣伝になるというならば、
どんな罵詈雑言をならべても名誉棄損で訴えられないような世の中に、なってほしいかも(笑)
デバッグと言う名の… (スコア:2, おもしろおかしい)
これはバグを取るための期間じゃなくて、
バグを見付けては仕様に加えていくための期間なんだ!
本音はBugレポートのバックログの解消? (スコア:2, すばらしい洞察)
セキュリティ問題と合わせてまとめて処理したいということじゃ
ないかな
この発表によって (スコア:1, おもしろおかしい)
2.仕方なく方針を急遽変更して、またもとの体制に戻る。
3.中途半端で終わったため、またバグが増える。
4.使用者の怒りを買う。
5.また会社の信頼が下がり、株価が下がる。
6.仕方はく、「バグつぶし月間」を復活する。
7.「1.」に戻る。
世にも恐ろしい「株価下落スパイラル(ただし1社のみ)」の始まり、始まりぃー!。
Code Complete という名の本を思い出しました (スコア:1)
そういう自社スタッフが書いた本を読み直す月間かもしれませんよ。
McConnellの書いた本を時代順に並べてみると
1994 Code Complete : A Practical Handbook of Software Construction
1996 Rapid Development : Taming Wild Software Schedules
1997 Software Project Survival Guide
1999 After the Gold Rush : Creating a True Profession of Software Engineering
他のマイクロソフトのコーディング本の著者たちもだんだん、
プロジェクトマネジメントに移行したようですね。
昇進して仕事が変わったのかもしれませんけど、みんなで
バグを出さないコードの書き方も忘れていったのかしら。。。。
Re:Code Complete という名の本を思い出しました (スコア:1)
Writing Solid Code や Code Complete は読みました。
至極真っ当なことが書かれていて、駆け出しCプログラマだった当時の私にはなかなか参考になった記憶があります。
Windows版 Excel を Mac に移植しようとした時の苦労話が印象的。
個人的には、この三冊が発売された1994年~95年頃の Microsoft が、私の中での黄金期でしたね……
ダイエットの本を書いている人が必ずしもダイエットに成功している訳ではない、ということですか?
Re:この発表によって (スコア:1)
「変わろうとしている」のは本当か? (スコア:1, 興味深い)
会社という集団ですから、実際の実務は一人一人は独立した人間のすること。
そんなことやってられるか?と現場が思うほど士気が下がっていたり、トップにカリスマや信頼がなかったり、もう会社やめちゃおーかなー、なんて思ったりしている人がたくさんたくさんいる場合は、そうコトは簡単には運ばないはず。
経営者の考えていることが、そのまま部下に伝わる、なんてことはそもそもありえないしね。
指揮官の掛け声の後に、指揮官が後ろ(見方)から撃たれる、なんてのは、本当によくあるハナシだからね。
このトップの発表を聞いて、現場では「もう、会社やめたほうが身のためだね」と思った、というか、その意志を固めた人がとても多そうですね。
別の筋からの情報によれば、同社がどうなかった後、エンロンのような問題が出てこなければいいですけどね。心配だなぁ(楽しみだなぁ)。
本家では (スコア:1)
方針転換してきたのがM$ (スコア:1, 興味深い)
あくどいことしてでも、
方針転換してきたのがM$
なんじゃないでしょうか?
それで、2,3度失敗しながらも
最後には自分のものにしてこれたのが
経営としてすごい。
と私は思います。
Re:方針転換してきたのがM$ (スコア:1)
生き残れれば、勝ちなのだな。
そうですよね (スコア:1)
それを可能にしたのは間違いなく「お金」の力なわけで。
#しかしM$ネタは毎度ヒートアップしますねぇ。
Re:方針転換してきたのがM$ (スコア:1, 興味深い)
>手っとり早く儲けるためなら、
>どんなあくどいことでも
>平気でやる
とか言い切れるところもスゴイけど。;-)
M$製品だけにバグがあるんでしょうかねー?ORACLEなんてバグだらけだと思うんですけど、
ついぞ「バグ直しに命かけてます!」なんてエリソンの口から出たことないよ?
8.0.xで修正されたバグが8.1.xで再発したりね。
要するに、宣言しようとしまいと、世の中の大多数のベンダーは真剣にバグフィックスなんかしてません、ってことかと。
Re:方針転換してきたのがM$ (スコア:1)
そうかなあ?
どっちかというとMSのありようは、
実力より人気!の、アイドルみたいな感じ
だったような気がする。
「いつかは彼らも成長して大人になるのさ」
という発想が有りえないとは言いきれないものの、
「それにしては遅い成長だね」くらいのことは俺でも思う。
一ヶ月では、生ぬるい (スコア:1)
あくまで、想像ですが… (スコア:1)
1.おい、市場から「貴社の製品はバグが多くって困るよ」という苦情が多くなってきててやばいよ
2.じゃあ、バグ潰しのために人を割り当てないとなりませんね
3.今出ているバグリストはこれだから、大体近い分野のことをやっている開発者に割り当ててしまおう
4. 割り当てられたほうは、こんな部分のことなんて知らない!と思って慌てる
5. その部分の挙動を理解するのに1ヵ月くらいかかる
6. はい、タイムアップ!
ということになっちゃうんじゃないかなと…。人月でしかものごとを見ることができないとこういうことは平気で起こりますよ。私の今の職場も似たようなものですしね。その問題のfix担当者に割り当てられてから1年くらいかけてようやくバグが分かって直したというのに、お客さんのほうのビジネスの状況が変わっていてもうそのfix はいらない、なんて言われることもしばしばです。
初歩的な質問なんですが (スコア:1)
一日に一人何行の割り当てで、何人が作業しているんでしょうか?
今までのバグ報告の整理だって、一ヶ月じゃ無理だと思ってしまうんですが、どなたか納得できる情報を教えてください。
Re:初歩的な質問なんですが (スコア:1)
Re:初歩的な質問なんですが (スコア:1)
マジっすか... でも、辻褄合わせまでしなくても、他の人に知られないようにするだけで十分隠せてしまうのではないでしょうか。縛りまであるなら、わざわざ自己申告する人はいませんよね?
で、そういう人達がそのうち転職すると、残った人達は実情を知らないので大変なことになると。
経験的大規模開発のコツ (スコア:2, 参考になる)
あと、多分Microsoftの中でも何らかのバージョン管理ツール(SourceSafeかどうかは知りません)を使っているでしょう。そのcommit logがどうなっているかは興味ありますね。みんなrelease前ならドサクサ紛れでなんとかなると思っていて、大量に駆け込みがあったりして。
bugに関しては、入れた人にツッコミを入れるよりも発見した人が率先して直してしまう方が経験的には効果があります。そもそもケンカしている余裕はない(その間何も生産できない)し、後者の方がbugが入ってしまった部分について正しく理解する人が増える(部分的なペアプログラミング?)わけですから。ただ、sourceをとことん隠す(企業全体から個々の開発者まで)ことを善とする人達にはなかなかわかってもらえないかなぁ...
みんな有言不実行を心配しているけど (スコア:1)
Re:みんな有言不実行を心配しているけど (スコア:1)
というか、XPだけじゃなく、2000のSP3やNT4のSP7なんかも位置から見直したらその規模になるんじゃないの?
コードフィックスと言う概念 (スコア:1)
確かにVSS使ってますが、いつまでたっても機能追加できてしまうエンドレス管理システムだったりする。
結局、MSの製品のバージョンって「見栄えの違い」以外認識できない気がする今日この頃です。
Windowsだって、結局いろんな機能拡張が出てきてWindows95でも、
WindowsXPでも似たような事ができてしまって何が違うのかよく分らない。IEもバージョン変わってこんなに違うって余り思えない・・
#まぁ、WindowsもIEもヘビーユーザじゃないからかもしれませんけど。
「WindowsXPの仕様はこうだ!」って決まっていてそれを守りつつ、セキュリティパッチを出すと言うことはもうないんだろうか?
職業としてのプログラマ
Visual SourceSafe 6.0を見てみたけど (スコア:2, 興味深い)
Visual SourceSafeの機能 [microsoft.com]を簡単に調べてみましたが...
...これじゃ、rcsよりひどくないですか? (rcsにもbranchはある) 並行開発が全く不可能です。どちらかというとdaily buildを重視した作りになっているようですが、そんなのは後付けでどうにでもなる(人になり代わって機械がcheckoutすれば十分)のに。 (こういう作りでいざと言う時に全く役立たずだったシステムを私は聞いたことがある)
Re:Visual SourceSafe 6.0を見てみたけど (スコア:1)
これは嘘でしょう.(ココ [microsoft.com])
実際,会社で使っていますが,分岐はできます.
ただ,その機能を使ったことはありません.
# 他のプロジェクトでは,分岐を使用しています.
そもそも,VSSは非常に使いにくいので,使い続けたくはありません.
ファイルが消えたりとか,バックアップするには,どのファイルを取っておけば良いのか(レジストリも必要なのか?)とか,不安な要素も他にあります.
VSSを使えば使うほど,MS社以外の生産性を落とさせるための陰謀じゃないかと,疑いたくなります.
Re:Visual SourceSafe 6.0を見てみたけど (スコア:1)
>ファイルが消えたりとか,バックアップするには,どのファイルを取っておけば良いのか(レジストリも必要なのか?)とか,不安な要素も他にあります.
わしも会社で試したことがあり、ファイルが消えたり
はしませんでしたが、何故か更新したはずのファイルが
古い状態になったことがありました。それ以来恐ろしくて
もう使えません。
#NT用のVCを手に入れるには、何故かIntel用
#エンタープライズ版が必要なのが縁でVSSが手元にあるっす。
BURRN!
やっぱり分岐はダメ (スコア:1)
>実際,会社で使っていますが,分岐はできます.
今仕事で使っていて, 分岐が使えるなら使いたいのですが, VSSで言うところの分岐は実際の作業では全く役に立たないことが分かりました. 最も大きな違いは, CVS等では分岐後にも幹と枝の間に関連性が維持されますが, VSSでは分岐によって完全に独立したプロジェクトとなってしまうことです.
これは次のようなシチュエーションを考えてみれば致命的に近い欠点であることが分かります
この時, VSSでは全てのbranchが独立したプロジェクトであるため個別に修正したソースの登録を人手でしなければならず, 作業ミスによるバージョン不一致が生じる可能性が高いです. さらに変更部分のマージチェックも有りませんので, branch独自の修正部分を重ね書きで潰してしまい, degradeを起こすという可能性も高くなります.
以上の欠点から, VSSを
の様な用途で使用するのは不適切であると結論付けられます
Re:Visual SourceSafe 6.0を見てみたけど (スコア:1)
というか、たしか、デフォ設定がロック型管理になっているというだけだったような記憶が。
ただ、共同所有について開眼(笑)していない人、つまり
そのメリットを知らず、デメリット(というか憶測にもとづく恐怖?)ばかりを信じて
いる人々にとっては、ロックがかからない管理方法ってのは
本能的(笑)に怖くなるようですね。
コードを書いたひとが後々のデバッグのセキニン(笑)まで負う、
などという呑気なモデルを未だに採用してるトコロには、
VSSは似合いのツールなんじゃないかな :-P
ていうか、良い説得台詞を教えてください(T_T)
実際にはファイルをロックしても「他のファイルとの関連」をロックできるわけじゃないんで
ロックなんて徒労なんだけども、それを理解してもらうのは至難ですぅ…
でもまあ、大人数(大企業にせよオープンソースにせよ)でナイ場合には、
大勢のひとが同時にチェックアウトできないことのデメリットは
あまり際立たないですけどね。隣人に一声かけるほうが早い(^^;
ところでVSSは、MSのソフトとは思えないほど(笑)比較的使いごこちは良いと思います。
あくまで比較的です。wordやexcelのような、何年たっても慣れられない
変な操作性は、あんまり無いです。
Re:Visual SourceSafe 6.0を見てみたけど (スコア:1)
checkoutされたfileをlockすることのデメリットとしては、CVS tutorial [sra.co.jp]のOHP [sra.co.jp]「衝突回避の一つのアイデア [sra.co.jp]」に挙がっています。一番つらいのは、fileを見るだけでもcheckoutするはめになること。見るだけならup-to-dateなものが必要とは限らないため、lockはするだけ無駄(どうせ変更は加えられない)です。
複数fileのlock(CVSの場合commitの禁止)はCVSROOT/availでしょうね。最も、きちんとmoduleを管理していないと使いものになりませんが、これは何を使っても同じか...
人数および配置とツール (スコア:1)
これと、remote accessができないということを考えると、開発者を全員1つの部屋に閉じ込められるならSourceSafeでも何とか使えるんでしょうかね。商用のツールでもperforce [perforce.com]のようにremote accessができるものがある(bkもそうらしい)ので、使い方に気が付いていないだけの問題でしょう。
人数はあまり関係ないのでは? 私が関わってることなんか、USに数名、ヨーロッパに数名、日本に1名(あっし)って状態ですから。
2月? (スコア:1)
ゆーへん
さーん個潰して五個作るー(Re:逆に (スコア:1)
『365日のマーチ』の替歌が浮かんだひと、一歩前へっ。
昔々... (スコア:1)
ほとんどのメンバがただの寄せ集めだったのだが、一人張り切ってる奴がいて、こいつが他の奴が帰った後に泊り込んでソースをいじりまくる。
これが、正しいんならともかく、すっげーバグだらけで、翌日の前半は復旧作業しかできんかった。
こーゆープロジェクトだから管理者もまともに管理してなくて、自衛のために自分の担当分は持って帰ってたよ。
そいつに全く技術力がないってわけでもなく、「自分のプログラムとの釣り合い」で直す。
だから、一見正しそうな修正に見えるから厄介。
特に問題なのは、単体では整合性が取れていても、全体では不整合になるってやつ。
品質向上とかバグの洗い出しってのは全体のバランスを壊す危険性があるから、大勢で時間をかけてやんないとただの「破壊活動」だと思うぞ。
Re:単に売れてないだけでは (スコア:1)
「セガガガ」 [segagaga.com]を超えるイタいソフトとして評判になりそう・・・
ゲームはかなり優秀なMSですからね。
本気でシミュレーションしたら、
まじめにバグ修正月間を続けていたら潰れてしまう、
ゆえに今までの方針が正しいのだ、
なんてことになるのかも。
攻略本に (スコア:1)
バグを減らすのも重要ですが
あまり時間を掛け過ぎると
大切な商機を逃してしまいます。
新製品は早め早めのリリースを心がけましょう。
バグは後でも修正できます。
と書かれたりして(笑)
#バグが裏技といわれた時代が懐かしい
Re:なんでもいいけど (スコア:1)
http://www.office.ac/tearoom/noframe.cgi [office.ac]