何言ってるの
Chefonline.ruは、 どんなに些細に聞こえても、料理のポータルです。 個人的で一般的なレシピ本があります。買い物リストを作成したり、メニューを計画したり、お気に入りを保存したり、集合的なブログに書いたり読んだりすることができます。恋人や共感者のためのその他の興味深く有用なサービスがあります。
ポータルは非常に若いですが、多くは行われていますが、多くはまだ開発中またはアイデアの形であるため、プロジェクト自体ではなく、その作成プロセスについてお話したいと思います。 私たちの経験がHabrの人々に役立つことを願っています。
ソースデータ
どうやら、私がどのように座って考えたのか、料理人や共感者のためのサービスを作成するためにどのようにアイデアが思いついたのかを詳しく説明しないでください。 私は料理が大好きなので、サービスは私のニーズとホテルの希望に基づいて行ったと簡単に言います。
開発の開始時には、次のリソースが利用可能でした。
- プログラマー、彼はタイプセッターです（I）
- デザイナー
- 独自のアンダーフレームワーク。これには、すでに多数のプロジェクトが実装されています
- 共有ホスティング
- Web開発およびプロジェクト管理の経験
- かなりの空き時間
開発中に使用されたもの：
- PHP5 fast-cgi + nginx
- MySQL5
- スマーティー
- JQuery
ドメイン名を思いついて、考えられる選択肢を列挙するのに1時間で苦労せずに登録しました。これは、哲学やトリッキーな「スタートアップ」を思い付くほどではないからです。 だから、chefonline.ruが生まれたと言えます
打ち上げの時点で、私は忙しいスケジュールでメインの仕事をしていた（そしてまだ持っている）ことに加えて、2008年の秋の危機はほとんど勢いを得ていなかった。 そのため、平日は約1時間、週末は数時間、プロジェクトに時間を費やしました。夜はプロジェクトの上に座って、週末全体で力も欲望もありませんでした。 一般的に、私たちはスタートアップとしてやったことだけを呼ぶことができます。ただし、ストレッチと用語の予約を除きます。
開発とアーキテクチャの開始
開発を始める前に、私は夜に座っていなかったし、アーキテクチャを設計していなかったし、技術的な解決策の選択に悩まされず、理想的なデータベース構造について殺されなかった。 サイトは私にとってかなり明確で理解可能な目標とニーズから生まれたので、私の頭の中のすべては、少なくとも高レベルで、あまり詳細に説明することなく、非常に明確に構築されました-設計しない場合でも、その後、プロジェクト中に終了してリメイクします。 数時間でデータインタラクションスキームを描き、データベース構造を投げて、ケースの大きなケースを見つけました。 多くのソリューションは長い間テストされており、疑いの余地はありませんでした。ほとんどすべてのモジュールのフレームは過去のプロジェクトから引き出されました。 それで、プロジェクトのアイデアの2日後にコードを書き始めました。
主な難点は、レシピブックのシステムとそのフレームワーク内でのユーザーの相互作用を考えることでした-1つのセクション構造を持つ一般的なもの、またはパーソナライズされたもの-ゼロから作成するなど、構造を編集する機能を持つ カテゴリにはツリー構造が必要です。 それまでの「フレームワーク」では、「NestedSets」を使用し、悲しみを知りませんでしたが、アルゴリズムはこの特定のタスクに適していませんでした-ツリーで一定の挿入と更新が発生する可能性があり、ネストされたセットはこれに適していません
たくさんの資料を壊し、ツリー構造にあるほとんどすべてのものを試した後、私はついに平凡な「id-parentId」を見つけましたが、再帰を選択しませんでしたが、JOINを通じて（方法はdklab.ruフォーラムで説明されています ）。
この方法にはいくつかの制限とニュアンス（特に、ネストレベル）がありますが、一般に、ネストレベル10の大きなベースでの合成テストの後（さらにネストの多いレシピ本はほとんど想像できません）、このアルゴリズムは私を満足させ、最終的に書かれました彼とのクラスワーク。 また、特に一般的なレシピ本からの読み取り速度を最適化するために、異なるカタログに従って一般的なカタログとパーソナライズされたカタログを配布することも決定されました-そのカテゴリは、サイトの公開部分に表示される一般的なレシピ本にも使用されます。
レシピカタログの構造に加えて、私はJqueryを使用することを心配しました。これは使用したことがなく、実際に楽しいものと有用なものを組み合わせました-フレームワークの開発と同時研究です。 Jqueryでのドックの読み取りとソリューションの検索は、開発時間の大部分を占め、PHPでのコードの作成は問題なく迅速に行われました。
プロジェクトのすべてのアイデアはリスト（スクラムの観点からバックログとも呼ばれます）に集められ、優先度順に並べ替えられ、2か月間のスプリントに分割されました。 したがって、4-6-10スプリントでポータルがどうなるかは明らかでした。これにより、アーキテクチャ上の決定の採用が簡素化されました。
デザインと使いやすさ
設計には最大の問題がありました。 設計者はプロジェクトに取り組みましたが、プロジェクトの作業が開始されてからわずか4か月後にデザインコンセプトが受け入れられ、その後2か月間の苦痛を伴う内部ページの編集と精緻化が行われました。 使いやすさは私たちの能力と知識を最大限に考慮して考え出され、この問題に最大限の時間を費やし、美しさと機能性のバランスをとろうとしました-結局のところ、判断するのはユーザー次第でした。
コンセプトの最初の結果を取得した後、深刻な危険が潜んでいました-それ以上のものを受け入れる場所がないため、何を受け入れるかという考えがありました-あなたが望む方法ではなく、少なくとも何か。 論争、主要な概念の放棄、さらなる修正と改善のために抜粋が十分であったことは良いことです。 かなりの数の改善がありました-コンセプトは3回やり直され、メインページは2回完全にやり直されました。そして、ささいなことで十分でした。
プロジェクトへの関与は、インターフェースの開発とその結果に大きな影響を及ぼしました-サービスのユーザーとして、私自身ができるだけ早くフィードバックを提供できました-必要なものと理由、置く場所、これがサイトの一般的なインターフェースに与える影響 開発者として、私が同じ道を歩むという事実を無視することは非常に困難であり、私にとって明らかであると思われる多くのことがユーザーにとって完全に自明ではないことが判明しました。 最初のベータテスターはこれに対処するのを助けてくれました、そして彼らに感謝します-多くの迷惑なバグとインターフェースの問題は彼らの助けで修正されました。 テストの最初のユーザビリティの結果によると、私たちが気に入って快適に感じた個人的なレシピ本がユーザーにとって完全に自明ではないことが判明したことを受け入れるのは難しく、少し残念でした。 もちろん辞任し、やり直しました。 それは私の過ちを認める良い経験でしたが、多くはありませんでした。
レイアウトの長いレンダリングに関しては、個人的な関係が何であれ、働く関係は常に上手く調整され、交渉され、合意される必要があることが示されています。 意識やテレパシーを期待することは無意味で有害です。 6か月間の非生産的な作業の後、それでも私たちはどのように、そしてどのように作業するかについて合意に達しました。 特に、毎週日曜日に私たちは自分の家で会い、ほぼ一日中静かな雰囲気の中でプロジェクトに取り組みました。そして夕方には新しい料理を試し、ビジネスと喜びを組み合わせました:)
実際には、視覚コンポーネントの作業結果はすでに推定されています。
パフォーマンスの最適化
最初は、大量のjavascriptと弱いホスティングがボトルネックになることは明らかでしたが、夏が近づくと、これはほぼ完了したプロジェクトのパフォーマンステストとストレステストによって確認されました。 以下の活動を実施することが決定されました。
- 専用サーバーまたは少なくともVPSをレンタルします。チューニングと最適化の可能性もあります
- ほとんどの統計とデータベースクエリをmemcacheにキャッシュする
- JavaScriptとCSSを組み合わせて圧縮する
その結果、プロジェクトをVPSに移行し、すべてを自分で構成する必要がありました（* nixシステムの管理経験なし）-これは、多くの経験と有用なスキル、そして自分が今の王であるという誤った感覚を学んだ魅力的なストーリーです世界の。 私の毎週の努力の結果、次のバンドルができました：nginx + php5-fastcgi + mysql5 + xcache + memcached。 これにより、サーバーの最適化のニーズを満たし（ボトルネックはまだVPSで変更できないカーネル設定であり、プロバイダーチャネルはやや弱い）、クライアントチャネルに切り替えました。
残念ながら、クライアントの最適化に関しては、計画どおりに多くのことが行われていません。 javascriptとcssの組み合わせ、DOMの最適化、http要求の数の最小化、キャッシュメカニズムの実装は完全ではありません。
合計
プロジェクトの開始から1年が経過しました。この間、私たちが望んでいたほど多くはありませんでした。私たちが望むよりも多くの間違いがありましたが、多くの経験が積まれました。 この経験はいくつかの論文で述べることができますが、実際には、共通の真実によってもう一度確認されています。
- サブジェクト領域へのプロジェクト参加者の関与は、プロジェクトにとって大きなプラスです。
- プロジェクトの実装を先送りして、計画と設計に深く入り込むことは必ずしも価値がありません。 反復的な開発、頻繁なデモンストレーション、最大限のフィードバックの取得-このために努力する必要があります。
- 最初のプロトタイプのサービスを（エンドユーザーとして）使用すると、将来の多くの問題を回避できます。
- チームメンバーのモチベーションのレベルが異なる場合-コミュニケーション、共通のアプローチの開発、問題を特定した後すぐに解決する、遅らせたり「黙らせ」ようとしない-それ自体は解決しません。
- 完璧主義とプラグマティズムの中間点を見つけることが重要です。場合によっては、痛みを伴うリファクタリングによって将来の時間を大幅に節約できます。また、過度の退屈さは、改善の沼でプロジェクトのリンクにつながる可能性があります。
- 自転車の数が少ない-すべてがすでに私たちの前で発明されており、数年前にプロジェクトを始めていて、既存の素材や他の人の成果を使用するよりもはるかに多くの時間を自分の自転車で考えていたら、私はこれを自分ですでに実現しているのは良いことです。
- ネガティブフィードバックを恐れずに、プロジェクトを自由に見せてください。これは非常に重要なフィードバックであり、初期段階で取得するほど、最終製品は良くなります。
- 開発単独または友人の小さなチームでの開発は、開発プロセスを無視できるという意味ではありません。 私たちは多くのスクラム技術を使用しており、これを時間や過剰な無駄だとはまったく考えていません。逆に、私たちは常に肯定的な側面を観察しています。
- プライマリUGCに依存しないでください。プロジェクトを開発するときに、それを埋めるための計画が必要です。
更新：コメントやサイトのフィードバックで見つかったエラーについて書いたすべての人に感謝します。 もちろん、間違いについては恥ずかしく思いますが、後で修正するよりも早く修正することをお勧めします。 また、サイトのデザイン、使いやすさ、技術的な部分について有用で合理的なコメントを述べてくれたすべての人に感謝します。