原文:The art of over-engineering your side projects – Liam Symonds
お金を稼ぐことを目的としたプロジェクトのアンチパターンのお話。
筆者はそのようなプログラミングの傾向として、過剰な機能をもたせすぎるとしている。
そのようなアンチパターンを撲滅するために、筆者がかつて経験した間違いを列挙している。
- プロジェクト管理
- 過剰に設計されたインフラ
- 技術の引き出しへの心配
- 独自フレームワークの作成
- 継続的機能提供
1. プロジェクト管理
素晴らしいアイディアとどのようにそれを達成するかの見通しを持っているとして。
論理的に、アプローチの計画を並び替えたものをひとまとめにしようとする。
しかしながら、当初の計画にフォーカスしすぎてしまい、「プロジェクト管理」という罠に落ちてしまっている。
つまり、顧客のストーリーを描いたり、バックログの作成やまだ始まってもいないプロジェクトのツールを探し出したり、質実な管理のために大量のお金をかけたりしている。
解決策:
未だ存在しないプロジェクトを管理しようとしないこと。
アイディアとざっくりした時期間だけをノートに書き留める、これだけで良い。
2ヶ月後にそのプロジェクトで何をしているのか予測し始めたとしても、予測通りに行くことはほとんどない。
2. 過剰に設計されたインフラ
プロジェクトの見通しが立ち、その未来を考えられるようになると、
「サービスに100万の人が訪れるようになったらどれくらいスケールすべきだろうか?」とか
「どのようにマルチゾーンの冗長性をもたせようか?」とか
「100%の稼働率をどのように達成しようか?」などと考え始めるかもしれない。
読んでいる人の中にはバカげていると感じる人がいるかもしれないが、その感覚は正しい。
多くの人々は、ユーザー数が適正になるよりも前にその要件を満たすような行き過ぎたインフラ構成になっている。
解決策:
まずは実装すること。
実装したら、アプリケーションが動く最低限のアーキテクチャに展開すること。
多くのユーザーを獲得し、モニタリングをして、負荷と冗長性を考慮したインフラに変更すること。
3. 技術の引き出しへの心配
多くのエンジニアは潜在的な顧客が裏側でどう動いているかを気にしている、と考えている。
顧客はRubyで動いていようが、GoだろうがPHPだろうが気にしない。
気にしているのはパフォーマンスと目的を満たせるかどうかだけである。
解決策:
自分の書きやすい/経験のある言語で書くこと。
4. 独自フレームワークの作成
Bootstrapはつまらないし、Materializeは大きすぎるし…。Foundationはなしだな…。自分で作ったほうがマシだ。
以前はそのようにも思ったけれど、一度完成させてみるとそのような願望はなくなっていた。
解決策:
フレームワークを使って、それをカスタマイズすること。
自分が明確に必要な部分だけをリファクタリング/ビルドをして。
5. 継続的機能提供
「2. 過剰に設計されたインフラ」と似ているが、何一つ提供する前に、継続的に機能を提供する仕組み設計してしまう。
JenkinsやDrone, Travisは素晴らしいツールであるが、それらの設定に時間をかけるよりも、稼働させるべき。
解決策:
まずはビルドする。それから継続的機能提供を考える