プログラマーはより改善しようという気概に溢れた人が多いです。なのでプログラミングに慣れてくると、どうにかそれを改善しようと思うことがあります。
これは多分麻疹みたいなものだと思うんですが、20代後半くらいのそこそこデキる人でよく見かけます。たぶん中二病みたいなもんです。「俺が改善してやる」となるわけです。
しかし失敗する、なぜか?
経験的にそのアプローチは失敗します。
見事に失敗して途中でやめるか、押し通してぶっ壊れるか、本人は失敗したことに気づかないか、と言うケースが多いと思います。
原因は、改善対象となる課題は1つではないからです。
- 速度、軽量さ
- メモリ使用量
- コードや設計の美しさ
- 読みやすさ
- 開発速度
- 開発品質
- 開発コスト
- メンテナンス性
- 継続性
多くのアプローチは、いずれかの課題を少し改善し、トレードオフとして何かを失います。その失ったものに対して注意が向かないと失敗します。
最も多いのは引き継ぎできない、しづらいコードができあがることです。本人にしか触れないというパターン。
失敗しないためには
まずどのような課題(パラメータ)がプロジェクトに存在するかを知らなければなりません。
そのためにはプログラミングだけでは不十分で、プロジェクト管理の立場や事業戦略の立場、チームビルディングの立場など、様々な角度からプロジェクトというものをよく知る必要があります。
その上で、該当案件の状況をヒアリングし、その方法を用いた場合、トレードオフとして失うものは何かを考え、理解する必要があります。
これらを突き詰めるとテックリード、システムアーキテクト、CTOの仕事の一部になってくるのだと思います。
もう一つの解
トレードオフでどのパラメータにも害を及ぼさない方法を見つけるのもよいと思います。
しかしこれは非常に難しいことで、一朝一夕にはできないのではないでしょうか?
やりがちなオレ流
我流とか・オレオレフレームワークが基本的に悪しき文化だ。というのは割とこの業界広まっていると思うのですが、新しいアーキテクチャーパターンや、デザインパターンには無防備だと思います。
新しいアーキテクチャーパターンやデザインパターンでも、このトレードオフは発生していて、何かを改善するために何かを犠牲にしていることがあります。何を犠牲にするかを慎重に検討し、わからなければ(チャレンジしづらい状況なら)諦めて普通に書くのが良いのではないでしょうか。