そう、ネーミング以外にも、長すぎる関数、無意味なコメント、変更箇所をコメントアウトして残す、などなど技術者を詐称するカスがやりがちなアンチパターンを一通り取りそろえているのだ。それゆえに、なにか事情があってこのような有様になっているのだろう、と好意的に考えられない。おそらく単に担当者が無能なのである
ｗｗｗｗｗ、昔話でもしようか。以下の話は一部フィクションです。
あるSI企業のプロジェクトに、関数の名前が全て EA00001 のようなコードで定義されている仕様書がありまして、それはどこか別の会社のお偉い上流エンジニア様が作成なさったらしいのですが、こういう命名はどうなんですか？と当時新人だったおいらは先輩に質問しました。
そのとき先輩は、システムエンジニアなら、その程度は全部覚えるもんだ、という意味の事を言ったことを覚えています。今考えるとどう考えてもダメなんですが、まだ純真な社会人一年目のおいらは、そうなのか！と真に受けてなんか無駄に熱く燃えて仕事に取り組み、案件とともに炎上したのでした。
いや、１年目の新人に対する先輩社員の答えとして社会的には100点なのさ、たぶん。会社が要請するよく訓練された社会人としては正しい回答なのさ、おそらく。知らんけど。だが、確実に間違っている。エンジニアとしてもダメ、ビジネスマンとしてもダメだ。
今の俺ならどう答えるか？そんな名前はゴミカス以下の廃棄物、命名超重要、名前付けた上流エンジニアは無能ウンコ死ねばいいのにって答えるだろうな…。ま、確実に人としてダメな回答だけど。
あの炎上案件はやりがちなアンチパターン満載案件だった。デスマの本当の要因は要件定義やプロジェクト管理がgdgdなせいであって、設計が根本原因ではない。だが、クソな命名のおかげでただでさえ時間無いというのにメンバーが無用な時間を浪費したのは間違いないのだ。
そうした無駄な事前準備を行うことも仕事の範疇、大いに結構なことである。しかし、そうした無駄を場当たり的な人の努力で補って良しとする思考は常に間違っている。本来不要な作業なのだから、無くせるようにしていくべき。たとえ今は自分の努力/我慢で乗り切るしかないとしても、それを安易に許容すべきじゃない。ダメなものはダメというべき。
クソ命名が何故クソなのか。プログラムの美しさとかエンジニアの美意識といった問題だけの話ではない（もちろんこれは大切なこと）。もう一つの理由は、それが無駄なコストというビジネスにおいて最も忌むべき存在だからだ。アンチパターンに疑問を覚えない技術者を詐称するカスは、その命名が不要なコストを上乗せするもの、損失であると認識すべき、というかエンジニアとっとと辞めちまえ。
