開発者の目から見たスタートアップ。 どのフレームワークを選択するのが良いですか

私たちは、人々が特定の操作を手動で行うことにうんざりしており、他の人がそれを行うためにお金を支払う準備ができている時代に生きています。 また、医師との面談、請負業者の検索、格安便、家の掃除、おいしい家での夕食の作成など、関係ありません。



これらのアイデアを結び付けるものは何ですか? 人々は仕事で稼ぐお金よりも時間を大切にし始めました。 同時に、完全にユニークなアイデアを持っている必要はありません。他のものより良いことをしたり、熱意を持っていることができれば十分です。



別の有望なスタートアップが出てきたという、インターネット上で多くの感動的な話があります。それはすでに数百万ドルの投資を得ています。 統一フロントエンドシステムプログラムが主催するプロモーション会議で、彼らは新製品やスタートアップの作成について多くのことを話し、コンテストの決勝で最高の銀行アプリケーションのアイデアを選択しました。







そして今日、私たちの投稿では、Sberbankのシングルフロントエンドシステムプログラムのフロントエンド開発のリーダーであるNikolai Nadorichevが、ある夜にスタートアップのビジョン、よくある間違い、Reactテクノロジーを使用したアプリケーションの作成方法について語ります。



開発アプローチ



スタートアップ開発について何を知っていますか? それはいくつかの段階で構成されています:



  1. 概念実証
  2. 投資をする
  3. チームの集まり
  4. MVP開発
  5. 投資家へのプレゼンテーションと新しいラウンドの資金調達


多くのスタートアップは、ベンチャーキャピタルファンドに行く前にMVPを開発しようとするミスを犯します。 これは、時間が経つにつれてチームのモチベーションが低下し、プロジェクトが光を見ない可能性が高まるという事実につながります。 これを防ぐには、いつ製品を停止して取り出すかを明確に理解する必要があります。 コンサルティング会社を見ると、会社のリソースの浪費を防ぐために開発時間がしっかりと固定されている場合、多くの製品が先行販売段階を経ていることがわかります。



チームには、潜在的な顧客とコミュニケーションをとるときにチームの利益を守る明確なリーダーが必要です。 さらに、製品の明確なビジョン、落とし穴や起こりうる問題を予測する能力も必要です。 技術的な面だけでなく、コミュニケーションの面でも。 大企業では、原則として、この役割は製品の所有者、中小企業ではチームリーダーが担います。



失敗の理由



スタートアップを思いついたのですが、クールですが、撮影はしませんでした。 なんで?



最初の理由は、広大さを把握しようとする試みです。 能力に自信のある多くの若い開発者は、スーパーヒーローのように感じます。 彼らは完璧なソリューションを作成しようとしますが、時間がかかりすぎます。



2番目の理由は、詳細なアプリケーションアーキテクチャの開発です。 常に、完璧なアーキテクチャを備えた完璧な製品を作成したいと考えています。 しかし、これは大企業でしか機能せず、1行のコードが書かれていない製品でも資金調達することができます。 そして、これはしばしばウォーターフォール開発モデルへの参照です。



ただし、投資家からフィードバックを取得するプロセスを遅らせると、コードの書き換えに莫大なコストがかかる可能性があります。 チーム内に柔軟な開発方法論を知っている人がいる場合は、 スクラムモデルに従って開発を構築すると役立ちます。 そのような人がいない場合は、開発方法論をまったく使用できません。 問題やタスクをすばやく解決するための十分な一般的なチームチャット。



技術スタック



枠組み



アイデアがありますが、今度はアプリケーションを作成する必要があります。 どこから始めますか? テクノロジーの選択に進む前に、必要なテクノロジーを決定する必要があります。



まず、プロジェクトで使用するフレームワークを決定する必要があります。 フレームワークの主な目標は、製品の開発に使用されるゲームのルールを設定することです。 フロントエンドの世界にはさまざまなテクノロジーがありますが、選択基準の概要を説明しましょう。





順番に始めましょう。 コミュニティサポートとは、アプリケーションの機能を拡張できるnpmパッケージの数、および外部開発者からのプロジェクトでのコミットの数を意味します。 次に、ITの巨人によるプロモーションに注目します。製品がどれほど優れていても、その認識は常に重要です。 製品の背後に巨大な企業が存在する場合、突然終了する可能性が高く、メガプロジェクトが多数のレガシーコードに変わります。 3番目の重要な事実は、開発の容易さです。 私の意見では、ここで追加のコメントは必要ありません。なぜ多くの開発時間を無駄にするフレームワークで開発するのですか? そしてリストの最後のパラメータは重要ではありませんが、成熟度です。 技術はどれくらいの期間市場に出ていますか? どのくらい積極的に開発していますか? これらの質問に「ずっと前」と「積極的に」という言葉で答えると、このテクノロジーがあなたに合っていると言えます。



これらの考慮事項に基づいて、統合フロントエンドシステムプログラムでReactを開発するための主要なフレームワークを選択しました。 なんで? すべてのポイントを見ていきましょう。Reactには、膨大な数のUI要素、アプリケーションの状態を管理するためのライブラリ、 その他のモジュールがあります 。 これにより、作業の一部を行わないようにすることができます。完成したコンポーネントを取得して、アプリケーションに埋め込むことができます。



さらに、Reactは簡単に習得でき、市場でそれを知っている多くの開発者がいます。 これにより、チームを編成し、すぐに戦闘に送ることができます。



すべての利点を備えたReactには、複雑なプロジェクト設定という形で軟膏が入っています。 幸いなことに、Facebookはこれを処理し、 Create React Appプロジェクトをリリースしました。 元々は、プロジェクトの迅速な開始に焦点を当て、アイデアからすぐに開発に移行しました。



ニコライは、会議のある夜にリアクションでアプリケーションを作成する方法について話しました。 ビデオの説明をご覧ください。





ウイキット



UIKitの開発のために別のチームを既に持っている企業だけが、独自のUIコンポーネントのセットを作成できるようにします。 UIKitがすべての製品チームによって共同で開発されたという既知の話がありますが、このアプローチには重要な欠点があります。開発者が多いほど意見が多くなります。 そして最終的に、これは各チームが自分自身の上に毛布を引っ張るという事実につながります。



しかし、私たちの目標は、MVPを短時間でリリースすることです。 広大なネットワーク上には、有料とオープンソースの両方の既製のソリューションが数多くあります。 人気のあるものがいくつかあります。





それぞれに独自のデザインがあり、どちらがより似ているかを選択するだけです。



MVP



または、Minimum Viable Productは最小限の実行可能製品です。 コンセプトの確認を提供する最小限のアプリケーションがあることを意味します。 その主な目的は、製品に生命権があることを示すことです。 データベースアーキテクチャの詳細な調査、高負荷、美しいデザインの下での作業は必要ありません。 多くの場合、彼は、タッチできるインタラクティブな画像を表示します。



そして最も重要なこと-プロジェクトの将来について常に考えることを忘れないでください。 製品が必要かどうか、その将来の見通しは何かを理解する必要があります。 そして、あなたが正直にこの質問に自分自身に答えるなら、それは戦いに勝ち、勝利する価値があります。 スタートアップに参加しようとしたことがありますか? 成功は何ですか? コメントでのディスカッションにご招待します。



All Articles