ぷっちん日記

■ 自分の仕事にはいれない

週末中、延々と某氏のせいでむちゃくちゃになっているコードの手直しに追われた。自分のところの単体テストをやろうとしたら、あるメソッドにあやしい引数があり、追っていったらとてつもなくたくさんの仕事があるわ、あるわ、、。

怒りたいけど、怒っているけど、それどころじゃない。

せっかくだから今回わかったことを書いておこう。

これにたくさん当てはまる人は採ってはいけない。

• シナリオ番号が好き
• 返り値は0とか1とか2が好き
• MLにメールを投げないで必ずDMしてくる
• クラス名が意味不明
• 文字列変数名の先頭に s をつける
• ChangeLog は全部 Changed. で済ます
• 処理のまとめ方が手続き的で、複数レイヤーの処理を１つのメソッドに入れ、処理の違いをパラメータによる分岐で解決しようとする
• switch 文が好き
• Object#hashCode を知らない
• Vector が好き
• System.out.println が好き
• 他人の JUnit をまったく実行せずに commit する
• JUnit テストを書かない
• コンフリクトを病的に恐れる
• ソース中に絶対パスを書いたものを平気で（何の TODO コメントもなく） commit する

次はこういうところに気をつけよう

• ENUM 的な値を扱うクラスは早めに設計しよう
• 処理レイヤー分けは最初に指示しよう
• 面接であやしいと思ったら絶対採用しないようにしよう
• 日本語データベーステーブルをみせて英語名をつけさせてみよう。意味不明な省略をしたらお帰りいただこう。
• クラス名をつけさせてみよう。先頭に、読んでわからない大文字アルファベットが３つ並んでいたら即効で面接を終了しよう。
• switch をよく使うか聞いてみよう

レビューも設計も大事だけど、臨時の急ぎのリソースとしては、採らないことがもっとも重要だ。

えらい目にあいました。