経験豊富な人には、私たちのアドバイスは明白に思えるかもしれません。ただし、初心者の方は読むことを強くお勧めします。時間をかけてこれらのアイデアをプロジェクトに変換し、後で無限のリファクタリングにさらに費やさないようにしてください。
同様のアイデアは、開発のほぼすべての分野で表現できますが、Reactのプロジェクトの例を使用してそれらについて説明します。
プロジェクトを最初から始めて、すべてを整理して、後で無限のやり直しによって耐え難いほどの苦痛を与えないようにするための最善の方法を考えます。個人的なペットプロジェクトでは、好きなものをフェンスで囲み、自分で一緒に暮らすことができます。しかし、チームワークでは、同僚が本質を理解し、詳細に飛び込むのを容易にするような方法で行動する必要があります。それら。開発アプローチを再発明しないでください。確立された、業界で認められた慣行に固執することをお勧めします。
入力について考えてください
開発言語の自由度に関係なく、静的型付けは大規模な長期プロジェクトで非常に役立ちます。何らかの理由でそのようなプロジェクトで静的型付けを使用することが不可能な場合は、JSDocでさえコードの品質を維持するのに大いに役立ちます。
ただし、常にタイピングを使用することを強くお勧めするわけではありません。タイピングはまず第一にチームを助けるので、大規模なプロジェクトについて上記で予約が行われたことは無駄ではありませんでした。ただし、その編成と保守（バックエンドの変更に応じた同じタイプの変更）には、特定のリソースが必要です。 1〜2人が働く小規模な短期プロジェクトでは、この投資は無意味です。ただし、チームが大きく、拡大する場合に必要です。
タイピングの使用が正当化される場合は、最初からタイプを作成することをお勧めします。そうしないと、この作業により多くの時間を費やす必要があります。APIの準備ができておらず、データモデルがわからない場合でも、少なくともスタブを作成して、汎用タイプがどこにも表示されないようにします。
プロジェクトが進展するにつれ、たとえすべての締め切りが長い間燃え尽きたとしても、タイピングは守られなければなりません。次に、この完璧主義に感謝します。
コードをブロックに分割し、ロジックを強調表示します
コードをまとめてはいけません。プロジェクト構造の階層を検討する価値があります。コードをモジュールとブロックに分割し、コンポーネントをスマートとバカに分割します。特にこれらの粒子が相互接続されている場合、1つの大きなヒープでこのロジックの粒子を探すよりも、このような構造を維持および開発する方が便利です。おそらく、このアドバイスはフロントエンドだけに当てはまるわけではありません。
この原則の有用性は、私たちが最近書いた大きなフォームのプロジェクトで非常にはっきりとわかりました（https://habr.com/ru/company/maxilect/blog/511322/）。そのプロジェクトでは、ブロックチェックとそれらのブロックの可視性が最初にリンクされていました。しかし、フィールドのすべての通信を1つの場所に収集すると、ロジックの変更を追跡するのがはるかに簡単になりました。そして最も重要なことは、新しい同様のプロジェクトでコードを再利用できたことです。
プロジェクトの構造に単一の基準はありません。ここでは、知識に頼る必要があります。多くのプロジェクトで機能する可能性のある2つのアプローチがあります。ファイルタイプファーストと機能ファーストです。
自分に便利な構造を見つけるための出発点を見つけるには、ドキュメントを参照することをお勧めします。通常、ベストプラクティスはそこで説明されています。たとえば、ドキュメントのReactとReduxは、プロジェクトのロジックとファイル構造を整理するための標準を提供します。ある程度の経験があれば、特定のプロジェクトの制限を回避できる場合は、実験して標準から逸脱することができますが、ほとんどの場合、これは必要ありません。そしてもちろん、SOLIDのような「基本的な」原則を忘れないでください。 Reactでこれらの原則を適用する方法に関する素晴らしい記事：https://habr.com/ru/company/ruvds/blog/428079/。クリーンなアーキテクチャに関する優れた記事：https：//habr.com/ru/post/499078/。
Reactおよび関連する問題のコードベースの編成については、長い間更新されていませんが、優れた資料のコレクションがあります：https：//github.com/markerikson/react-redux-links/blob/master/project-structure.md。
コーディング規則を策定する
アプリケーションが開発されるパスに基づいてプロジェクトを最初に計画するアーキテクトは、特定のテンプレートを念頭に置いています。それらをプロジェクトパスポートの形式で明示的に表現し、コードを記述するためのルール、たとえば、別のモジュールに含めることができるものとできないものを補足することは価値があります（一般に、これはかなり哲学的な質問です）。このような「パスポート」は、開発者が書き方を事前に決定するのに役立ち、後で書き直さないようにします。これにより、レビュー時間が短縮され、コーディングアプローチの標準化に役立ちます。これは、プロジェクトがリモートワーカーまたは分散チームによって作業されている場合に特に役立ちます。
選択したパラダイムに固執する
当初、アトミックWebデザインなどのアプローチに従うことにした場合は、期限が切れ始めたらすぐにそれを放棄しないでください。パラダイムの開始および放棄されたサポートは、完全に存在しない場合よりもほとんど悪い場合があります。少し「混乱を自由に操る」と、秩序を取り戻すのが非常に難しくなり、パラダイムに戻るのに時間を費やす必要があります。また、プロジェクトではすでに形のない混乱が発生しているため、別のものにすばやく「ジャンプ」することはできません。
タイミングやその他の要因のためにパラダイムを拒否することは、交差点で馬を変えるようなものです。痛くてお勧めできません。しかし、解決策がない場合は、アプリケーションのほとんどをテストでカバーする必要があります。そして、ここで次のヒントに移ります...
テストを忘れないでください
プロジェクトのテストは、必ずしもそうである必要はありません。彼らは働かなければなりません。そして、開発が始まるとすぐに、最初の段階でそれらをプロジェクトに含める必要があります。それ以外の場合は、特定の時点で、アプリケーションの何かを変更してから、リリース期限を過ぎて、手動テストでのみカバーされるプロジェクトのさまざまな部分のパフォーマンスを復元できます。
最初はテストを小さくし、何もチェックしないようにします。しかし、この「技術的負債」の返済に1週間を費やすよりも、機能が成長するにつれてそれらを開発する方がはるかに優れています。費やした時間の観点から、最初のアプローチがより効果的です。ちなみに、多くの人はこれをよく知っていますが、それでも後でテストを残します。
また、統合とエンドツーエンドのテストについても触れておきたいと思います。
バグを修正したり、新しい機能を追加したりするたびに統合テストを実行して、調整が何にも影響を与えていないことを確認する必要があります。私たちのプロジェクトでは、作業の結果をアップロードするときに自動的に起動しようとします（これはフックを介して実装しました）。テストはうまくいきませんでした-プロジェクトに変更をアップロードしないでください。まず、すべてを修正する必要があります。
ただし、統合テストはフロントエンドのみに関係します。エンドツーエンドのテストは遅く、アプリケーションとすべての依存アイテムとの相互作用をテストします。これらのテストは、ユーザーのアクションをシミュレートします。ここでは何も嘲笑していませんが、バックエンドの応答を待って、サイプレスを使用してプロジェクトのエコシステム全体内の相互作用をチェックしています（アナログとしてPuppeteerをお勧めすることもできます）。
アップグレードする前に考えますが、あきらめないでください
フロントエンドの世界では、すべてが非常に迅速に変更されます。フレームワークのバージョンが相互に置き換えられ、より成功したライブラリが表示されます。それらを最新の状態に保つことは価値がありますが、熱狂的ではありません。
上で説明した入力と同様に、更新にはリソース（つまり、間接的にお金）がかかります。ただし、更新を完全にオプトアウトすることを不可能にするいくつかのことがあります。
まず、最も成功したライブラリでさえサポートが終了することがあります。この状況では、より有望な類似物を探す必要があります。
第二に、古いテクノロジースタックを使用して作業することで、開発者が刺激を受けることはめったにありません。チームをほこりっぽいバックボーンに留めることができないことに気付いた場合、または古いスタックが新しい開発者の流入に重大な影響を及ぼしていることに気付いた場合は、更新する必要があります。
軽食は物事の自然な秩序の一部としてとられるべきです。ただし、ライブラリを変更したり、フレームワークを更新したりする前に、常に調査を行う必要があります。
新しいバージョンはあなたにぴったりですか？一般的に移行を整理する方法は？そしてもちろん、事前にすべてを計画する必要があります。
プロジェクトにテストがない場合、更新は非常に困難です。小さな日付ライブラリでもプロジェクトのさまざまな部分をカバーでき、それを更新すると完全な回帰テストにつながります。プロジェクトの成長に伴い、兵器庫での手動テストのみでは、効率的にそれを行うことは不可能になります。
今は元気ですか？
プロジェクトの開発効率の尺度は、新機能の開発に費やされた時間とバグに費やされた時間の比率になります。アプローチによっては、この指標は多かれ少なかれある可能性があるため、「目標」レベルの設定は行いません。変換の前後の状況を自分で比較できます。
「プロジェクトからの開発者の満足度」などの非数値的な特性に加えて、新しい人がプロジェクトに参加する時間などの指標があります。これは、ドキュメント、テスト、およびコーディング規則を通じてプロジェクトがどれだけ明確に記述されているかという特徴です。
また、以前よりも優れたコードを残しておくことをお勧めします。技術的な負債を発生させないでください。そうしないと、後のプロジェクトの開発が妨げられます。
おそらくあなたはあなた自身のヒントを持っていますか？コメントを残してください！
PS私たちはルネットのいくつかのサイトで記事を公開しています。Maxilectからのすべての出版物やその他のニュースについて学ぶために、VK、FB、Instagram、またはTelegramチャネルのページを購読してください。
PPS最近開催されたプレイハウスコンペティションのタイトル写真。