2008-12-09
プログラマの格言
ぼくはぷろぐらまじゃないけれど
素晴らしい
http://www2.biglobe.ne.jp/~oni_page/other/etc/pr03.html
一日は24時間ある。
今日中という意味は明日の朝までという意味である。
プログラムは思った通りに動かない。書いた通りに動く。
要求仕様はプログラム完成後に完結する。
基本仕様は完成品を顧客が見てから決定される。
詳細仕様は使用者がプログラムを動かしてから固まる。
私は、ソフトウェア設計には 二つの方法があるという結論に達した。
一つは、欠陥がないことが明らかなほど単純にする方法である。
もう一つは、明らかな欠陥がないほど複雑にする方法である。
C.A.R.Hoare
コードは開発現場で書くんじゃない! 納品先で書くんだ!
デバグは納期前にするんじゃない! 運用後にするんだ!!
画面は青かった 。
(通信用語の基礎知識 より)
「無理です!」は言ったもん勝ち
文句があるならお前がやれ
プログラマー殺すに刃物はいらぬ、仕様を三回変えれば良い
まず、他人を疑え、疑われた人が解決してくれるかもしれない。
(注 「まず自分を疑え」の方が一般的)
開発に終わりはない。リリースがあるだけだ。
仕様確定がどんなに遅れても納期は変わらない。
これを「納期不変の法則」という。
顧客は水と仕様追加はタダだと思ってる。
金払いの悪い客ほど口うるさい。
開発スケジュールは小学生でもできる算数を無視して作られる。
営業とは1+1が2であることを理解できない人の集まりである。
一人倒れればみんな倒れる。
バグは夜更け過ぎに仕様に変わるだろう。
良い仕様は一人の天才よりも三人の凡人を求める。
悪い仕様は百人の凡人よりも一人の天才を求める。
オーダーメイドのソフト料金の30%は仕様の確認に当てられる。
30%は仕様の変更のためである。
30%はバグの検出のためにある。
初期仕様による作成に関わる料金の割合は結果として10%しか残されていない。
顧客にとってSEは部下であり、プログラマーは家畜である。
SEにとって顧客は金であり、プログラマーにとって顧客は姿の見えない悪性のウィルスである。
駆除はPGを完成させる以外には困難である。
顧客がSEに好かれる方法は、システム開発には時間と金がかかることを認識し、早めに仕様を完全に確定させることである。
SEが顧客に好かれる方法はプログラマーに嫌われることである。
金と時間があれば、どんなシステムでも作ってやると密かに考えているSEとプログラマーは数多い。
しかし、その機会が与えられることはない。
品質は仕様変更の数と規模により、どれだけ劣化するかが決定される。
営業とは空想が実現すると考える夢想家である。
SEとは越えられない壁はないと信じる冒険家である。
プログラマーとは夢想家と冒険家によって漆黒の海に投げ出された漂流者である。
有能なプログラマーが詳細設計を貰って最初にすることは、プログラムの目的を理解することである。
次にすることは、指定された方法と工数では目的を果たせないと言うことをSEに理解させることである。
プログラムとは運と勘によって作成される奇蹟である。
その両者がなければ、その工数でその仕様が実現できるわけがない。
仕様変更とは奇蹟にいちゃもんをつける罰当たりな行為である。
仕様追加は奇跡が二度起こると信じる無謀な行為である。
自分が顧客なったつもりになれ、と言われてプログラマーが想像する。夢のようだ。
趣味でプログラムを作成する人にとって技術とはプログラム言語スキルのことである。
職業でプログラムを作成する人にとって技術とはロジカル思考スキルとヒューマンスキルのことである。言語などマニュアルとヘルプを見ながらでも言うことをきくが、顧客はそうでもない。
システムは納品までの間、縮小を続ける。
要件定義で、社長を喜ばせる。
概算見積もりで、部長が現実的な案で妥協する。
運用打ち合わせで、課長が責任範囲を狭めようとする。
詳細打ち合わせで、担当者が覚えられる範囲に絞り込む。
SEは持久力、プログラマーは瞬発力。
定時に職場を出ると、仕事が増える。
完璧なプログラムは完璧な時間と金が必要になる。
アメリカの国家予算使い放題のNASAさえも、まだ時間と金が足りないらしい。
詳細設計はソース内のコメントにて完結する。
コメントだけが唯一の自衛手段であるから、少なくとも本人が理解できるように書かれている。
目で追う暇があるなら動かせ。脳細胞よりもCPUのほうが解析が速い。そして、その間、休める。
不具合をバグと呼ぶか仕様上の制限事項と呼ぶかは残された工数と納期によって決定される。
カジュアルデーは、世間では休日とか祝祭日とか呼ばれているらしい
修羅場が続くと、殺気立ち怒鳴り声が多くなる。
さらに続くと、口数が少なくなり愚痴が多くなり、どんよりとした空気に包まれる。
もっと続くと、やたらと陽気になり、元気な声が響き渡るようになる。この状態を「プログラマーズ・ハイ」と呼ぶ。倒れる人が出てくるのはこの辺りからだ。
遠くの火事は必ず燃え移ってくる。
祈れ、そして働け。(修道院のスローガンより)
プログラムは頭で覚えるんじゃない、体で覚えるんだ。
明日休めるのなら死んでもいい。
外は雨だったんだ。昨日から降っていたのかな?
心が荒まなければ、体が荒む。
非情にならなければ、自分が殺される。
顧客は嘘を付く。営業は夢を語る。SEは空想を話す。
プログラマーは無口になる。(独り言は多くなる)
SEは「無理はするな」と無茶を言う、
営業は「無茶」と言うなと無理を言う。
仕様書とは海図のようなもので、顧客とは海流のようなものだ。海流はよく変わり、海図は紙屑になる。プログラマーは海図のない海の上で自力で陸に辿り着かなければならない。
ぐだぐだ言うと金がかかるぞ。
「はい、できます」と言いそうになったら10秒数えろ。
人はおよそ他人の失敗から学ぶことのできない動物だ。
値切る、変える、増やす、急かす、誰もみずほの失敗を教訓にしようとしない。
ベテランが気力を取り戻すための魔法の言葉
「それでも、昔に比べれば・・・」
新人がやる気を出すための魔法の言葉
「この仕事が終われば・・・」 彼らは、仕事の谷間など無いことをまだ知らない。
納期とは開発現場を会社から顧客先に変更する日である。
プログラマー・SE・マネージャーなどは職種ではない。役職だ。
営業は最もやっかいな顧客である。
問題に対してすぐさま解決法を決めつけるプログラマが多すぎる。
彼らは 1分考えて、1日をコーディングに費やす。
1時間考えて 1時間でコーディングする代わりに。
Jon Bentley
綺麗な仕様では、バグが出ないとわかったの。汚れているのは、 設計なんです。何故こんなことに・・・
追加要求を確定すると納期は確定できない。納期を確定すると追加要求を確定できない。これを納期と追加要求の不確定定理と呼ぶ。
三つのデバグは一つのバグを産む。これをバグのエンドレスループという。
いやな予感は必ず当たる。
しかしプログラマーは、その悪い予感に対応しようとはしない。それはSEの仕事だ。
修羅場を解決できる方法は、唯一、顧客が金を出してくれることだけだ。
素人のオペレーターはバグを発見する天才である。再現不能。
打ち合わせのたびに仕様が変わる顧客の操作マニュアルは、できあがったPGを操作しながら作成される。
分からないときはIntegerよりCurrency。CurrencyよりVariant。安全第一。(VBプログラマーより)
プログラマーが不満に思う仕様は顧客も必ず不満に思う。
プログラマーに必要なスキルは、交渉・スケジュール管理・業務分析・提案・設計・言語・構築・保守・運用。
SEに必要な能力は、これから言語・構築・保守・運用を引く。
マネージャーに必要な能力は、さらに業務分析・提案・設計を引く。
営業に必要な能力は、さらにスケジュール管理を引く。
健康だからこそ、不健康なことができるんじゃないか。
(格言どもより)
し、仕様よ、仕様。でも、ちょっとだけ仕様じゃないの。
(fortune (back number)より)
それは、あなたが言った仕様ですよ。
開発室の窓は開かない。その理由は昔・・・
腐っても仕様。(fortune (back number)より)
SE: しようがないな。
PG: コメント もありません。
(作り人知らずのPGの問い合わせに行き詰まった状態)
どうして、こんなことちょいちょいとできないんだ。
ちょいちょいとできたものに、あなたがちょいちょいと品質確認の印をついてくれるのでしたら。
今日の害虫駆除でバグも死んでくれないかな。
え、Windowsも死んでしまいますよ。
顧客は最悪を考えず、最悪に対応しようとするのを悪質な費用のぼったくりだと思う。
SEは最悪に備え、最悪に対応しようとする。
PGは最悪を誰よりも予想し、最悪を無視する。
次善の方法は、スケジュールと人員を定めた後は仕様の変更や追加の度にプロジェクトを見直すことだ。
共同責任はプログラマーの責任。管理職? 何それ? おいしいの? 食ったこたねぇなぁ。
もし転職するとしたら、定時で帰ることを「逃げる」と呼ばない職業がいいですね。
職業プログラマーにとって美しいプログラムとは、単純で素朴なロジック、簡単で基本的なコマンド、豊富なコメント、つまり新人に近いプログラマーが初めて見ても直ぐに修正できるようなプログラムである。
そのためには単純で簡単な美しい仕様が必要である。しかし残念ながら顧客は素人だ。何故か凝りたがる。
設計者が、設計以上のものを 製造者に求める分野なんてあるはずがないじゃないか。
仕様書に書かれていないことをしても、また、仕様書に書かれていることだけしてもSEはプログラマーに文句を言うものだ。だからプログラマーは仕様書に書かれていることだけしかしない。
SEがプログラマーに言う「常識」は、三時間毎に変化する。
無理ですというのは一日を何時間で計算しているんだ。一日は 3人日、一ヶ月は4.5人月あるんだぞ。
工数は半分、単体テストを引き、システムテストを半分しにて、 納期は運用後二ヶ月を足して計算しています。
金がもらえる仕様変更は受注要件だが、金が付かない仕様変更はSEの仕様の確認ミス 、とプログラマーからは見なされる。
もう疲れたよ。なんだかとっても眠いんだ。帰っていいかな。
(疲れただろ、僕も疲れたよ。なんだかとっても眠いんだ。仕様でいいよ、もう)
- 1 http://b.hatena.ne.jp/add?mode=confirm&title=%u30D7%u30ED%u30B0%u30E9%u30DE%u306E%u683C%u8A00 - platoronical%u306E%u65E5%u8A18&url=http://d.hatena.ne.jp/platoronical/20081209/1228787409
- 1 http://d.hatena.ne.jp/diarylist?of=50&mode=rss&type=public
- 1 http://d.hatena.ne.jp/keyword/小学生
- 1 http://dir.goo.ne.jp/culture/03994/04025/site/http:$$www.wdic.org$
- 1 http://fastladder.com/reader/
- 1 http://search.yahoo.co.jp/search?p=WINDOWS+ワークスペース切替器&ei=UTF-8&fr=top_ga1&x=wrt
- 1 http://www.google.co.jp/reader/view/
- 1 http://www.google.co.jp/search?q=flint+particle&lr=lang_ja&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&client=firefox-a
- 1 http://www.google.co.jp/search?q=nativeWindow&sourceid=navclient-ff&ie=UTF-8&rlz=1B3GGGL_jaJP280JP281
- 1 http://www.google.co.jp/search?q=scaleGridTop scaleGridLeft&lr=lang_ja&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&client=firefox


