イケてないプログラムの共通点

イケてないプログラム（使えない成果物）に見られる３つの共通点 :: Drk7jpを読んで「うんうん」という人は少なくないと思う。問題はひとつではなく複数の要因から成り立っている。

外注という仕組みに起因する問題

自分はとある会社で外注の立場で常駐している訳だけど、こういう外注を含め外注には内部の人間とは違うルールが働く。これはエンジニア個人の能力とは別の問題だ。

• 目先のコストが最優先される。時間いくらで仕事しているのではなく、また、成果物は自社のものではないため、当然ながら無駄なコストは悪となる。
• 形を最重視する。社員と違って基本的に契約が切れたら、納品が完了したら基本的に無関係となるため、明確に成果を定義できない調査・研究・改善のようなものは黙殺される。
• 契約にない事はしない。当然だが、契約内容がタコだと悲惨な結果が待っている。
• 触らぬ神に祟りなしの法則に縛られる。改修なんかの場合、触る箇所が狭ければ狭いほどリスクが減る。すなわち改修によって影響の出る範囲が限られるため、試験コスト、保証コストが低減でき、本来修正すべき王道が判っていても、あえてきな臭いコードそしてコピペコードを記述する場合がある。

ソースコードの記述に関する問題

外注だからという訳じゃないけど、イケてないエンジニアが書くコードにはこんな原因があると思う。

• 真の命題が理解できていない。これはエンジニアより上司にありそうだけど、問題の本質がなんだか理解できずに突っ走る輩が多い気がする。クライアントの話を聞いてきた営業から聞いた上司が「これをこうしてこういうモノを作れ」みたいな。結局客は喜ばないものが出来上がる。「あぁここの1行を直せば良いのね」という近視眼的な発想から抜けないままの修正もそう。
• 動けば良いじゃん的発想から抜け出せない。確かに仕様にある範囲では正しい動作をするが、そこから容易に連想できる範囲でも仕様書になければメタメタな動きになる。そして通常仕様には記述されない実行速度についても無視される。というか、そんなの考える暇を与えられていない(と本人は思ってる)
• アルゴリズムを軽視する。パターンは無理にでも当てはめようとするのにアルゴリズムは無視。自己流。
• 形だけのオブジェクト指向。こういうときは継承とか、クラスとはこういうもの、という言われたことだけ守ってつくる。だから、逆効果な継承や、一度しか使われないインターフェース、不気味なシングルトン、メンバ変数のないオブジェクト、コンストラクタだけで処理の終わるクラス、なんてのが出来上がる。
• 知っていることだけで片付けようとする。配列とHashMapしか使わない奴なんてのもいる。そりゃ変なプログラムになるよな。ちょっと調べればまともな方法がすぐに見つかるのに。
• コピペに恐怖を感じない。自分は同じコードが複数箇所に出てきた場合、正直いって恐怖を感じる。将来の修正時のリスクを考えるからだ。だが外注という事もあるのか、改修範囲の事があるのか、彼らはそういう事を無視する。コピーマンセー状態。
• 意味のないコメント。単にeclipseで自動生成しただけのコメントや、体裁だけ整えたものだらけ。同じような二つのメソッドのコメントがメソッド名以外すべて同じコメントとかってのもよくある話。自分でもその二つの違いが判らなくなってるからバグの元。無意味にすべての行に入っているコメントや、処理内容を日本語に置き換えただけの関数コメント、そんなのに何の意味が。水増しか。
• 意味の取れない識別子。copyの引数にbeforeとafterとか使われたら何がなんだか。と思ったらpastとfutureってのもあった。なんだそりゃ。オンライン辞書で、「元」と「先」を変換しただけだな。馬鹿以下。KaitenとかShoriとかもお里が知れる。正しくても難解な単語や長い単語もどうかと思う。自分は識別子ひとつ決めるのに3分悩むことすらある。後で自分で意味が間違えずに取れる為だ。そのためなら今の3分は惜しくないし、全体としてコストダウンとなる。

なんか愚痴みたいになってしまった。