--/--/--(--)


上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
コメント(-) | トラックバック(-) | --:--:--

2010/09/14(火)


入社してから数年、ようやく私は仕事にも慣れ、毎日意欲的に作業をこなしていました。
当時の私は、どのプロジェクトでも利用可能な汎用的機能を集めた共通ライブラリの作成(開発言語はC)に携わっていました。
私の担当は、とあるメモリ領域を同サイズに等分し、それぞれを貸し出したり返却したりする機能でした。
私はその機能を「メモリブロック管理」と名付け、愛着を持って開発してきました。

「貸し出すメモリブロックがなくなった場合のエラーなんだが」

ある日、上司が私に話しかけてきました。

「君はENOBLKという独自のエラー番号を使ってるね? 『エラー番号はなるべくerrno.hに沿う』というコーディング規約があるんで、それにしたがって直した方が良くないかな。例えばそう、一時的なバッファ不足という意味でEAGAINがいいんじゃないか」

「いいえ、それは違います」

私は得意げにそう言います。

「確かに今回のプロジェクトにおいてはEAGAINでいいのかもしれません。しかしこの共通ライブラリは今後、他のプロジェクトでも使われる汎用的なものです。使い方によっては、それが一時的なエラーではない可能性も出てくると思います」

私は話を続けます。

「例えばシステムの起動時にすべてを取得し、終了時に一気に返却するという使われ方をされた場合がそうです。一度取得されたブロックは返却されることがないため、EAGAINが返ってきたからといってリトライされてしまうと、無限ループに陥るかもしれない。メモリブロックの枯渇は、それが一時的なものなのか、それとも回復不可能なものなのか、共通ライブラリのレイヤーでは判断がつかないのです」

私は上司が反論してくるのを待ちました。
自分は正しいことを言っている。
かたくなにそう信じ、上司の反論に応酬するつもりでいました。
しかし、その上司は「そうか」とだけ言って私の元を去りました。

実は上司が関数仕様書にEAGAINと記述し、それがすでに関連部署に配布済みであったことを知っていました。
正直なところ、メモリブロック管理はその機能特性上、私が例として挙げたような使われ方をされることはまずありえませんでした。
にもかかわらず、そのときの私は自分の主張を押し通したのです。
ひょっとすると、私に一言の相談もなく仕様書を作って配布してしまった上司に腹を立てていたからなのかもしれません。

その後、何も言われなかったため、私はENOBLKを返すコードを修正しませんでした。
しかしなんの問題も出ないまま、製品は出荷されていきました。

ある日、共通ライブラリのエラー番号を定義するヘッダファイルを見る機会がたまたま訪れました。
そのファイルを見て、私は驚愕しました。
なんと、ENOBLKはEAGAINと同じ値で定義されていたのです。



さて、あれから十数年の月日が経ち、私はテスター、サーバ管理、PG、SE、PM等ほぼソフトウェア開発に関わるほとんどの役割を経験してきました。
この出来事を思い出し、ふと考えることがあります。
もしあのとき私が上司の立場だったら、あのくそいまいましいプログラマにどのような対応をしただろうかと。

コメント(0) | トラックバック(0) | 12:13:23
コメントを書く

管理者にだけ表示を許可する
トラックバック:0 - http://genmaicha460.blog27.fc2.com/tb.php/30-73a8a1e1

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。