僕はYAGNIを大事にしたい
ポエムです。
YAGNIの原則なんて、もうさまざまな場所で記事にされていたり、議論されているので
今更新しいことなんて書けないとおもっているので。
今後一緒に働く可能性があると思ってくれている人がこの記事を読んで、
- 栗田さんってこんな考え持っているのか。
- めんどそうな人やな。
- ええやん、その価値観。うちで働こーや！
ってのをジャッジしやすいように記します。
共感してくれる人はいいねかオファーください。笑
「だろう」の開発はやめよう
開発リソースは限られています。
AI時代だったとしても、今のところは結局はエンジニアに依頼しないと作れません。
特に開発をした経験が少ない人だったり、meceなんて言葉が好きな方は、
あれもこれも、全部やっとかなきゃ！もれなくやらんと！
という思想であらゆるパターンを想定した依頼をしてきます。
...でも、それって本当にあり得ますか？
...ピボットやクローズ等々するまでに、本当に使いますか？
既にユースケースが存在していて、すぐに発生しうるものなら対応はした方がいいと思います。
でも、それが年単位で結局使うことになる「だろう」からという感覚で実装すると
結構痛い目を見ます。
- 作った人以外は、「なんでこれ作った？」となる(コードリーディングのノイズ)
- 過去の「だろう」で作った仕様が、未来の別の機能開発に干渉する
- 使われていないままサービスクローズ...(何のために作ったんや...)
特にエンジニアは、作った機能が日の目を浴びないっていうことに
落胆する人は多いと思います。
ビジネスサイドの意見が強かったりすると、作らざるを得ないこともありますが、
エンジニアサイドの心証はあまり良くないと思うので、その点は留意していただきたい。
運転は「だろう」ではなく「かもしれない」発進をしろなんて言いますが、
開発は「だろう」でも「かもしれない」でもなく「今欲しいから」で発進したいものです。
未来のことは考えないわけでなく、「実際に使う時の最適解」で実装したい
じゃあ今やること以外は作りたくないってか！わがままなやろうだぜ😡
っていう話ではなく、将来そういうことが発生すると想定した設計にしといてね。
という対応は全然いいんです。
例えばユーザーが退会処理を行ったとして、再登録処理をするといった際に
過去のデータを引き継げるようにしておきたい。みたいな話であれば、
🙆 再登録時に連携できるように論理削除にしとこ。ステータスはbooleanじゃなくてenumの方が後で再登録ってフラグ増えても対応できるな。
🙅 再契約を処理実装...(1年後)え？やっぱり過去のデータで連携すると問題があるから新規作成？じゃあ再登録じゃなくて登録でええやん！作った意味...😭
ってなるんですよね。
場当たり的な実装をして、過去の自分のコードに憤慨はしたくないものです。
(といっても、半年前の自分のコードはいつ見てもクソコードだと思ってしまいます。笑)
プロダクト開発は常に仕様が変わります。
設計思想やツールも日々アップグレードします。
その時に最適だったものも、すぐに枯れ果て、新しいものに置き換えられます。
そんな状態で、「今やる」と意思決定していないものを今作ってしまうと、
いざ使うとなった時には時代遅れなやり方になっていたり、
隠れたバグの温床になっているみたいなこともあります。
そん時に後悔するのは僕なので、できればそういう開発をしないように。
今だと3人/日かかる実装も、実際使う時には1人/日で済むようになっている、
なーんて可能性あるから。その方が開発リソース抑えられてお得でしょ？
終わりに
とはいっても。
同じエンジニアコミュニティにいる人も、
「人にはそういうけど、個人開発だとやっちゃいそう」っていってて、
これはあるあるだなぁと思いました。
今作っている個人開発も、ちょっと気を抜くとスタイルやパフォーマンスの
こだわりとかに時間を取られてなかなかリリースできないなんてよくあるので...
そうならずに、しっかり「今必要なMVPを作りきってあげる」を意識して
開発していけるようにしたいと思います。
あ、今エンジニア超特化型のポートフォリオサービスを個人開発しているので
また宣伝させてください。
Discussion