いやあ。
仕事に疲れました。
いや、でも仕事はやめないです。
以下、持論です。
エンジニアは勉強し続ける職業
僕は、エンジニアに就職したんですけど。
エンジニアって、勉強し続ける職業だと思うんですよ。
いや、究極的にはどの職業もそうだと思うのですが。
エンジニアはその色が特に強いのかな、と。
勉強。
してますか？
うーーん。
僕は大学院まで紙とペンで数学やってて。
プログラミングなんてやったことなかったのもあって。
プログラミングの勉強を始めたときは面白くて面白くて、仕方なかったです。
いままで自分がただただ利用していたwebサービスや色んなアプリも、誰かが汗水を流して作ったものなんだな～と思ったり、多分裏でこういうものが動いているんだな～ってわかったり。
その帰着として、そういうものを作ってみたいと思ったりしていました。
こういう「○○したい！」っていうのは、別にプログラミングに限らず、勉強の大きなモチベーションになります。
プログラミング学びたての僕は、そういう「○○したい！」でビンビンでした。
仕事以外にもプライベートでテキトーなプログラミングを書いたりして、まあ、勉強できて。
それがあまり苦ではなく、一年目は結構楽しく終わったんですよね。
ここまではいいんですけど。
2年目くらいから残業が多い部署で仕事が始まって。
まあ、プログラミングが楽しい～～～！！って時期だったので。
最初は楽しかったんですよ。
多少残業しても。
あるときから、
プログラミング楽しい
という気持ちが薄れていきます。
クソコードで殴られ続けると人間は病む
僕がやった仕事は、いわゆるクソコードの機能改修でした。
クソコードというのは何なのか。
僕が思うに、以下の要素を含むものです：
- ユニットテストがない
ユニットテストは、各機能がどう動くかを保証するもの。それがないから動作が保証されない。
- ユースケースがない
ユースケースは、各機能の使用方法。どう使用できるかがないから、迂闊に使用できない。
- インターフェースがない
インターフェースは、機能の抽象化。どういう機能かが抽象化されていないから細部まで読まないと全貌を理解できないし、細部の変更による影響が広く波及する。
これらの要素を含むコードを直すと、
「あれ！この不具合を直したのに、今度は別の不具合が！」
だったり、
「エラーが起きたけど、原因がわからないや！」
だったり。
そういった、理不尽な問題が起きるわけです。
理不尽ですよね。
エンジニアって、機械みたいな合理的な判断するイメージないですか？
できないんですよ。それが。
ちなみに、こんな要素を含むがんじがらめなコードを
なんて言ったりしますが、上司がそういうコードを見るたびに
「これはスパゲッティだね～」
みたいにかっこつけた感じで言うのがむかつくので、僕はクソコードって呼んでいます。
暴走族もぶんぶんバイクパーティーみたいに呼べば憧れの的じゃなくなるんですかね？
リファクタリングのススメ
はい。
これらの理不尽を解決するにはどうしたらよいか。
リファクタリングが重要なんです。
リファクタリングというのは、コードの機能をそのままに、変更可能性や可読性の向上を図る行為だと認識しています。
つまり、文章で言う推敲です。
ただ、すごく当たり前なんですが、顧客が求めているのは目で見える機能であって。
それがどういうコードで書かれているかに関心はないわけです。
なので、顧客に
「えへへ、リファクタリングの時間ください」
というのは、結構難しいわけです。
時間がかかるのに、提供される機能は見かけ上変化がないので。
お金を払う側は気が乗らないわけです。
そんなこんなで、リファクタリングもできずに半年近く、クソコードにあれやこれやしてきました。
じゃあリファクタリングをしないのか？
って話なんですけどね。
変更可能性がないと、
「やっぱりこういう機能欲しいよね～」
とか、そんな場面ですぐ対応できませんよね。
結局のところ、便利にものを使いたい側のユーザが便利なものを提案・要求できなくなるわけです。
コードの可読性が低いと、
「○○さんじゃないとこれ直せないんだよね～」
とかなってしまいます。
仮にプロジェクトに100人いても特定の1人しか直せないのであれば、人員リソースが意味がないのです。
もし、別の担当者が勇気を出して手を出したとしても、意図を読み違えて誤った修正をしてしまうかもしれません。
さらに動作が保証できなくなってしまえば、それが致命的なバグにつながるかもしれません。
まあ、リファクタリングをするのは大事なんです。
本当は、お金をもらってでもするべきことなんです。
品質向上ってやつです。
でも、なぜか、リファクタリングの大事さは理解されません（少なくとも周りの人間は理解してくれませんでした）。
重要性を資料にまとめて説明したりもしたのですが、どうも響かなかったようです。
かなしい。
そもそもソースコードに「正解」はない
とするから手間なのであって、はじめから
を書いてしまえば、たしかにリファクタリングの必要はないです。
かしこい。
が、それは不可能です。
ソースコードに「正解」はないです。
文章の推敲と同じで、この文章が正しいというものはないです。
ただ、確実な「不正解」、アンチパターンとでもいいましょうか。
それはあるんです。
そして、自分がいったん落ち着いたときや、第三者がレビューを経て、それらは自覚されるものです。
逆に、自分が落ち着いて推敲する時間＝リファクタリングの時間や、第三者のレビューの時間がないと、コードはアンチパターンを多くはらんでしまう可能性が高まります。
リファクタリングの目的は「正解」を探すことではなく、「不正解」を避けることです。
「正解」を探すことと「不正解」を避けること。
似ているようで全然違う。
勉強の意味を見出せなくなってしまった
確実な効果が期待できるリファクタリングの時間を設けましょう！
という呼びかけが断られ続け、明日は動くか不透明なコードを書かされ続けて、どんどん勉強の意味が分からなくなりました。
その間半年。
「正解」に近づくことはおろか、「不正解」を避けることもさせてもらえない。
うーーん。
半年もその環境にいると、ポジティブなことなんて起きるわけがないんですよね。
1年前は「○○したい！」だったのが、いまは「○○したいけど、どうせできねえからな～」となってしまいました。
こうなると、モチベーション下がりまくりですよね。
困難にぶつかるたびに、その解決策を調べて学んでいるのですが、それってマイナスを0にするような、ポジティブなモチベーションじゃないんですよね。
ずっと困難がある。
それはストレスですよね。
じゃあ、僕が間違いなのかって話で
絶対僕が正しいです。
アンチパターンを踏みまくる同僚、それに気づかない同僚、見て見ぬふりをする同僚。
おまえらが絶対悪です。
でも、正論をぶつけるとなぜか浮いてしまいます。かなしい。
こういうのがいやだったから、アカデミックに行きたかったんだなあ…
うーーん。
これまでは自分をだましだまし、
動くものを納期に間に合わせるのが大事だよね～～～
と思いながら、今日までやってきましたが、さすがに最近は限界です。
なんで、周囲の不勉強に僕が迎合しないといけないのか。
というか、そもそも
動くものを納期に間に合わせるのが大事だよね～～～
じゃねえんだわ。
正しくは
動く高品質なものを納期に間に合わせるのが大事だよね～～～
なんだわ。
だから、僕は絶対に正しい。
そんなこんなで
上記みたいなことをずっとぐちぐち言って。
最近、半年近く触れていたクソコードを、何とか周囲を説得して、年明けからリファクタリングの時間を設けることに成功しました。
で、リファクタリングそれ自体も成功し、それからすいすい機能改修できて、めちゃめちゃ調子いい～～～♪って感じだったんですが。
それはあくまで僕自身の話で、周囲は別にそうではなく、相変わらずリファクタリングやコードレビューをおろそかにしながらクソコードを量産し続けて。
そのうちのひとつ、別のクソコードの機能改修が回ってきて、ストレスがぶきゃぶるるって感じになってしまいました。
こういう絶望感はやばい。
来週からどうしようかしらね。
--------------------------------
このままだと、ただの愚痴になってしまうのですが、学んだものはそれなりにありました。
ただ、時間は有限だし、できれば学びたいことを学びたいよね、って話です。
学びの内容って大切で、主体性に関与すると思うんですよね。
主体的に学んだもののほうが身につくので、できるだけ、モチベーションと内容のミスマッチは避けたいですよね。
学びの内容がミスマッチでもいいのですが、その場合は別のモチベーション、つまるところの給与をください。
3億円ください。
いや、やっぱり4億円。
…5億円。
…ざわ……ざわ…
6億円！！
7億円！！
さあ、どんどん値段が跳ね上がっています…
???「66兆2000億円」
周囲「！！！」
落札ッ！！
周囲「馬鹿な…」
周囲「三角関数ちゃそにあんな巨額な給与だなんて…」
周囲「そうよ！！あんなオワコンツイッタラーにもったいないわ…」
まんげ（〆の陰毛）
