BEM開発の19の原則、またはすべてのライブラリ開発者が知っておくべきこと

BEMの人気が高まり、より関連性が高まっています。たとえば、Googleは最近、 BEM方法論によって実装されたMaterial Design Liteと呼ばれる新しいブロックライブラリをリリースしました。 BEMチームも怠けていませんでした-bem-componentsライブラリの新しいバージョンをリリースしました。これに基づいて、Yandexだけでなく他の開発者のサイトとプロジェクトも構築されました。



これらのイベントは、BEM方法論におけるライブラリ開発の原則がどのように形成されたかをもう一度思い出して伝えるためのアイデアを私たちに与えました。 これが多くの人にとって興味深く有用であることを願っています。 行きましょう。







長い間、私たちは主に直観を使用してブロックのライブラリを作成しました。 このとげのある道には、多くの円錐形が詰め込まれ、多くの教訓が得られました。 その結果、ライブラリ開発の原則を含む新しいドキュメントを作成しました。これは、新しいブロックを開発する際のチェックリストとして使用しています。 私たちの意見では、これらのシンプルで明白な原則は、思慮深く、便利で、スケーラブルで、保守しやすいコードを取得する機会を与えてくれます。



開発原則にどのように到達したかを例で学びたい場合は、catへようこそ。

少しの歴史、または熊手での歩き方について

私たちがライブラリに取り組み始めたとき、私たちは、ほとんどの開発者と同じように、すべての人のために、素早く、美しく、やりたいと思っていました。 ライブラリを使用したい多くのアイデアとプロジェクトがありました。



しかし実際には、それは必ずしもあなたが望むようにうまくいくとは限りません...

みんなを楽しませる

大企業や若い企業で働いていた人は、ここで「自転車を発明する」のが好きなことを知っています。それは私たちと同じでした。 開発者の各グループは、自分でブロックを作成しました。 実際、すべてのチームが同じことをしましたが、方法は異なります。 最初は十分に速かった。 しかし、同じブロックの実装数は急速に増加しました。 すべてのプロジェクトに共通のブロックセットが必要であることが明らかになった（たとえば、全員が同じキャップと地下室を必要としていた）ため、共通ブロックを別のライブラリに配置することにしました。 私たちには、多くの同一のブロック間の秩序を回復することになっていた、有能でバランスのとれた決定のように思われました。







ユニバーサルライブラリの開発を開始しました。 すべてのプロジェクトに共通のブロックを作成して、個々のプロジェクトの要件を満たすように考えました。 ブロックを使用するすべてのケースを考慮し（最もまれで、ほとんど不可能）、できるだけユーザーフレンドリーなブロックにすることを試みました。 そのため、各ブロックのコードは不適切なサイズに膨らみ、提供したケースの90％は誰も使用していません。 それにもかかわらず、このコードをすべてサポートする必要がありました。 エラーの修正が遅れました。

速度優先

ブロックのコードはYandex内で使用されたため、個々のプロジェクトの開発者はリリースに依存していました。 したがって、ブロックを開発する速度が重要でした。

プロジェクトはそれほど多くないように思われ、すべてのエラーをキャッチすることができたため、ユニットテストは作成しませんでした。 しかし、ブロックの数、プロジェクトの数も増加しました。 しかし、開発者の数は増えているものの、同じ速さからはほど遠いものでした。 Bugreportでいっぱいになりました。

ユーザーの権利が増え、開発者の権利が減る

非常に便利なライブラリを作りたかったのです。 これを行うために、広範なパブリックAPIを割り当て、ユーザーに操作の余地を与えました。 しかし、私たちは自分たちの手を縛ることを考慮しませんでした。 外部APIに影響を与えることなく、ほとんど変更を加えることはできませんでした。 修正されたエラーは修正され、新しいバージョンがリリースされました。 しかし、このような移行はプロジェクトのすべてを容赦なく壊し、多くの時間がかかったため、開発者はライブラリの古いバージョンからの切り替えをますます拒否しました。

スタイルのニュアンス

ライブラリを使用するすべてのサイトのデザインが同じであるため、ライブラリのコアからスタイルを削除しませんでした。 私たちのテーマを実現するために、一般的なスタイルを捨てて、独自のスタイルを課しました。



そのため、開発者の1人がコントロールの通常の外観を変更する必要がある瞬間まで正確に生きることができました（たとえば、プロモーションページを「明るく」するため）。 新しいスタイルを追加すると、多くの問題が発生しました。スタイルが相互に競合し、キャンセルされたときに、コントロールが正しく機能しませんでした。 トピックをブロックの一般的なコードに直接実装する方法は、それ自体を正当化しないことを認めなければなりませんでした。 私たちは、アーキテクチャを考えて、プロジェクトに新しいテーマを追加する可能性を築く必要があるという結論に達しました。

デフォルトの使いすぎ

修飾子にデフォルト値を使用するのが好きでした。 一方では、値を指定して機能するコントロールを取得できないため、これは便利です。 一方、開発者はデフォルト値のままで修飾子に影響を与えることができません。 つまり、値の数には制限があります。 たとえば、ボタンがあり、そのサイズは修飾子（s、m、l、xl）によって設定されます。 修飾子を指定せずに、デフォルト値-mを取得します。



ただし、カスタム値を使用する必要があるときが常にあります。 提案されたモディファイア値のいずれとも一致しないサイズを設定する必要がある場合、寸法に関する追加のコードがまだアセンブリに入りました。 ライブラリ開発者は、すべてのデフォルト設定をサポートすることを余儀なくされたため、リファクタリングに多くの時間を費やす必要がありました。



スタイルの一般的なリセットを使用したため、テーマのない基本ブロックの実装は機能しませんでした。 したがって、私たちは自分自身を堅いフレームに追い込みましたが、それは変更が非常に困難でした。



もちろん、あなたが話すことができる他のエラーがありました。 そして、すべての困難に遭遇したことを後悔していません。 これにより、ライブラリ開発へのアプローチを策定し、優先順位を特定し、BEMライブラリ開発のためのシンプルで理解しやすい原則を策定することができました。

原則がどのように形成されたか

過去の災害の規模を推定し、結論を出して、すべての経験を1つのユニバーサルライブラリ-bem-componentsに収集しました。新しいコンポーネントのリリースは最近行われました。 ここで、アプローチの主な変換と、ブロックライブラリの作成における肯定的な経験について説明します。

普遍的なブロックとすべての人のためにすべてを行うブロックは同じものではありません

まず第一に、私たちはもはやみんなを喜ばせようとはしないと決めました。 ここで、ブロックまたは追加機能の開発を開始するのは、これが本当に必要であると判断した場合のみです。 必要性は、ブロックが使用されるプロジェクトの数、実装に必要なコードの変更量、パブリックAPIの変更の必要性、および新しいバージョンへの切り替えに必要な時間から決定されます。



私たちは、ベース、基盤として機能し、あらゆるプロジェクトで使用できるユニバーサルブロックを作成しようとします。 ユーザーの固有の要件はすべて、ベースユニットの追加と再定義の助けを借りて、ユーザーが個別に実装できます。 このおかげで、私たちには製造された製品の責任を負う機会があります。 ブロックをできる限りシンプルにしようとしています。その結果、ユーザーはわかりやすく、特定のプロジェクトのニーズに合わせて再定義しやすい明確なコードを取得できます。



ブロックの機能を削減することに加えて、ライブラリのすべてのレベルで均一性を維持します。 たとえば、1つのブロックで寸法を修飾子を使用して指定する場合、他のブロックの寸法も修飾子を使用して表現する必要があります。 イベントを操作して修飾子を変更できる場合、新しいイベントを作成したりサブスクライブしたりする必要はありません。



可能な場所ではデフォルト値の使用を拒否しました。 ライブラリユーザーは、コードに影響を与えて再定義する機会が増えました。



また、パブリックAPIを大幅に絞り込んだため、ブロックを変更する自由が増え、宣言されたAPIが安定しており、頻繁に変更されないという自信がユーザーに与えられたことにも注意してください。

完全かつ無条件のオープンソース

ブロック開発を公開しました。 彼らはGithubのすべてのコードを取り出し、 セマンティックバージョニングのルールに従ってライブラリのバージョンをリリースし始めました。 各メジャーバージョンのリリースには、変更履歴の詳細な説明と新しいバージョンへの移行に関するガイダンス が付属しています。



テストでコードを完全にカバーすることにしました。 これにより、ブロックの作成が複雑になり、速度が低下しますが、サポートが大幅に簡素化されます。 新しいバージョンのリリースは、すべてのコードがテストでカバーされるまで行われません。



上記のすべてに加えて、プロセスを自動化できる場合は、これを行う必要があると考えています。 ロボットはすべての反復アクションを実行し、開発者の時間を解放する必要があります。これは、偶然にもテストの作成に費やすことができます。

APIのより明確な

また、プライベートAPIとパブリックAPIの分離がより明確になったため、新しいバージョンへの移行がはるかに簡単になりました。 たとえば、これがプライベートAPI（メソッドの名前はアンダースコアで始まる）であることを明確に示す正式な標識を開発しました。これは、誰もその不変性を保証しないことを意味します。 ただし、健康のためにパブリックAPIを使用してください。その変更は、新しいメジャーバージョンのリリースでのみ可能です。

ブロックアーキテクチャを事前に検討する必要があります

最終的にそのアーキテクチャを決定するまで、ブロックの開発を開始しません。 もちろん、開発中に最初に考慮されなかった追加機能を実装する必要がないとは予測できません。 しかし、適切に設計されたアーキテクチャは、通常、ユニットを簡単に拡張できるようにし、追加の変更なしで不足しているものを追加できるようにします。



これはまさにブロックのスタイリングで今やっていることです-テーマは修飾子を使用して実装されます。 新しいトピックを追加するには、修飾子の新しい値を設定するだけです。 ライブラリにトピックが1つしかない場合でも、別の修飾子でその実装を取り出します。 同時に、常にシンプルなサービステーマを作成します。これにより、新しいテーマを追加するときにスタイルが競合しないことを確認できます。 また、すべてのブロックは、テーマ修飾子が指定されていなくても基本的な機能が機能するように実装されます。



私たちがどのように構築し、構築し、最終的に構築したかについて長い間話すことができます。 しかし、彼らが言うように、一度見た方が良いです-bem-componentsライブラリは私たちの仕事の結果です。 もちろん、製品をより良く、より簡単に、より理解しやすくするのに役立つ原則自体をリストすることは残っています。

BEMライブラリの開発の原則

長年にわたる研究の結果、ライブラリ開発の短い原則を策定しました。 一見、このリストには多くの明白なルールがありますが、明白であることでそれらの重要性が減ることはありません。

1.オープンソース

ライブラリは、すべてのタスクと計画が利用可能なGitHubで開発されています。 開発者は誰でもライブラリの作業に参加できます。チームの希望に基づいてタスクを作成するか、プルリクエストを送信します。

2.使いやすさ

ライブラリはできるだけシンプルにする必要があります。 あいまいに見なされたり使用されたりする可能性のあるものはすべて破棄します。

3.ミニマリズム

必要な機能を設計するときは、ニーズを統一するのではなく、交差するように努力してください。 選択した状況では、より少ないコード、BEMエンティティ、またはサポートしやすい問題を解決する方が望ましいです。

4.テスト範囲

ライブラリコードはテストでカバーする必要があります。 これにより、エラーが少なくなり、将来のサポートの時間を節約できます。 コードは、テストでカバーされるまで、完全で安定しているとは見なされません。 新しい機能を備えたプルリクエスト。ただし、テストを追加または変更しない場合は受け入れられません。

5.均一性

すべてのフィールド名とメソッド名は、1つ以上の互換性のあるライブラリ内で統一する必要があります。 ブロック内でメソッド、修飾子、またはフィールドが特定の方法で呼び出される場合、同様の問題で、同じ命名ロジックに従う必要があります。 すべてのエンティティの一貫性と一貫性は絶対に近づける必要があります。 ライブラリを使用するかコードを変更する他の開発者が命名ロジックを理解することが重要です。

6.プライベートAPIとパブリックAPIへの分離

プライベートブロックAPIは、このブロック外では使用しないでください。



パブリックAPIは、余分なものを提供せずに最小限に抑える必要があります。 ドキュメントで使用可能な方法を必ず示してください。 パブリックAPIの安定性は、 セマンティックバージョニングの規則の遵守によって保証されます。

7.ユーザーの微調整

開発プロセスでは、ユーザー側の柔軟な追加およびオーバーライドテンプレート、スタイル、およびスクリプトの可能性について事前に考えてください。 たとえば 、テンプレートをオーバーライドすることにより、入力BEMJSONでHTMLタグを指定する機能。

8.複数のテーマのサポート

ライブラリはいくつかのトピックをサポートする必要があります。 これにより、各スタイルのルールを正しく作成し、新しいトピックとの競合を回避できます。 現在、BEMライブラリの主なテーマは島であり、新しいYandexデザインが採用されています。 同じライブラリ内でのいくつかのトピックの実装は、bem-componentsで提示され、島とともに追加の単純なテーマがあります。

9.明示的は暗黙的よりも優れています（JavaScript APIで）

メソッドの名前は本質を正確に反映し、実装するものをすぐに明確にする必要があります。 このアプローチにより、エントリのしきい値を下げて、APIをより理解しやすくすることができます。

10.明示的なデフォルト

デフォルトは明示的に宣言する必要があります-これは外部APIです。 それらを変更すると、後方互換性が妨げられます。 暗黙的でどこにも説明されていないデフォルトは、ライブラリサポートに問題を引き起こします。

11.エラー処理

入力は使用前に確認する必要があります。エラーが発生した場合は例外をスローし、呼び出し元のコードで処理できます。 エラー処理はライブラリ全体で均一に発生する必要があります。同じケースで発生しない場合は、ブロックに複雑なデータ検証を追加しないでください。

12. BEMのサブジェクトエリア

BEMエンティティを通じて表現できるものはすべて、BEMエンティティを通じて表現する必要があります。

13.修飾子と 専門分野

修飾子は、位置または条件の事前定義されたセットです。 特殊なフィールドは、以前は未知の変数値のセットです。



値の有限セットとして表現できるものはすべて、修飾子を使用して実装する必要があります。 これが不可能な場合は、専用のフィールドを使用してください。

14.ブロックの階層

ブロック間の相互作用は、階層的な順序で構築する必要があります。 ブロックは、外部または隣接するブロックと対話できません。

15.ブロックレベルの最適化

最適化ソリューションは、特定の各ブロックの開発中に実装する必要があります。 将来、すでに記述されたコードでそれらを実装しやすくするために、可能な最適化パスを事前に考えてください。

16.ルーチンプロセスの自動化

画像の挿入、接頭辞の配置、スタイルのコピーなどのすべての反復アクションは自動化する必要があります。 開発者はルーチンを実行する必要はありません。これにはロボットがあります。

17.アダプティブレイアウトのないモバイルプラットフォーム

ライブラリはモバイルプラットフォームをサポートする必要があります。 アダプティブレイアウトの使用は推奨されません。 ライブラリは、サポートが宣言されているすべてのブラウザで機能する必要があります。コンポーネントの機能のみではなく、コンポーネントのスタイリングのみの低下が許可されます。

18.可用性

ライブラリコンポーネントは、アクセシビリティプログラムで読み取り可能である必要がありますが、このためにパブリックAPIを拡張しないでください。 必要なすべてのARIA属性の公開は、テンプレートとスクリプトのレベルで実装されます。

19.ブリーディングエッジ

ライブラリは、将来に焦点を当てて開発されています。 常に最新バージョンのブラウザーとツールを使用して、開発プロセスで可能な限り長く関連性を保ちます。



これらの原則は、BEMライブラリの開発に役立ちます。誰でも開発に参加できます。 開発の基本原則を策定した後、図書館に貢献するための内部ルールを開発することもできました。

原則の例に従う-bem-componentsライブラリ

リストされた原則に従って、ライブラリを作成しました。 bem-componentsは、BEMチームの主要なオープンソース製品です。



bem-componentsライブラリには、22個の既製のコントロールが含まれています。 ただし、不足している機能を追加することを制限するものではありません。







ライブラリをプロジェクトに接続するさまざまな方法を提供しています。 Webサイトのライブラリの説明にあるすべての接続方法をお読みください。



バージョン2.3.0以降、bem-componentsライブラリは、 Distの形式でのBootstrap-deliveryと同様に使用できます。 これで、ライブラリコードをプロジェクトにコピーするだけで、具体的な例として、各ブロックでの原則の実装方法を確認できます。



Dist形式のライブラリ配信は、事前に組み立てられたCSSおよびJavaScriptコードとテンプレートを提供します。 ライブラリはページへのリンクによって接続されており、アセンブリを必要としません。



ライブラリを使い始める最も簡単な方法は、CDNからファイルを添付することです。 これを行うには、アイテムを追加します

    HTML : 
      

        
        
        
      

     
      

        
        
        
      

     <link rel="stylesheet" href="https://yastatic.net/bem-components/latest/desktop/bem-components.css"> <script src="https://yastatic.net/bem-components/latest/desktop/bem-components.js+bh.js"></script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
      

        
        
        
      

     
      

        
        
        
      

         CDN: //yastatic.net/-///-. 
      

        
        
        
      

     : https://yastatic.net/bem-components/latest/desktop/bem-components.dev.js+bh.js . 
      

        
        
        
      

     
      

        
        
        
      

        bem-components   Dist,           . 
      

        
        
        
      

     
      

        
        
        
      

          ,      —           —  . 
      

        
        
        
      

     
      

        
        
        
      

              ! 
      

        
        
        
      

     
      

        
        
        
      

     PS       ,  ,    .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

HTML :



<link rel="stylesheet" href="https://yastatic.net/bem-components/latest/desktop/bem-components.css"> <script src="https://yastatic.net/bem-components/latest/desktop/bem-components.js+bh.js"></script>







CDN: //yastatic.net/-///-.

: https://yastatic.net/bem-components/latest/desktop/bem-components.dev.js+bh.js .



bem-components Dist, .



, — — .



!



PS , , .