ダメエンジニアの8つの特徴

1. オブジェクト指向を理解しない

ダメエンジニアはオブジェクト指向を理解しません。

もちろんオブジェクト指向を理解しなくてもプログラミングはできますし、動くプログラムを書くことは可能です。しかしオブジェクト指向プログラミングを使わずに（あるいは十分に理解せずに）書いたプログラムは著しくメンテナンス性・可読性が低く、共通化すべき箇所が共通化されず無駄なロジックが散在するコードとなるでしょう。

オブジェクト指向の技術は1970年頃の登場以降、様々な進化を遂げながらも今なお開発の最前線で使われている技術です。こんなすばらしい技術を使わない手はないでしょう。

2. コードが美しくない

ダメエンジニアのコードは汚いです。

では美しいコードとはなんなのか。個人的には「プログラマの思想が見えるコード」「一貫性があるコード」だと思っています。

思想が見えるコードというのは、例えばコードを見て「この人ならここはこう書くだろうな」とか「この人が作ったこのメソッドはきっとこういうことをしているんだろうな」といったことが想像できるようなコードです。

つまり、できるプログラマはしっかり自分の中で「こう書く」という思想があるので基本的にコードがブレないのです。そういう人が書くコードというは、得てして一貫性があり、（たとえコードの書き方などが自分の趣味とは合わなかったとしても）美しいものです。

一方、ダメエンジニアの書くコードというは、字下げが一貫しなかったり、演算子前後のスペースの有無が場所によって異なっていたり、変数名、メソッド名が一貫せずにちぐはぐだったりします。

3. コメントが適当

ダメエンジニアはコメントが悪い意味で適当です。

「あれ、これコメントに”TODO”入っているんですけど終わったんじゃなかったでしたっけ？」ダメ「ああ、ごめんごめん消し忘れたんだわ。そっちで消しといて。」「（終わったんなら消しとけよ・・・）」

「（このクラス、findやら、seachやら、getResultやら似ている関数名がありすぎてわかんねぇ・・・）あの…の結果が欲しいんすけどどれ使えばいいんすか…?」ダメ「あぁ、それなら(メソッド名)使えばいいと思うよ。」「（少しくらい説明加えておけよ・・・）」

コメントの書き過ぎもよくありませんが、全く書かないのも考えものです。

よく「コメントを書くな。コメントを書く必要のないくらいわかりやすいコードを書け。」なんて言われたりしますが、ダメエンジニアの書いたコードは残念ながらコメントを書く必要の「ある」くらい「わかりにくい」コードです。

285 名前：仕様書無しさん [] 投稿日：2008/07/14(月) 10:33:43
// TODO 美しくない。後から見直す。
287 名前：仕様書無しさん [] 投稿日：2008/07/14(月) 19:55:14
// TODO 美しくない。二度と見たくない。
288 名前：仕様書無しさん [] 投稿日：2008/07/15(火) 01:23:29
// TODO 美しくない。もう直したくない。

via. ベア速【プログラマー板】印象に残ったコメントを晒せ

4. 開発標準を守らない

ダメエンジニアは開発標準を守りません。

ダメエンジニアを部下に抱えるマネージャは考えます、「どうすればダメなやつをダメじゃなくするか」と。そこでマネージャは開発標準を作ります。

開発標準はコーディング規約であったり、開発プロセスであったり、開発手法であったりします。処理がなるべく明確になるようなドキュメントをダメエンジニアに書かせ、それが完成したら必ずマネージャがレビューをするようにします。このようにして誰が開発しても成果物が同じになるようにマネージャは努めます。

しかしダメエンジニアはそれを守りません。開発標準を決めても結局自分の書きたいように書き、およそ彼以外使えないようなオレオレ関数を量産し、その結果見事に訳のわからないプログラムが仕上がります。

エセーグルは開発プロセスに従うことで、高品質なシステムが作れるようになったのでしょうか。
いいえ、そんなことはありませんでした。
エセーグルはドキュメントを書かせても読みづらく、矛盾だらけのドキュメントを書いてきました。コーディング規約や開発標準を用意したところで、彼はそんなこともお構いなしに自分の好きなようにコードを書き続けました。問題点を何回指摘しても、摩訶不思議な持論を繰り返して自分の正当性を主張してきました。結局、プロセスを導入してみても彼の作るシステムはやはり理解不能なスパゲッティコードだらけで、誰の手にも負えないような粗悪品のままでした。

ソフトウェア開発プロセス残酷物語 - give IT a try

5. テストコードを書かない

ダメエンジニアはテストコードを書きません。そして彼らは作ったら作りっぱなしで、品質に責任を持ちません。

まともに出来上がっていないものを「できた」と言い張ります。試しにマネージャやテスターがそのプログラムを動かしてみると、まともに動きません。処理フローの中で一部のチェックロジックが抜け落ちているならまだしも、数段階ある処理フローの最初の段階ですらまともに動かないことがあります。

ダメな彼らにしてみたら複雑に入り組んだ処理の中の最も簡単の処理フローがまともに動いただけで「できた」ことになるのでしょう。

ときに彼らの手は人のプログラムにすらも及ぶこともあります。（彼らによってバグを植え付けられ、何度私が”git blame”コマンドで犯人探しをしたことか・・・）

彼らはテストコードも書きたがりません。彼らはそれをコストだと考えます。彼らにとって重要なのは、テストを書いてプログラムの品質を高く保ち続けるよりも、品質が低くともまずプログラムをさっさと仕上げることです。

作るのが早く、できていないプログラムをできたと言い張るより、作るのが遅くとも、丁寧に作ってバグが少ないプログラムを作ったほうが手戻りも少なく、テスターの労力も減るのでよいと思うのですが。

6. コミットログをまともに書かない

たとえば以下のようなコミットログです。

コミット
変更
追加
Fix

「おいおい、目的語がねぇじゃねぇか」ってやつ。ダメエンジニアは自分さえコミットの内容がわかっていればいいので、他の人がそのログを見ることを想定しません。また、自分が過去に遡ってコミットログを読むことを想定しません。

最低限、何(What)をどうしたか(How)くらいは最低限コミットログに書いてほしいものです（場合によってはなぜ(Why)もいれる）。

7. 例外の扱いが雑

ダメエンジニアは例外の扱い方が雑です。とあるコードレビューの１シーン。

「えーと、なるほど、ここでこの例外をキャッチしてるわけね。。。んで、その中身の処理は、と…（…うわっ、これ例外思いっきり握りつぶされてるやんけ…！）」

と、ここまでひどくはなくても、上位へ例外throwすべきところでthrowされていなかったり、例外発生時に適切なログが吐かれていなかったり、切り分けるべき例外が切り分けられなかったりします。

8. 最新技術に興味がない

ダメエンジニアは最新技術動向に興味がありません。

ドッグイヤーなこの業界ですから現在一般的な技術が三年後、五年後、十年後も現在のままあり続けるなんてありえません。しかし彼らはそんなことは気にせず、今いけてんだからいいじゃんと思考停止し、現状に満足します。現状に満足しているので学習意欲もありません。技術動向がどうなろうが関係ありません。

無論、枯れた技術を否定するつもりはありません。枯れた技術には良いところがいっぱいあります。しかし技術トレンドを知らずして無根拠にレガシーな選択を続けることは、ときに最善の選択を逃してしまい、気づいたときには周囲に取り残されてる…なんてことになりかねません。

最後に

以上、私もまだまだ未熟なエンジニアではありますが、そんな未熟な私が最近思う、ダメエンジニアでの特徴でした。