最初に入札に勝たなければなりませんでした。 これを行うには、最小限の貴重な製品を迅速に提出する必要がありました。 そして、ここに私たちの顧客にとってまともな金額を要する最初の間違いがあります。 このように聞こえます：すぐにMVPを切り裂きます。 顧客は結果をすぐに見たいと思っていますが、これは優れたインフラストラクチャ、信頼性の高いアーキテクチャを犠牲にし、1年後にフロントエンドアーキテクチャに重大なリファクタリングが必要であるという結論に達したことを意味します。 約数ヶ月。 そこで、500,000ルーブルを漏らしました。
振り返ってみると、最初にすべきことは、数年後に顧客が最終的に見たいと思っていたすべての機能を考慮することだったと自信を持って言えます。 したがって、「このアーキテクチャはこれを提供しません」というスタイルのアーキテクチャエラーを回避できます。 その結果、各主要チップは深刻なリファクタリングを必要としました。
入札に勝つために、当社は、大規模なアプリケーションと信頼性のある拡張可能なシステムを設計した経験のない開発者を派遣しました。 明確なビジネス、入札は注文ではなく、優秀な人材を散らしたい人はいません。 しかし、（クラスレベル）に技術アーキテクトがいないため、アプリケーションがスパゲッティコードになり、SOLID要件を満たせなくなったという事実につながりました。 そして、ここに各顧客のエラーがあります。 チームのリソースを増やすことなく、一定の開発ペースを維持することはできません。 アジャイルの原則「投資家、開発者、およびユーザーは、一定のリズムを無期限に維持できる必要があります」は、要件が最初からわかっており、機能のセット全体、信頼性と拡張性のあるアーキテクチャが設計されている場合にのみ機能します（つまり、各クラスが最終的なシステムの機能）および明確に定義されたプロセス。 そして、これは製品を見る前にMPVで行わなければなりませんでした。 それ以外の場合、線形時間では、アプリケーションの複雑さが指数関数的に増大します。 これは、1年のギャッシュ機能のコストが最初よりもO（e（N））高くなることを意味します。
私たちのチームでは、唯一のデザイナーはリモートの従業員でした。 それは重大な間違いでした。 リモートの従業員は常に自分の人生を生きています。 彼は自分のデザインを美しく、うまく描きます。顧客は幸せです。 しかし、これらの魅力はすべて、最終的には同じ論理形式でN個の異なるスタイルと組版を持っているという事実に要約されます。 最初から、特定のフレームワークを定型化するという要件を置く価値がありました（Ant Designがありました）。 何かがそこになければ、そこにあることをしてください。 顧客は、Reactはブロックコンストラクターであると考えていました。 そして、彼はまだ私たちが4日間原始的な形を見ている理由を理解していません。 Reactはコンストラクターですが、開発の最初に類似した再利用可能なコンポーネント（UIフレームワーク）のセットがある場合のみです。 レイアウトの経験のないデザイナーは、自分でこれを行うことはありません。 開発者はこれについて顧客に決して伝えません。 これにリーダーが続きます。 そのため、フロントエンドチームのリーダーは、以前のようにバックエンドではなく、過去のフロントエンド開発者でなければなりません。 したがって、完全に機能するアジャイルチームには、それぞれの作業領域（FE、BE）に有能なリーダーを含める必要があるという結論に達します。 これらのリーダーは、この記事で説明しようとしていることを顧客に伝えるために、強力なソフトスキルを持っている必要があります。 そして、これは非常に困難です。
最初のリリースをリリースしたとき、デモの最終日には常に何かが壊れていることに気付きました。 開発年を通して、各リリースブランチは地獄のような松葉杖のセットになります（オフにして削除します）。その後、魔法のように開発ブランチになります。 そして、一連のコミットがあります（これをオンにし、オンにします）。 1年後、明確な分岐ポリシーを持つ必要があるという結論に達しました。 しかし、最も重要なことは、既存の混乱を排除する責任者です。 これは、顧客の混oticとした欲求を和らげるため、または混bugとしたバグを和らげるため、または各スタンドで何らかのグラフィック機能またはボタンを無効にする独自の構成を持つことを意味しました。 ifステートメントで各ボタンをラップするのはおかしいです。 プラグイン機能モジュラーフロントエンドアーキテクチャ（無効-有効）が必要であるという結論に達しました。 私は長い間、このようなアーキテクチャを実現する方法を考えてきました。 しかし、私が確かに知っていたことの1つ。 完全なコンテキストが必要でした。 そのため、js-beansライブラリが誕生しました（https://www.npmjs.com/package/js-beans）。 各スタンドには独自のJSONコンテキストがありました。 プラグインは、プロキシパターンを介してチェーン（チェーン）で収集されました。 そのため、たとえば、データソースを個別のビンとして使用し、このビンを置き換えるプロキシビンとしてさまざまな変換を行いましたが、それを自分自身に注入しました。 たとえば、FPSのパフォーマンスをテストするためにデータモデルをスケーリングする必要がある場合、jsonファイルでスケーリングプラグインを有効にする行を追加するだけです。 プロダクションで何かが壊れましたが、それはローカルで再生されません。スタンドを再構築せずに1行でロガーをオンにします（スタンドは約20分かかります。 または、破損する可能性があるためにモジュールをすぐにオフにする必要がある場合（コンテキストでオプションのBeanを無効にします）。
時間が経つにつれて、私たちのスタンドは1週間オフになりました。 フロントをローカルで開発することは不可能でした。 Mokaの自律アーキテクチャは提供していません。 私はきしみで痛みを切り裂かなければなりませんでした。 今振り返ってみると、私は最初からそれをやっていただろう。 しかし、MVPがあり、深いエンジニアリングなしでコードを書くことを余儀なくされました。 しかし、顧客は私たちを専門家と考え、エラーなしですぐにコードを書くべきだと考えました。 これは次のエラーです。 会社の名前は、チームのプロ意識について語っていません。 チームのプロ意識は、チームリーダーのプロ意識によって決まります。 チームに技術リーダーがいない場合、1年でプロジェクトは停止します。 したがって、さらに数百万をマージします。
リモートアーキテクトがいました。 しかし、彼について知っていることはただ1つです。 ウラジミール・タラソフによると、リーダーの開発の最終段階。 これで私たちの建築家は完璧に達しました。 間違い番号N：クラスレベルでシステムを設計するテクニカルアーキテクトがいない。 立ち止まっている場合、助けを求める人はいません。 経験豊富な他のチームに助けを求めてください、と顧客は言いました。 しかし、何らかの理由で、他のチームには私たちを助ける時間がありませんでした。 私たちのPRは2か月目を迎えています。 私は彼を切り倒す勇敢な男がいることを心から願っています。 その結果、人生は私たちのコードに、あらゆる場面で魔法や松葉杖の形で豊富な超常現象をもたらしました。 1つだけが欠落していました。 特別な注釈Magicおよび@Kostyle。 次のESのための良いアイデア。
私たちは、このプロジェクトでより多くのミドルと少ない男性がより収益性があると判断しました。 今、私たちは異なった考え方をしています。 予算が少ない場合は、最も高価な専門家を雇う必要があります。 私たちのように予算に問題がなければ、専門家を安全に節約し、Code Reviewをサイキックの戦いに変えることができます。
四半期ごとの締め切りに間に合うと思いました。 今、私たちは異なった考え方をしています。 要するに、私たちはプロジェクトを書き直す必要があります。 そしてできればゼロから。 私たちの顧客がこれについて決して知らないことを願っています。 結局のところ、私たちは最近、豪華なチームビルディングを持っていました）
私たちは、専門知識がほとんどない新技術をいじることに決めました。 彼らは私たちに推薦されました。 もちろん、経験を積むことを望んでいました。 今では、私が経験している技術のみを使用する方が良いと思います。
8時間の就業日に基づいて見積もりを出しました。 実際には、見積もりは4時間の就業日に基づいて行う必要があります。 お茶を入れたり、面白い話をしたり、ナビゲーターでトイレを見つけたり、電話で話したり、通信したり、新しい技術を研究したり、最も重要なことにはチーム内で熱狂的な論争をしたりする人はいません。 後者はおそらく最も避けられず、最も高価です。 正直なところ、オープンスペースの場合は、まだ数時間を投げる必要があります。 絶え間ない話はひどく集中力を低下させます。 このすべてを理解している顧客は幸いです！
とにかく私たちの見積りは使い果たされ、退屈な技術論争に変わりました。 集会の効果は最小限でした。 しかし、私たちは解決策を見つけました：おいしいピザ。 おいしい匂いが鼻を刺激すると、人は自分の考えをより明確に表現し始めます。
最初は小さなチームが1つ、次に大きなチームが1つでした。 計画には2〜3時間かかりました。 立ち上がり30分。 私が私たちのPOを尊重しているのは、彼がそれを多くの小さなPOに分割し、それぞれに自分のミニPOを割り当てることに決めたからです。 これはおそらく私たちのプロジェクトの歴史の中で最良の決定でした。
最初から、テストを書く時間はありませんでした。 半年後、彼らはまだ書く必要があるという結論に達しました。 しかし、まだこの時間はありません。 優先度が高すぎる技術的負債が蓄積されています。 技術的な負債を節約しないでください-これはユートピアです。 彼はいつもそうです。
私の主観的な結論：
- 開発者がFrontEndのIOCの目的を理解していない場合、おそらく理解するのは遅すぎます。
- 開発者がFrontEndがOOPの知識を必要とする理由を理解していない場合、コードはほとんどサポートされません。
- 安価なスペシャリストは、収益性の高いスペシャリストよりも優れています。
- 建築家がいる場合、おそらくもう1人必要です。
- MVPを見ている場合は、それを終了してプロジェクトを変更します。
- MVPが既に記録されている場合は、このプロジェクトに移動しないでください。
- MVPを切り裂き、離れたくない場合は、考えを変えるでしょう。
- MVPを切り詰めて、プロジェクトを存続させたい場合は、ゼロから書き直してください。
- この記事を顧客に見せると、おそらく解雇されます。
- あなたがアジャイルに取り組んでいるなら、おそらく私を理解しているでしょう。
この記事を読んでも、これらの問題をすべて回避することはできません。 私の目標は、これが避けられないことを示すことです。 どんなに努力しても、理想的な状態になることはありません。 だから、それに備えてください。 そして、解雇する前に、この記事を顧客に安全に見せることができます。 彼に道徳的にこれをさせてください。
PS：マキシム、あなたがこの記事を読んだことがあるなら、私が説明したことはすべて完全に架空のものであり、私たちのプロジェクトとは似ていないことを知っています）しかし、今日は休暇中なので、これは重要ではありません。 骨の折れる不規則な仕事の年の最初の休暇！ （FEリードとして）。