コンピュータ外人部隊
Kudou Kikaku
天才プログラマ達
42
プロフェッショナルの章
ちょっとまじモードなので笑えないかもしれない。。。
このページは下のXの行が折り返されないところまで画面を広げてお読みください。
ＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸＸ
(411)
ことごとくそれらしい、推測を並べて結局全部まちがってしまうプログラマ。
プログラマの才能は、想像力とアルファ〜波をどんだけだせるかにかかってる（笑
(412)
いつでも、笑っている客ほど恐いものはない。
裏の顔でなにをかいわんや（恐
(413)
先日メールがはいった。
体制を整えたく。。。（前に書いたけど。。。）
一応状況を課長に話しておいた方がいいかと思いメールしたのだったが。。。
１）見積機能・工数・経費に関して予定と差異が無かったか？
２）ハード、ソフト基本設計・仕様レベルに落ち度が無かったか？
３）製作レベルに落ち度が無かったか？
４）工程の決定・進行に問題は無かったか？
５）テスト＆リリース体制にに問題は無かったか？
これについて再度見直したく〜
あ〜たの会社は、いまごろこんなこと考えるんかい！
後手後手やん！
(414)
工期は絶対！
納期は絶対！
これは、昔から口をすっぱくしてどこの会社へ行っても
どの部署へいっても言われてきたこと、言ってきたこと。。。
つまり、腐った林檎は商売にならんのぢゃ！
欲しい時がうまい時。
腐った林檎に金を払う客はいないと知れ！
(415)
レス。
＞１）見積機能・工数・経費に関して予定と差異が無かったか？
いまさらゆうんかい！
＞２）ハード、ソフト基本設計・仕様レベルに落ち度が無かったか？
落ち度が客先、うちにあったとしても工期遅れで十分にペイすると
おもうんぢゃが？？どうかのぉ〜〜
＞３）製作レベルに落ち度が無かったか？
ほんとはプログラマは並みレベルだと思うので問題はなかったのだが
このプログラマにど新人をつけた会社の管理責任っちゅ〜ものがあるような
気はするのぢゃが。。。。
＞４）工程の決定・進行に問題は無かったか？
なかったともいえんが、対応できないほどではなかった。。。
プロならば。。。。
＞５）テスト＆リリース体制にに問題は無かったか？
１０時に帰っていなければ問題なかったと思う。
ここ一番にね。
さらに、かなりやばい時期にこのプログラマに対して支援体制を
とらなかった会社にとっても問題が残ると思うよ。
彼死んじゃうよ、スキルオーバーだもん。
社員旅行なんていってる場合じゃなかったと思うよ。
その辺りで気付いているべきだったね。。。
今回の問題で、 首になったらうちにきなぁ〜、
最後まで守ってあげるから＞某プログラマ
(416)
プログラマと名乗るプログラマは山ほどいる。
しかし、顧客業務をクリアしていけるプログラマは
数えることができるのだ。。。。
そこで、徒党を組んでなんとか、顧客業務システムを
こなしているのがソフトハウスと呼ばれるところだ。
ソフトハウスは、小さいほどパワーがある。。。
とも限らないか。。。
プログラマが自己発起した会社ほどパワーがある。。。
といっとくか（笑
(417)
今回わかったのは、、、、、、、、、、、、
外注がいやがるところほど バグがあって、
それは客が望んでいるところだ！
(418)
修正に抵抗する量が多いほどプログラマのスキルは低い。
言い訳をする量でプログラマのスキルを計ることができる。
(419)
客のわがままは、予測しろ！
予測してソケットを埋め込んでおけ！
そして、倍掛で追加見積もりするのだ！（笑
(420)
全てのシステムは自分がテストしずらいと思ったところは
客も使いにくいと感じるのだ！
気付いた時に対処しとけ！
あとになると、わすれて工期が数十倍に膨らむ！
気付いてすぐ罠をしかけないプログラマは無能に近くプロでは
やっていけない。
(420おまけ)
埋め込んだ罠で、簡単なものほど客には重く説明するのだ！
客が欲しがる隠しコマンドほど見せびらかして、目の前で
外してやるのだ。。。。この部分は趣味でいれときましたから
外しときますね。（笑
(420おまけ)
新人君の為に。。。。
全てのイレギュラー処理の為にエラーメッセージを表示する。
これは、この業界では常識なのであ〜る。
しかし、「エラーが出ました」ってエラーメッセージいれんのやめろぉ〜〜！
なして、エラーだったのか？なんのエラーだったのかエラーになった理由が
推測できる情報とともに。。。いや、それがあればエラーが出ましたのメッセージすら
必要ないのぢゃ！
１０年生がそったなエラーいれるなぁ〜〜！しかも、一度チェックルート通った場所で
何回も！
不必要なエラーメッセージは、バグ取りの命取りになることがままある！
おぼえておくように！そこの１０年生！！
わしのセオリー
エラーログはダイアログ表示をしてもしなくても出力する。
そして、どれひとつ同じメッセージはない。（場所を特定できなくなる）
全てにキーとなる変数の中身を表示するようにしておく。
ファイルのオープンエラーなど、パス＋ファイル名を表示するのは
ごくごく当たり前のことなのだ！
その瞬間の煩わしさをがまんすることが数ヶ月、数年先の自分を
救う手がかりを埋めていることをわするることなかれ！
わしのセオリー２
プログラムは、簡潔であるのがいい。
急いで開発をしていると自分で書いていてもわからなくなる構造に
なることは、ままある。
デバッグのたびに簡潔にしてゆくことが必要だ。
入り組んだモジュールにはバグが住みつきやすい。
わしのセオリー３
計算式は変数を増やしてでも分解するに限る。
計算過程の誤差を見つける時にとてもらくちんになるっけよ。
わしのセオリー4
割り算の前には必ず if が入っている！
プログラムに入り込んだ直後での検査はあまりあてにならんのだ。
欲しい時にチャックする。
プログラムの見通しがよくなるのだ。
なるべく小さい範囲でデバッグができるように気を配るのぢゃ。
めんたまは２つしかないのだ。
頭は、デバッグで忙しいのだ。
関連変数、モジュールの場所などに裂く時間はどこにも
ないことを知れ！
開発のまだ余裕のある時にこそ、その為の労力を惜しんではいけない。
デバッグは絶対時間のないところでの作業になるのだ。
そして１００％の確率で納品後に出るバグが強力なバグなのだ。
プログラマの危機管理とはそういったことだ。
わしのセオリー５
ふがいないプログラマの見つけたバグの推測は１００％うそだ。
それ以外のそうなる可能性を探れ。
しかし、それは、かなり遠くても次ぎの推測への手がかりになる。
次ページへ
全てノンフィクションですがなにかと問題がありますので一部正確な事実と異なることをお断りいたします。
著者：工藤ゆたか <HOME>