あなたがすでに知っていることについて話しましょう。
これはHabréに関する私の最初の記事であり、私は作家ではありません。 しかし、
フロントエンド2018：今年の結果を見て、手は崇高に達し、書き始めました。
難しいタスクは単純なタスクで構成されます。
分解を正しく行う能力は必須です。
私は個人的な経験からのほとんどのプロジェクトの例についての議論をリードします。
「
しかし、私たちはそれを持っておらず、一般的に反応は速く、論理的で読みやすく、jsを使用してスタイルを生成することは何らかのアドオンではなく、ファッショナブルですが、バックエンドプロバイダーのFeofanはphpで優れたフォームを作成したため、 「でもまだ。
指定G1。 例外的な天才は、特別な壮大なケースです。
M *。 考え
これは読めません
それでは始めましょう！
M1。 ダビングコードが悪いです。M2。 常に100ステップ先を考える必要があります。たとえば、プロジェクトの開始時には、5年後の状態を考慮します。
明らかに、ソーシャルネットワークを開始すると、Webバージョンに加えて、モバイルアプリケーション、デスクトップアプリケーションがあるとすぐに言うことができます。 ここから......
M3。 サーバー部分は1回だけ記述する必要があります。 （M1）そして、Webバージョン、モバイル、デスクトップがあるので...
M4。 サーバー側はデータを処理します。サーバー側は、描画するボタンとその色を決定するべきではありません。
検索エンジンによるインデックス作成のためにページが読み込まれたときに読み込まれる[できる]レターテンプレートまたはhtmlファイルもデータを処理しています。 残念ながら、そこにはhtmlを操作する必要があります（たとえば、インデックス付けの要件のため）が、これは別の問題です。
実際、ファイル（html、js、css）とデータの初期セットを転送することは可能です。 つまり ここでは、背面はレイアウトに関与していません。
ここで、プロジェクトの最初の故障が発生しました：サーバー部分が壊れました。 どの言語で書かれているか、アーキテクチャがどのように配置されているかについては議論しません（MVCを思い出します）。 これは私のビジネスではありません...
M5。 誰もが自分でやらなければなりません。完全なスタックはいくつかのプロジェクトをカバーしますが、ここであなたはこの点について議論することができますし、確かに議論しますが、（M2）を参照して、ここでの私の立場は形成されています：あなたの分野に2人の専門家を置く方が1年でプロジェクトを書き直すよりも安いです。 もちろん、天才（G1）はいたるところにいますが、そのようなユニットがあります。つまり、「現状のまま」の議論にそれらを受け入れることはできません。
また、このパイから、Designer、Usability and coのブランチを削除します。
正しく理解してください。通常のフロントエンドベンダーは、100万のアナログと彼の想像力に焦点を当てて、独自にマイルストーンを展開できますが、私たちは（M2）深刻なプロジェクトについて話しているので、自分をflatめないでください:)（G1）
さて、データ（api、必要なすべてのメソッドなど）、レイアウトがあります-そして始めましょう。
現代の現実を考慮して、別のブランチを紹介します。 残念ながら、現代のフロントエンドベンダーの大部分は、レイアウトの操作方法を知らないか、jsを知りません。 私は膨大な数のインタビューを実施しましたが、観察するのは奇妙です。 したがって、フロントは「レイアウトデザイナー」と「非レイアウトデザイナー？」に分けることができます。
M6。 開発は複数のファイルで行う必要があります教えてください、明らかに？ はい、明らかに！
M7。 前面は2つの部分に分かれています。データを操作する部分と、データを表示する部分です。これまたはその部分がない場合があります。 例：表示のみ（静的ページ）またはデータのみ（コンソールのスクリプトなど）にする。
ここでは、抽象化して提示することをお勧めします。あなたはピザ屋です。 あなたは電話を受け、チーズを美しくレイアウトし、買い手に持って行きます。 ロジックは、あなたが特に効果的ではないことを示唆しています（M1）。 しかし、さらに2人があなたと一緒に仕事をすれば、もっとクールになります！ 1つは呼び出しを受け取り（データを処理します）、2つ目は取り戻します（プレゼンテーション）、3つ目はチーズを美しくレイアウトします:)（プレゼンテーションの様式）
すでに2012年から「CEP」、「明らかに」と聞いていますが、もう一度聞かせてください...
M8。 JSはデータを処理しています。彼はバックエンドを呼び出し、注文を受け入れ、チーズがどのようにそこに置かれるかは重要ではありません。 ピザはまったく存在しないかもしれませんが、おそらく彼は今年のピザの調査を行っているだけでしょうか？
M9。 HTML表現クライアントにピザを見せ、フィードバック（お金、レビュー）を受け入れて、管理者（JS）に渡します。
M10。 CSS-プレゼンテーションスタイリングチーズの2つのスライスの間にインデントします。
電話の管理者はチーズの積み方を言っておらず、ピザには電話で話している人が含まれていないことに注意してください。 jsを使用してスタイルを操作したり、htmlを使用してjsを操作したりする試みは、最初はアドインであり、最初は悪いです。 クラスとイベント処理は、理由のために考案されました。
ペパロニ、サラミを分類できますが、ペパロニチーズをどのように寝かせるかを決めるのはあなたの能力ではありません。
あなたはバインドを置くことができます：あなたが蹴られた場合、支払わなかった場合、管理者に伝えてください。 しかし、管理者をピザに押し込まないでください。 彼は一人で、たくさんのピザがあります！ オペレーターと同数のピザがある場合は、M1。
そして、js、css、htmlが責任を負っています-私たちはそれを見つけ出しました。
これで、ピザの調理方法、ピザをより速くより便利に配達する方法、電話で顧客と話す方法など、さまざまな質問に答えることができます。
どういうわけか今流行の単語「
コンポーネント 」を定義したいと思います。 実際、通常のボタンでさえすでに「コンポーネント」ですが、これを明白な例で再定義します。 ボタンはボタンであり、コンポーネントは次のとおりです。
1.投稿のプレビュー
2.解説
3.ファイルのプレビュー
4. habrでの投票
5.ブロック「空室」
6.投稿、レビュー、ウェビナーのHTMLテキスト
など
M11。 コンポーネントはどこでも同じように見えるはずです。投稿プレビューを投稿する場所、ページを開くページは、同じように見えるはずです。 3色のルール。 すべてがユーザーに認識可能でなければなりません。
変更-必要に応じて、強制的な変更。 CSSを使用して作成。
それとも別のコンポーネントですか
（たとえば、右の列の投稿プレビューは、ページの下部の投稿プレビューと異なる場合があります）。
M12。 コンポーネントは[html]、[js]、[css]で構成されます。各部分はオプションです。
M13。 同じコンポーネントのインスタンスの数に関係なく、そのスタイルは一度だけ登録する必要がありますたとえば、右側の投稿のプレビュー、下の投稿のプレビュー、通知内の投稿のプレビュー、スタイルは一度だけ登録されます。
M14。 jsコンポーネントでは、ベースのみを登録する必要がありますたとえば、ボタンをクリックしたときのイベントハンドラ、表示に必要なデータ。 それ以外はすべてレンダリングする必要があります。
M15。 コンポーネントはコンポーネントで構成されますたとえば、投稿のリスト。
M16。 別のファイルで取り出されたスタイルこれらのファイルはキャッシュされ、さらに、インラインでそれらを複製するという誘惑はありません。
M17。 コンポーネントスタイルは、親クラスを通じてのみバインドする必要がありますどのサイトのページも、サイズの異なるたくさんの箱のようなもので、入れ子になった人形が互いに埋め込まれているようなものです。
ボックスはコンポーネントです。
ボックスとアイテムが入ったボックスがあります。 ネストされたボックスの内部を記述する方法について考える必要はありません。 これだけを説明してください。
ここで彼らは自転車の束を発明しましたが、紳士、あなたがあなた自身のためにコンポーネントのセットを決定するとすぐに、名前に問題はないでしょう。 VKontakteを開いてそこでコンポーネントの数を数えると、30個も数えられます。 （フェイスブックに頼らないでください、痛みがあるだけです）。
30のクラス名を思い付くことができませんか？ そして当然のことながら、思い付くものは何もありません。
M18。 他の人があなたのコードを読むでしょう。自然な名前が最高の名前です
例えば
1.投稿リスト
2.コメントリスト
3.ニュースリスト
4.プレビュー後
5.コメントプレビュー
6.ニュースプレビュー
7.ポストディテール
8.コメント詳細
9.ニュース詳細
信じられないほど難しいでしょう？ そして、主なことは理解できず、維持が難しいことです
また、「他の人を読む」についても購読を解除します。
M19。 Html、js、cssは別々に保存する必要があります！それらを一緒に組み合わせる必要がある場合は、1つのファイルに書き込むのとは異なる解決策を考えてください。
Reactは、私が見た中で読みやすさの面で最も嫌です！「ボックス」のページが分割され、ファイルの保存方法が議論されました。 他に何？
M20。 特別なケースはほとんどありませんそしてそれが起こった場合、明日あなたのマネージャーは仕事に来て、「顧客の要求に応じて実装を変更する必要がある」と言うでしょう。 可能な限り最も一般的な方法で問題を解決します。
たとえば、私たちの仕事では、プロジェクトに関係なく、いくつかのタスクをすぐに分離します。カレンダー、入力フォーム、ポップアップ、さまざまな内容のメニュー、ファイルの表示、ユーザーと対話する他のウィジェット。 いわば、「キャラクター機能」
M21。 スタイルの記述には分解が必要です世界はすばらしいLESS、SASSを私たちに与えただけではありません。
プロジェクトには、フォント、色、影の固定セットがあり、ほとんどすべての深刻なプロジェクトには配色があります。そのため、スタイルを記述するとき、これらはすべてパラメーター化されます。 そして、ここでは以下が重要です
M22。 フォントの色（など）を変更する場合は、1か所で編集する必要があります。結論として、1つの重要な問題に言及したいと思います。
M23。 問題の正しい定式化は、正しい解決につながります。おそらく、css-in-js、facebook、および呼び出してはならないものはないでしょう。
みなさん、良い一日を！