Java（Spring）のプロジェクトにぶちこまれて数ヵ月たったから振り替える。

ポエミオス。別プロジェクトから派兵されて数ヵ月経過した。
主にメンバーの教育について思うところ。知見。単なる感想がたまってきたので吐き出しておく。
あとあんまりJavaもSpringも関係ない。

目次

lombokこのやろう。

こういったものがあるのは知っていたけど、いまのプロジェクトではじめて出会いましたよlombok。
詳しい説明は他にまかせますが、GettetSetterなどだれが組んでもだいたい同じになるお作法的な部分を省略してくれる
便利なアノテーションを提供してくれます。

@Getter
private String id;

みたいにしとけば勝手に public String getId(); メソッドが生えてくれます。

お陰で？スコープやらカプセル化がどうとか。そういったことをから思考を放棄して、
情報量の少ないしゃべらないクラスをごりごりと生産してくれるので嫌いになりかけてました。
悪いのはlombokではなさそうなことに気づいてからは良好な関係を気づけてます。
いいとか悪いとかではないんだけど。そもそもわからないところを「呪文」として処理する文化があるので、
アノテーションはちょっとその「呪文」を信仰している層と合体するとえぐいんだ。
DelegateとかSuperBuilderとか場面はあるけどほしいときにいるとすごく頼りになるんだけどね。lombok。
ちょっと封印したい気持ちになったよ。
どこからそうなったのか、あるいは１側面ではそうなのかもしれないけど、
「オブジェクト指向⇒カプセル化⇒privateにしてgetterSetter 」みたいなのがそこらを歩き回っている。
この思想とlombokは合体しやすい。大変危険。とりあえず新人は救えたと思うけどほかの方は。

Mybatis is God

神。レジェンド。こっちも詳しい説明は他に譲る。
RDBがそもそも適切に設計はされていない。を前提によく練られていて素晴らしいと思う。
いわゆるO/Rマッパーのような使い方もできるだろうけど、もうちょっと柔軟性を持ち込めてなおかつ余計なものを書かなくてすむので、
ある意味前述のlombokとにたようなもんかな。
そもそもDBちゃんと設計し直せよ・・・見たいな不自由と戦うには必要かもしれない。
そもそもちゃんと直してほしい。リレーショナルなDBが関係性を明示できてないってどんなやねん。
ところが一度作られたDBはいろんな。本当にいろんな（Excel管理されてるとか。）理由で開発中であっても変更が難しく、
違うところがダメージを吸収してる。歴史的にそうやってインフラ層、DBの設計の外側で頑張り過ぎてるせいで知見がたまらず、まともにDBを設計できる人が育たなかったんじゃないかと推測しているが。
えぐいRDBはそこらじゅうにある。今なら思考を放棄してKeyValueストアにでも放り込んだ方がましと思えるような設計も多々ある。結局同じ闇を生むので放棄されたらこまるのだけれど。
MybatisとDB設計を主戦場にしたいぐらい気に入ってる。所属の会社的にはなかなかここをいじれる機会がないので、これはプライベートでちまちま積むしかないのが惜しいところだ。

コピペとのたたかい

２Outぐらいから考えたいが。一般的には３Outからだろうか。３度同じコードを書くのではない。
おい。Ctrl＋C、Vしろって意味じゃないんだちくしょう。
これとひたすらレビューで戦ってた基本的に敗北してた。勝てない。
コピペも呪文信仰と相性がいいらしい。ある意味オブジェクト志向らしいというか、再利用してるんだけど「違う。そうじゃない。」

思想レベルでのインプットはしんどい

思想とはいかに。仕事に思想を持ち込んではいけないのかもしれないが。
コードは設計書に書いてる風味でクラスはデータの入れ物で、あとはなんか適当な場所（書きたくなったタイミングでその当時さわっているクラスファイルに）メソッド開く。見たいなコーディングスタイルが身に付いてる人に別のものをぶちこむのは非常に大変だった。いまもぶちこめてない。あんまり思想に染まってない新人だけ引き込めたけど。

「納期　＞　品質」
これは仕事でやってるわけなのでその通りだとも思うんだけど。
品質を測る方法が曖昧なのをいいことにとりあえず納品するケースは多々あると思う。これは業界全体的によくないことだと
おもっている。最低限の品質が人によっててしかも測定しないってのはずいぶんだとおもう。
主に保守性に関する品質はガンガン犠牲になる。品質を犠牲に時間を生成することを覚えたプロジェクトは次第に「バグの密度」とかどうとか。そもそも納品してはいけないレベル、ものの品質を犠牲にしはじめる。
口を開けば時間がない。やむを得ない。ねぇのは「時間」じゃなくて「（私を含む）技術」だ。
といった具合でプログラムや設計の範疇から「自責他責」なんかの話までしなくちゃいけなさそうで、
なかなかである。いってることはわかるし全然理解できるけどね。
コーチするのはやってみたいけど、corachableなところまでもっていくのはなかなか大変ですね。ちょっと一人でやってると辛くなるからさすがに仲間がほしいなと思う。

レビューでなんとかするんなら覚悟しとけよ

そういったもの「品質」全般をレビューで確保するのは無理筋（範囲と責任が広すぎるぜ）
Lombokについても、コピペについても。基本的にはコードレビューで私が相手をすることになっていた。
相手にならん。私の全面敗北。つまり指示通りパンチしてた勢とやりあうにはレビューのタイミングでは遅すぎる。
先のカプセル化もそうだけどそもそも設計の知識なり経験も乏しかったりするんだ。そうなるともっと基本的な教育も必要になる。
OJTとかいうのりでコードレビューなんかで教育しだすとなかなかコミットされないしひたすら指摘が返却される地獄が生まれた。地獄になってたので基準を緩めたらお察しである。レビューで教育してはいけない。戒め。
覚悟とは地獄が生まれる覚悟でそれでも「品質」を維持する覚悟。上記のとおり「納期」が優先なので地獄が生まれただけになってしまった。
そもそも一定基準までレベルをあげる必要がある。教育の時間は別途とろう。IPAのプロマネ問題でもだいたいそうやって解決してる。そんな時間も予算も権限も俺にはないんだ。
Springの話は前半に時間とってやったのはよかった。ただ層や責任の分離はちょこっとやっただけでは理解できないしどうしようもないなぁ。

呪文使いのトラブルシュート

たぶんドリルかなんかだと思われてるのでだいたいに問題解決にぶちこまれる（割りと火力がないので弱点見つけてつるはしでえっちらおっちらやるタイプなんだが・・・あとは壁から逃げる。）
不明点を不明のまま「呪文」として処理する呪文使いは問題の切り分けも呪文であるがゆえに苦手としている場合も多い。
よって解決困難な問題がでてくるのだが報告も曖昧で（まぁ、正確に問題がとらえられるならそもそも相談になんか来ないんだろうけど）きつい。呪文使いのトラブルシュートはまずはこの呪文使いがその呪文をどうやって理解してたり解釈してるのかを想像したりする必要がある。こちらの言語も一部伝わらないので日本語なのに日本語が使えなかったりする（残念なことにこちらのいっていることも一部呪文なんだ。あちらから見れば私も十分に呪文使いである）
もちろん謎の呪文をつかって解決したことになっているので応用は聞かず。ほげぇってなる。なるけど頑張るよ。その人が悪いわけではないしね。

おわり

なんか辛い感じなったけど多人数プロジェクトは楽しいと思うし基本は楽しく仕事させてもらってます。
無力感もあるが学びもある。やってきてよかったなーと思うこともあればもっとやっとけばよかったなーなど。
設計スキル、保守の経験は貴重。もうちょいまともに人と一緒に成長する手段は確立しないときついなぁ。
Springすごく楽。手が足りねぇ。

参考にしている本とか

1. 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 増田 亨 https://www.amazon.co.jp/dp/B073GSDBGT/ref=cm_sw_r_tw_dp_W1WHSR4TZNKRW0FRYNH9
2. この1冊ですべてわかる 新版 コーチングの基本 コーチ・エィ　 https://www.amazon.co.jp/dp/4534056591/ref=cm_sw_r_tw_dp_BNR5PMY03HSPSQAKTFRE
3. 松岡さんの質問箱（ドメイン駆動回りとか。あれこれ回答してる。） https://peing.net/ja/little_hands