吉本式 Web制作のコーディングガイドラインについて
まずはじめに
ちょうど1年前ごろに、吉本式BEM設計（BEM設計ベース）を発信しました。
公開当時は、意図しない分野（ターゲット外）の方々から想定をはるかに超える反響がありました。
このような技術的なガイドラインの発信は初めての経験で、文中の言葉遣いなどに甘い部分があり、意図しない解釈による反響が想定をはるかに超え、2日間で4万アクセスを超えてしまう、という経験をしました。
その後、落ち着き、Twitterなどから徐々に評価の声をいただきました。
あれから1年が経ち、私のWeb制作の実装環境も大きく変わりました。
その実務経験を元に、また新たなWeb制作のコーディングガイドラインとして発信します。
私について
現在、フロントエンドエンジニアとして活動しています。
Web制作会社で約3年経験を積み、個人事業主として約2年半、その後、会社を設立して10年目になりました。
Web制作会社・広告代理店から仕事の依頼を受け、受託制作を続けています。
構築環境は、JavaScript（TypeScript）+ HTML（Pug）+ CSS（SCSS）+ webpackです。
コーディングガイドラインについて
今回のガイドラインでは、HTML（Pug）+ CSS（SCSS）の設計を主に解説します。
webpackの設定についても触れる予定です。
本コンテンツのターゲットは、HTMLコーダー・マークアップエンジニアになります。
メインとなる内容は、ファイル設計（Pug, SCSS）・作業環境設定（webpack）についてです。
わかりやすいファイル設計
Web制作の実装をするとき、SCSSファイルをどう分けるか（設計するか）に迷うことはないでしょうか。
また、案件の引き継ぎでファイルに目を通しても、どういう設計で作られているかわかり難い・・・という経験はないでしょうか。
誰が見てもわかりやすいファイル設計にするには、ファイル設計のルールを統一し、例外を作らないことが重要になります。
法則性を持たせることで、誰が見てもわかりやすくなります。
例えば、BEM設計の場合にBlockごとに必ずSCSSファイルを用意するとルールを決めることで、SCSSファイル = Block要素と、統一された認識ができます。
これにより、実装者は新たにBlock要素が出てきた → SCSSファイルを用意と迷わずファイル設計ができます。
第三者が見てもSCSSファイル → Block要素という法則性があるため、わかりやすいと感じるはずです。
このルールに、例外を作ってはいけません。
例外を作ってしまうと、迷いが生じます。
この迷いが、作業を遅くする原因になります。
HTMLコーディングのスピードをあげるためには
いろんな要因がありますが、大きく分けて次の3にまとめられそうです。
・スキル（知識、経験）
・作業効率化（ツール、エディタ）
・迷い（ファイル設計、コーディングルール）
スキルについては、誰もが納得するところだと思いますが、こればかりは勉強と経験を積むしかありませんが、一言だけ付け加えると、最新の技術ばかりにアンテナを張りすぎると、実務では早すぎるケースが多いです。
何について勉強するかが大事になります。
作業効率化については、意外と改善の余地がある実装者が多い気がします。
デザインデータからHTMLコーディングに必要な情報（CSS, テキスト）を取得する際、Zeplinなどのツールを使う、またはプラグインを導入するなどで作業の効率が改善されます。
テキストエディタに関しても同様です。
どのテキストエディタを使うか、そしてプラグインを導入して、自分なりに使いやすいエディタにカスタマイズしているかどうかでも大きく変わってきます。
そして最後に、迷いです。
最も多いのが、クラス名でしょうか。
「クラス名、どうしよう」と悩む。これは誰もが経験すると思います。
もし、この迷いがなくなれば、コーディング速度が大幅に改善されます。
そのためには、クラスの命名規則の自分ルールを決めておくべきです。
ファイル設計も同様です。
Pugファイル、SCSSファイルの設計ルールを事前に決めておくことで、迷わずに済みます。
他にも、画像の命名規則などもこれにあたります。
これらについて、全てルール化し、そのルールに則ったファイル設計・命名規則で実装するということを本コンテンツで解説できればと思います。
解説する前に
これから解説する「吉本式 Web制作のコーディングガイドライン」は、もちろん完璧ではありません。
現在、私が実際に、受託制作を行う際に使用しているコーディングガイドラインです。
「もっとこうしたほうがいい。」「その考え方は間違っている。」「ここはもう古い。」
などなど、意見が出てくると思いますが、あくまでも本コンテンツの考え方を参考にしていただき、自分なりの素晴らしいコーディングガイドラインのお役に立てればと思っています。