何を書くのか
一つ目のオリジナルアプリケーションを作成、運用しているうちに、先に決めなかったことで苦しんだことを項目ごとに簡単に振り返ります。ほとんど、自分への戒めです。お付き合い願います。
環境
Ruby: 2.6.5
Rails: 6.0.3.4
結論
これらの項目を取り上げます。
| 番号 | タイトル |
|---|---|
| 1 | ビューの構成をBEMで考える。 |
| 2 | いったん部分テンプレのことは忘れる |
| 3 | 後から読み返しやすいコードにしましょう |
1. ビューの構成をBEMで考える。
BEMとは、Block, Element, Modifierの略で、webサイトのコンポーネント化を行う
ためのフロントエンド設計方法の一つです。
詳細な説明については、こちらの記事をご覧ください。
BEMがどんなものか、かなりざっくりと説明すると
- classの命名規則に共通認識を持ちましょう。
- block > Element という階層構造を意識しましょう。
- 変更を加えたいところは、modifierで、Block/Elementに装飾しましょう。
といったような、フロントエンドの実装にあたって、そこに関わる人の中で共通理解をしながら実装を進めましょう、という考え方です。
BEMは前提として、「ページは成長に伴い変化する」という前提のもと、その変化に伴うコスト（時間や人的リソース）の最小化を目的として開発されました。この特徴があることで、例えば以下のように記述することになります。
<ul class="list"> <!-- Blockです -->
<li class="list__itme"></li> <!-- Elementデェス -->
<li class="list__itme"></li> <!-- Elementデェス -->
</ul>
ここで、このBlockは、再利用することができることに注目します。例えば、このようになります。
<ul class="list list_type_disc">
<li class="list__itme"></li>
<li class="list__itme"></li>
</ul>
<ul class="list list_type_check">
<li class="list__itme"></li>
<li class="list__itme"></li>
</ul>
このように、ほぼ同様のリストを二つ作ることができます。これが、BEMのメリットでもある再利用性を高めるということにつながります。
また、class属性には、"list_type_disc"とlist_type_check"をそれぞれ付与しています。本筋からは外れるので深くは説明しませんが、これをmodifierといい、「key_value」の形でBlock/Element名の後ろに記述しています。（詳しくは前述の記事をご覧ください。）これで、同じリストでもチェックボックス形にするか黒ポチ形にするかを、cssを見なくてもhtmlだけで判断することができるようになります。
2. いったん部分テンプレのことは忘れる
##部分テンプレートとは
部分テンプレートは、同じ記述をまとめることができるDRYの理念に基づいて用いられる設計方法のうちの一つです。
部分テンプレートについて知りたい人、復習したい人がいたらこちらの記事がおすすめです。
【Rails】部分テンプレートの使い方を徹底解説！
しかし、最初から部分テンプレのことを頭に入れた設計（DRY...DRY...とうなりながら開発する）だと、逆に柔軟性を失う可能性があることを理解しました。
##いったん忘れろと主張する理由
ページ同士で共通するヘッダーなどは、部分テンプレートにされがちです。
しかし、すでに部分テンプレを作成している場合、「ヘッダーにパンくずリスト入れたいな。あ、でも一つにまとめたんだった。また分け直すのも面倒だしな...」
といったジレンマに陥ります。なので、「部分テンプレに分けるのは、実装したい機能面で部分テンプレに干渉するかもしれないところ」を実装し終わってからが良いのではないかなぁ、と思います。
#3. 後から読み返しやすいコードにしましょう。
今回は、個人で開発を行ったので、「この記述でこうなる」と理解しながら実装を進めることができました。それでも、記述が長くなればなるほど、「これなんだっけ...」となることも。
そこで、注意すべきことは
- 変数の命名を適当にしない
- class名をBEMのルールに則って行う。（やらないと、特にcssで大変なことになる）
- 複数のコントローラーを跨ぐ機能が入り混じっているところは、コメントアウト等で補足する。
- 複雑なロジックは、コメントアウトをなるべく利用する
などです。大きく分類すると
- 命名規則を作成し、それに則って命名する
- ロジックが分かりにくいところは、コメントアウトで補足する
です。氷山の一角だと思いますが、これらを守るだけでも少し作業がしやすくなるのではないかと思います。
4. 実装したことない機能を実装する場合は、要件定義の時点で下調べ
要件定義の時点で、「これ、開発したことないな...」と思う機能は、まず、実装の方法を調べましょう。
そこで、「なんか難しそうだ...」となった場合、少し勉強してみます。
それから実装した方が、悩みが減り、精神的に健康だと思いますし、他の機能を実装しているときに、その機能を実装する前提で開発を進めることができるので、結果的に効率よく開発することができます。
僕は、formオブジェクトを用いた編集削除の機能を実装したことなかったのですが、後からこの実装が死ぬほど大変なことに気づきました。こちらの記事がなければ、詰んでました。
#最後に
最後まで読んでいただき、ありがとうございます。
ソースコード、記事の書き方について**「もっとこうしたほうがいいよ！」というご意見、「そこどうなっているの？」というご質問**など、お待ちしております。
#参考文献