技術選定 ~ となりのプログラマー
こんにちは。『技術選定』の話を書こうと思いますが、大きすぎるテーマに思われますので、今回は前の記事に書いた「いきなりレガシー」問題のみに焦点を絞ります。
いきなりレガシー
新しく作ったのがもうレガシーと呼ばれる、そんな様子を「いきなりレガシー」と表現しました。多くの場合、以下のような特徴を持っています。
過去のコードからのコピー&ペーストがある
自家製ユーティリティ集に依拠している
環境構築やデプロイについて手作業が多い
プログラミング言語やフレームワークのバージョンを上げられない
前任者が出世している
なぜそうなるの?
考えなく前例踏襲をするからです。より正確に言うと、前例の動機や背景について思いやることなく成果物のみを借用するからです。
まるで同じロジックがあるとは思えないし、あるとすれば共通化なり外部化されるべきではないのか?
そのユーティリティが製作された当時の制約がいまでも存在しているのか?制約が消滅あるいはより信頼性の高い解決法が出現していないか?
喉元過ぎれば熱さを忘れる。
ハッキーなソリューションはいつでも推奨されない!言語やフレームワークの思想を理解しよう。
無用な忖度はやめよう。実際、偉い人はただただ収益性の高いプロダクトを望んでいるだけだ。
受け継ぐべきは「知識」です
受け継ぐべき「知識」です。古いコードではありません。
古いコードの動機や背景を思いやり、ノイズを除去して、プログラミング言語やフレームワークなどのツールの思想を理解し、プロダクトの本質を知ることが大事です。
現在進行中のプロジェクトとしては、プロジェクトメンバーが「知識」を最大限に蓄えられるように工夫があるべきです。
将来また同じメンバーで仕事ができれば最高ですが、そうでなくてもそのような「知識」は組織のレイヤーにも透過的にレプリケートされていくものだと私は考えています。
おわりに
最後までお読みいただきありがとうございました。
あと一つ付け足しですが、思想を理解するとは、憶えるとか身につけるということではなくて、一緒に考えるという意味でした。
この記事が気に入ったらサポートをしてみませんか?