すべてのライブラリに実プロジェクトが必要な理由
多くのライブラリ開発者は間違いを犯します。サンプルがあれば十分だと考えてしまうのです。
サンプルだけでは不十分です。
サンプルは機能が動作することを証明しますが、実プロジェクトはライブラリが機能することを証明します。これらは全く別物です。
私は多くのデモアプリケーションを作成してきました。サンプル用のウェブサイト、API、コンポーネントなどです。デモではすべてが完璧に見えます。デモはハッピーパス（理想的な実行経路）を示すものです。理想的なワークフローを示すのです。
デモは制御された環境です。アーキテクチャはシンプルで、要件も予測可能です。
実プロジェクトは異なります。
実プロジェクトでライブラリを使用する際、ルールは変わります。もはやデモンストレーションをしているのではなく、問題を解決しているのです。
実プロジェクトには以下のような要素が伴います：
- 厳しい納期
- 変化する要件
- 複雑なレイアウト
- エッジケース
- ヒューマンエラー
ここでライブラリの真の強みと弱みが明らかになります。ライブラリの本質が露呈するのは、デモの中ではなく、プレッシャーのかかる場面なのです。
実プロジェクトは、あなたの思い込みを暴き出します。机上の空論としてはエレガントに見えるアイデアも、開発中は理にかなっているように思えるかもしれません。しかし、現実に直面すると話は変わります。
ワークフローに違和感を覚えたり、設定が冗長に感じられたり、APIが不自然に感じられたりします。設計が間違っているわけではなく、まだ現実に即していないだけなのです。
開発者ができる最善のことは、自分自身のソフトウェアのユーザーになることです。単にデモを作るだけでなく、自分のツールを使ってウェブサイトやアプリケーション、さらにはビジネスを構築してください。そのツールに依存するのです。
自分のソフトウェアに依存するようになると、視点が変わります。開発者としての思考を止め、ユーザーとしての思考が始まります。
ユーザーが重視するのは以下の点です：
- 摩擦（使いにくさ）
- 明快さ
- タスクの完遂
本物のものを作ることで、問いが変わります。「どんな機能を追加すべきか？」と問うのをやめ、代わりにこう問いかけるようになります：
- なぜこのワークフローは使いにくいのか？
- なぜ同じことを繰り返しているのか？
- なぜこれに時間がかかりすぎたのか？
これらの問題を解決することは、どんなブレインストーミングよりも優れたソフトウェアを生み出します。
すべてのライブラリには実プロジェクトが必要です。このプロジェクトはマーケティングのためのものではありません。それは「試練の場」なのです。ライブラリに現実の問題を解決させ、ユーザーが気づく前に弱点を見つけ出すためのものです。
目標は、ライブラリが完璧であることを証明することではありません。目標は、ライブラリが改善していくための道筋を作ることなのです。
Source: https://dev.to/stinklewinks/why-every-library-needs-a-real-project-1ae7