きっかけ
現場でJavaアプリ開発しているが、変なルールがたまにある。
聞いても「こうしてください」としか言われず、腹が立ってしょうがない。
とりあえず、ブログに書いて発散しようぜ！が主な目的である。
意味不なルール
例外Throwしちゃダメ
もう、意味がわかりません。
ルールを守ることを強いられている状態。
エラーチェックして処理を処理を終わらせたいのだが、できない状態。
後続の処理をしないために、判定分を書かなければいけない始末。。。
例外を発生させないことを強制した場合、メソッド分割することができず、モンスターメソッドになると思うのだが、相手が理解してくれない。
個人的に、「例外設計上手くできてないから、例外を発生させちゃダメって方針作ったろ」って気がしてならない。
今まで開発してきた現場で、例外を発生させてはならない現場を見たのは、ここだけだった。
命名がすべてローマ字
日本の企業は多いのだろうか？
DBに引っ張られて、ローマ字を使うことを強いられている。
そうした場合のデメリットは、名称が無茶苦茶長くなる。
ただの変数名で20文字位上になることが多い。
本当にローマ字を許容するのか、ルール作りをする人はよく考えたほうがいい。
文字が多くなければ、それだけタイピング量が増え、改行もやりにくなって画面が見にくくなり、積み重なった手間が生産性を著しく落とすと思うんだよね。
課題管理がない
課題の一覧がない。
ありえないと思うが、実際にあるんだぜ！
おかげで、問題がどれだけ残っているのか、何がネックになっているのか、毎回報告しなければいけない始末。。。
管理職になる人は、よくよく考えるべきだ。
いちいち日報で報告は、個人の時間を削って、最終的にコストが増えるだけだ。
メーリングリストを使ってもプレフィックスが付かない
毎回思うのだが、メーリングリストを使っても、メールのタイトルにプレフィックスつけないのは何で？
タイトルで振り分けしないのだが、メーリングリスト使うと暗黙的にプレフィックスは決まる。
人によっては、タイトルでフィルタリングしているやつもいて、メーリングリストにメールを流すときにプレフィックスを忘れるとひどい目に合う。
もう、メーリングリスト作ったら、プレフィックスの指定は必須にしてよ！
じゃないと共有漏れが起こりやすいんだから！
データ保持用のクラス禁止
データ保持用に、DtoとかDaoとか使うことは多々あると思う。
場合によっては、もう一個、２階層目のデータ保持用のクラスが欲しくなる。
しかし、禁止にされる。
クラスが増殖するのを辞めたい気持ちはわかるが、ツリー構造のデータを単一クラスで表現するには無理があるで！
しかも、データ保持方法がMapしか許さないってなったら最悪。
デバックしづらいだけでなく、不要なデータを持っていることがあり、メモリ圧迫の原因を作りやすい。
自動化という甘い罠
自動化って言葉に耳を貸しちゃダメ！！
騙されないで、相手の思うツボよ！！
自動化って言って、なんでもやってくれるわけではない。
自動化するための前準備が必要な事があり、それが作業ネックになることがある。
しかも、自動化ってのは認識齟齬が生まれやすい。
それを逆手にとる営業がいるから困ったもんだ。
支援や発注した側にとっては、自動化されているから即効でできると思っていてもできない。
本当に腹立たしい。
自動化という甘い罠には本当に気をつけるべきだ。
一般化していないツールの強要
一般化してないツールを強要してくる。
OSSになっているものを独自で拡張して、それを強要してくる。
汎用性がまるでなく、浅はかな考えの実装が多いこと多いこと。
ドキュメントもないため、使う側がかなり困惑する。
使ってわからないことがあると、問い合わせをするのだが、返事が遅い。
遅延が発生しても、「うちらに問題ないですよ」みたいな雰囲気を醸し出しているから、余計に腹立たしい。
一発、腹パンかましてやろうかと思うことが、何度もある。
結婚指輪以外の指輪をしているやつに良い奴はいない
だいたい自己主張が強く、独善的なやつが多い気がする。
仕事する上で、こいつがトップに立つと、上手くいかない事が多い。
なぜなら、実力が伴っていないから。
そして、自分が絶対だと思い込んでいるので、説得させるのが辛い。
横文字を使いたくはないが、コミュニケーションボトルネックになる人は、たいてい指輪をつけている。
Stream使っちゃダメ
処理が遅くなるからダメと言ってきている。
本当にそうだろうか？
検証方法が間違っている可能性が十分にある。
並列処理するところを見誤っている可能性はないのだろうか？
個人的に検証したことがあるが、きちんと中間処理を行っていれば、Streamの方が高速化されるはずだが。。。
「Stream使っちゃダメ」って言っている人たちの頭の中を見てみたい。
継承を機能のコピーと思っている
継承を機能を複製するための機能だと思っている節がある。
複製するのではなく、機能を汎化してから、汎化したものを継承すべきだと思うのだが、間違っているのだろうか？
何度か継承を機能の複製として使っている現場を何度か見たことがあるが、大抵炎上するのがいつものパターンになっている。
戻り値なし
呼び出し元に戻り値を返さないんだぜ。。。
いや、返しているんだけど、returnとかで返してない。
データクラスを別領域で持っていて、そいつを使って呼び出し元と呼び出し先のデータのやり取りをする。
ありえないだろ。。。
おそらく、ＦＷでリフレクション使っているんだろうけど、可読性が著しく悪い。
ソースを追う際に、いちいちソースファイルを探さないと行けないんだぜ。
eclipseなら参照先を開けばいいけど、それができない。
生産性を著しく落とす。
本当に、何がしたいのだろうね、このＦＷは。
考えたやつは、死ねばいいのに。
メソッドの引数がインタフェース
意味あるのだろうか？
引数は、もうメソッド固有だろ？
使いまわす可能性がゼロで、拡張したい場合、インタフェースも変える必要がある。
ただの手間でしかない。
クラス設計が正しくできているか疑いたくなる。
クラス設計したやつは、死ねばいいのに。
JavaScriptの実装を原則禁止
JavaScript使っちゃダメって言うんだぜ。。。
どうやって画面の要件をみたせっちゅうねん！！！
その現場で、ほとんどの画面はJavaScriptの実装が必要だったとさ。
死ねばいいのに。
このルールの意味が、ホンマにわけわからん。
JavaScriptでレベルが均等化できないのはわかるが、それはレビューでとれや！って言いたくなる。
ヘンテコルールを作ったせいで、開発を一時止めて聞く必要がある。
こんなルールを考えたやつは死ねばいいのに。
仕様変更が確定してないけど確定事項です
支援で開発に参加していたけど、仕様が確定してないのに設計かえるように強要してくるんだぜ。。。
そうしてにっちもさっちも行かなくなり、俺が責められる。
仕様変更が確定してもいないのに、命令出すんじゃねぇ！
死ねばいいのに。
共通処理を業務横断Ｔに申請したら、申請でクローズ
Redmineでタスク管理しているのだが、共通処理の作成依頼を申請したら、申請が通ってクローズ。。。
意味がわからない。
その共通処理が完成して、完成しましたの連絡をもらって初めてクローズだと思うのだが。。。
なんでそういう運用なのだろうか？
どうやって完成したことを伝えるのか、疑問でならない。
実は完成しているけど、伝えていませんがあったら、袋叩きにしてやる！！
Redmineを使ったことがない会社なんだろうね。
死ねばいいのに。
いつのまにか管理職に。。。
開発者としてアサインされたはずなのだが、いつの間にやら外部の会社との問い合わせ窓口に。。。
俺よりも地位が高い人が誰もやらず、俺にお鉢が回ってきた。
なんで誰もやらないの？
その地位にいて、恥ずかしくないの？
積極的に動いた奴が、最終的に責任の重いタスクをやるハメになる。
しかも、そのタスクはスルーしておくと他者の遅延になるため、優先度が自分のタスクよりも高い。
ただ、こなす能力があれば、チャンスでもある。
こなせていないので、ピンチなのが腹立たしいが。
こんな状況に追い込んだやつら、死ねばいいのに。
Getter, Setterに異様にこだわる
ただの入れ物クラスなのに、Setter/Getterを作ってないとダメ！みたいなことを言う。
ただの入れ物クラスなにに、そんなものは必要なのだろうか？
なんでも変数はGetter/Setterでとることがオブジェクト思考だとでも思っているのだろうか？
役割が明確なクラスに無駄なメソッドを追加すれば、タイピングが遅くなる上に、コード量だけあるシステムができる。
コード量が多いシステムが立派だとは思えない。
適切な設計をして、適切なコーディングを行えば、コード量は減るはずだと思う。
話が脱線したが、なんでもかんでもGetter/Setter使えと共用するアーキの人は、物事がきちんと見えているのだろうか？
とりあえず、お決まりだから作ってといっているなら、死ねばいいのに。
感想
もう、ただの愚痴になってしまった。。。
今の現場に対する不満が強い。
本当にシステム開発会社なのだろうか？
疑いたくなる。
自分が、今働いている会社は、大企業で正論を述べれば意見が通るけど、仕事を依頼してきた大元に対する不満が多い。
本当にシステム開発会社なのか疑いたくなる。
最後は、締めくくりに「死ねばいいのに」が常套句になってしまったな。
反応がよければ、もっと書こうかと思う。
末端のエンジニアの悲痛な叫びと疑問を、世間様に投げかけたい。
