Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

エンジニアが育つ環境のために

ファイルの有無をチェックするのに、
「fopen() して、エラーだったら。で、fclose() する。」というコードを
ときどき見かける。どこの会社というのはなく、あちこちで。わりと。
 
これで「ちゃんと動いている」からいいや、なのだろうか。
誰かが作ったものだから、とか、
他の箇所でもこうやってるから、なのだろうか。
 
かんたんな処理ゆえ、
共通関数化されていなかったりもする(同じコードをべた書き)。
errno も見てなくて、単に fopen() の戻り値のチェックだけだったりもする。
 
今のひとたちに「ファイルの open は重い」という感覚は持てないだろうし、
もしかすると今や「重い」なんて言うほうが老害なのかもしれない(?)し、
そんなことは気にしなくていいシステムかもしれないし。

用をなしているのだから、これで「問題はない」のだろう。
 
でも、何も疑問に思わないのだろうか?
「ファイルの有無」を見たいだけなのに「ファイルのopen」をするのだぞ?
読みも書きもしないのに open して、ファイルがあったら close するんだぞ?
ムダじゃん。用途ちがうじゃん。エラーだっていろいろ種類があるじゃん。

もっと「ズハリそれ」みたいな処理がないものか、探したりしないのだろうか?
もっといい他のやり方がないか、考えたりしないのだろうか…。
  
 
前例を見て、それを「あたりまえ」と思い、「お手本」にしてしまうことは
よくあることのように思う。
知識が足りないとか、対応する余力がないとか、
プロジェクトにはそういう制約もあったりする。
 
けど、
「これカッコわるいなぁ、もっとうまいやり方ないかな?」って思う
自分なりの基準を持てるように育っているのか、そして、
「こっちのやり方がいいよ」って気軽に言えるチームなのか。
そういうのは大事だと思う。

ただなんとなく仕事ができてればそれでいい、ではなくて、
そういう観点が持てて、議論ができるように、
そういう訓練ができる環境であるように。
僕らはどんなことができるだろうか。
  
ただなんとなく仕事をしててはいけない。
 
linuxjm.osdn.jp