ザマス
エンジニア大家
ガバッ！
ハァハァ、あー夢か。。。
ときどき過去のトラウマが悪夢で蘇って目が覚めることがありますｗ
今日は書くことが無くなったので最初の開発現場でチームリーダー（通称：ザマス）に叱られた話をしたいと思います。
経験8年のwebエンジニアが初めての客先常駐で叱られた事
何を隠そう、私は最初に勤めた会社で8年もwebエンジニアとして数十サイトに関わってきたのですが、
その間ほぼ一人で開発から運用・保守までを行っていました！
というわけで、それまで他のエンジニアと一緒に仕事をやったことがなかったのです。
なのでソースレビューを受けたこともなければ、コード規約の縛りももちろんないので自分の本能のおもむくまま自由に開発してました。
そして会社を辞めてフリーランスとなり、初めて客先常駐した先の一発目のソースレビューでコテンパンにやられました。
その時のレビュワー（チームリーダーのザマス）がメチャクチャ怖い女性（年下）で、
見た目はとても地味系の「theエンジニア」的な人で冗談の一つも通じない方でした。
とある機能の一画面のソースコード（MVC）をレビューして頂いたのですが、
当時githubみたいな仕組みが無かったためレビュー内容はエクセルにまとめていただきました。
たった一画面なのにそのエクセルに60項目も指摘されていまして、とても恥ずかしい思いをしました。
その内容の一部を書きたいと思います。
コメントが幼稚、もしくは不要
これまでコメントは自分以外誰も読まないので超適当でした。
// ここよくわからないから仮で！
とか
// このフレームワークあんまイケてないかもm9(^Д^)
とか書いたのを消し忘れてpushした結果、エクセルで、
「コメントが幼稚、もしくは不要」
というお叱りを受けました。
マジックナンバーを使っている
指摘に「マジックナンバーがある」と記載がありましたが、初めて聞いた単語で「？」でした。
つまりは、
$db->query("SELECT id FROM members WHERE enable_flag = 1");
ではなくて、
$db->query("SELECT id FROM members WHERE enable_flag =" . Model_Members::ENABLE_FLAG_ENABLED);
のように定数を用いろという指摘でした。
これも最初は全くわからないどころか、記述が増えてメンドクセーじゃんとまで思っていました。
なので当時の自分はしぶしぶ「はいご所望のとおりに修正いたします」と返事はしたものの、
肝心の定数定義をどこのファイルに記載するのかもわからず、恐る恐るザマスに聞いたらキレられました。
ザマス
ファイル内に不要な記述がある
コントローラのファイル生成が自動で作成される仕組みだったのですが、
ファイルの中身に自動生成された記述で必要なのか不明なものがあり、
それをを消して良いものか？、いやいや後で使うかも、
というふうに判断が揺れに揺れた結果そのままにしてました。
結果的にその記述は不要だったわけですが、当時の自分には必要な記述かどうかの判定ができない位に無知だったわけです。
ザマス
メソッド名がわかりにくい、ていうかありえないネーミングをしている
メソッド名はよく使われるのが、
getXXX
とか
isXXX
とかありますが、当時の自分にこのようなWEBエンジニア的な一般常識的が一切抜けていました。
なので自分なりに考えたメソッド名を付けた時のザマスの態度の「お前はアホか！？」感は凄まじかったです。
ザマス
その他
60箇所指摘された記憶はありますが、もう殆ど忘れてしまいました。
よくもまぁそんなに指摘する箇所があったなと。。。
そして良くもまぁ60箇所もエクセルに記述したなと。
（最初は口頭注意してある程度修正させてから本格レビューの方が効率良かったのでは笑）
用語の発音
現場に入って少し違和感があったことですが、用語の発音が微妙に自分と異なっていました。
nagiosを私は「ナジオス」と読んでましたが、ザマスは「ナギオス」、
gitに関しては私もザマスも同じく「ギット」だったので、私の方が一貫性がないですね。。
「gi」を「ギ」と発音する人が多そうなので、
「ナギオス」、「ギット」が正解だと今は思います。（どっちでもいいかｗ）
あと「リンクを押下する」の「押下」ですが、私は「おしげ」と発音したところ、
ザマス
と血も涙もないツッコミを受けました。。
まとめ
WEBエンジニアの世界で一人現場の経験が8年あったってこんなもんです。
ちなみに会社員だった当時、その会社で一生過ごすつもりでしたので一人現場の状態を全く悲観してませんでした。
今思うと恐ろしいですが、、、。
いろいろな現場を渡り歩いてより良い環境・ギャラを得たいと思う人は「集団で開発をしている現場」で経験を積みましょう。
汎用性を身につけることができると思います。
そうでないと現場が変わるたびに超苦労しますので。
そして超厳しい環境で1,2年揉まれたら半端ない位成長できると思います。
それは他の現場に行ったら時にわかると思います。
なので、ある程度技術を盗めたと思ったら思い切って現場を変えてみるのも良いと私は思います。
素人にもわかりやすく
ちょっと話はそれますが、それまで汎用的なフレームワークも使ったことがなければ、
オブジェクト指向な考えも持っていなかった私に、
ザマス
と宣言されました。
ザマスに何度か説明を受けたのですが、当時に自分には何がメリットなのか良くわからず、言われるがまま実装してしまいました。
今思うと、「素人にもわかりやすく説明できる」のがプロフェッショナルだと自分は思います。
というのも、その後の「すごくわかりやすく説明ができるエンジニア」に出会ったからそう思いました。
ザマス本人に言わせれば「同じエンジニアだから私の説明を理解できて当然」という感じでしょうが、
それでいて相手に理解してもらないからという理由でヒステリーを起こされてしまうと、こちらも質問をしにくくなりますし、現場の雰囲気が悪くなるので、結果として良くないと思います。
そのチームリーダーの方はとても優秀なエンジニアでしたが、私にとって良い人ではなかったです。
コメントを残す