🤔

プロダクトのミニマム版を作って検証に役立てることはできないか?

2020/10/12に公開2

じつのところ、ただの思いつきです。皆様のご意見をお聞かせ願えればと思います。

たとえば、React + Redux + react-router + Webpack + etc... みたいな構成のプロダクトがあったとします。もちろん、Scala + Akka + etc... でもいいでしょう。

その構成を最小限にしたもの(削るとしたら画面とかでしょう)を用意し、これを「ひな形」とでも呼ぶとしましょう。ひな形に、画面とか色々なモノを付け加えたものが、プロダクトです。

ひな形が基底クラスで、プロダクトはひな形を継承した完全版のクラスのような関係だと考えればいいかもしれません。

基本的にプロダクトで使ってる要素技術の全てをひな形にも導入します。おそらく利用パッケージを完全に同一にしたモノが望ましいでしょう。

atomic design を採用してるなら、atoms/molecules までをプロダクトコードと同期してもいいかもしれません。

ひな形の用途

たとえば、Webpack4 -> Webpack5 みたいな大型アップグレードがあったときに、ひな形を使って雑に検証ができるはずです。

あるいは、特定ライブラリを別のライブラリに置き換えるような実験もしやすいかもしれません。

全くの新規機能の開発用環境に使ってもいいかもしれませんし、内部構造を変更するための検証にも使えるかもしれません。

つまり、さまざまな検証用のテストベッド[1]といえるものです。

問題点

  • 「ひな形」をどうやってプロダクト本体と同期を取るのか?(管理コスト)
  • 「ひな形」で行った実験はどれくらい確実にプロダクト本体に役立つのか?
  • 「ひな形」で実験を行う工数を捻出できるのか?

ぱっと思いつく問題点はこのようなところでしょうか?

「ひな形」をどうやってプロダクト本体と同期を取るのか?(管理コスト)

  1. ルーティング情報を元に、ページを最小限にまで削る。VSCode で注意深く依存関係を見て、依存がなくなったものを削除を繰り返す
  2. 「ひな形」とプロダクトは別々に管理し、プロダクトのパッケージ情報(Node.js なら package.json とズレが生じたら、自動で「ひな形」の修正を促す bot でも作っておく

「ひな形」で行った実験はどれくらい確実にプロダクト本体に役立つのか?

やってみないとわからない気がする。

そもそも、プロダクトコードにブランチを切って実験するのでもいいのかもしれない。あえていうと、余計な要素を切った状態で実験できるという利点はありそう。

「ひな形」で実験を行う工数を捻出できるのか?

一番の問題点はこれかもしれないが、まぁ最初は持ち出しでプロダクション検証をやってみつつ、利点を説明できるようにして、ねじ込むという流れか。

まぁ、問題はやはり 2 番の

「ひな形」で行った実験はどれくらい確実にプロダクト本体に役立つのか?

次第にはなりそうです。

まとめ

プロダクションコードから、余計な要素を省いて、技術検証を行うためだけの「ひな形」を作れば何か役立たないか?

ということを思いついたところです。

もし、何かアイデアや、見落とした問題点や、解決方法などを思いついた方がいたら、コメントなりいただけると幸いです。

脚注
  1. ナイツ&マジックを好きな方なら「トイボックス」といえば身近でしょうか。 ↩︎

Discussion

catnosecatnose

Webpack4 -> Webpack5 みたいな大型アップグレードがあったときに、ひな形を使って雑に検証ができるはず

たしかに、これができたら精神的に楽になりそうです。

僕もこの記事のような思想でひな形を作って「よし!このひな形を使い回すぞー」と意気込むことがあります。ただ、実際に開発を進めていくとヘビーなライブラリを追加したり、除いたりしてしまって、ひな形の原型が無くなり、検証コストが上がってしまう…みたいな結末を迎えがちです。そしてまた新しいひな形を作ったりしますw

記事に書かれている「VSCode で注意深く依存関係を見て、依存がなくなったものを削除を繰り返す」ができれば良いのですが、どうしても面倒になって時間が経つと放置してしまうという…

これは自分の技術力の問題でもあると思うので、ちゃんと設計できる人であれば問題にはならないのかもしれません。

erukitierukiti

やっぱり、最新状態との同期が面倒くさい(コストが高い)が先立ちますよねー。ひな形を低コストで作るためのノウハウが出来上がったらいいかもしれないですね