こんにちは、フロントエンドエンジニアのてりーです。
僕の詳しいプロフィールはこちら
独学でフロントエンドエンジニアを目指している人へ
フロントエンドの仕事を得るまでにどんな勉強をしたら良いのかをまとめました！！
興味ある方は是非ご覧ください。
はじめに
記事の内容はタイトル通りです！
年明けから個人で3つほどLPやweb制作系の案件に関わりました。
主にデザインカンプからコーディングする！的な内容ですが、それらを進める中で先輩やデザイナーの方から貰ったフィードバックを重要度で区切ってまとめて見ました。
重要度は個人の主観で決めてます。
Lv3~Lv1で数字が大きいほど重要度が高いです！
割と初歩的な部分もフィードバック多いので、公開する事への恥かしさもありますが、自分の成長記録的な意義で赤裸々に記しているので、お付き合いください。
Lv3 実案件なら必須
reset.cssいれる
reset.cssをいれてなくてデバイスによってmarginズレズレ事案が起きました。
後からreset.cssを入れるのは地獄絵図です。
絶対、結論最初に入れておきましょう！！
入れるcssはreset.cssじゃなくてもよいので、そこら辺はお好みで、、
ちなみに読み込む順番はstyle.cssより上にしましょうね。
こんな感じで、、
<link rel="stylesheet" href="css/reset.css">
<link rel="stylesheet" href="css/style.css">imgタグのaltを空にしない
altの中身、空はアウトです！
受取手がコードが読める人なら確実に気になるレベルです。
altの役割としては画像が表示されなかった時に、代わりに表示されるテキストなので、画像に沿ったテキストを入れましょう。音声読み上げ時に利用されたり、SEO強化にも繋がるので必須です！
対象ブラウザ・デバイスの確認を最初にする
最初に受ける段階でちゃんと聞いておきましょう。
検証用のツールも確認するのが、マストかなーと個人的には思っています。
https化する
これはサーバーへのアップロードまで案件の場合ですが提出する制作物はhttps化を確実にしましょう！
httpで出したらめちゃくちゃ印象悪いです！！笑
レンタルサーバーからSSL化を行うのですが、僕はこの辺を参考にして行いました。
https://service.plan-b.co.jp/blog/seo/22408/
publicフォルダ下に公開用のファイル群はしまう
publicという命名は「公開用の」という意味を持っている。
なので公開する時に必要なファイルはpublicフォルダ下にしまいましょう。
そして納品時はpublicを渡すイメージ。
そのままだと公開時にユーザーに見られる情報が多すぎて危ないです。
READMEやsassなんかは実際の公開に関係ないので、外でOKです！
max-widthを設定する
pc版の一般的なレイアウトがしっかり作れても、横長の大きなモニターで見たら伸び切って残念な出来になってしまうので、max-widthはしっかり設定しておきましょう
タイポチェック
タイポは頻繁に起こすとレビュアーの人に対してとても申し訳なくなります！！
正直、人力ではどうしようもないので、僕はプラグインに頼りました！！
vscodeだとこれがおすすめです！！
https://qiita.com/diescake/items/98c5a099e85775cd917d
共通部分はできるだけファイル分けする
これやってないと同じコードを何度も書いている事になります。
例えばscssで使う変数(色などを定義したもの)はどのscssにも共通で書くことになると思うので、別のファイルとして作成し、各ファイルで読み込む形にして、コード量を減らしていきましょう！！
ベンダープレフィックス入れる
ベンダープレフィックスとは各ブラウザで正しくcssを出力するための拡張子で、これを設定していないとブラウザによって見た目が変わってしまいます。
vscodeでは「Live Sass Compiler」というプラグインがあり、sassからcssへのコンパイル時に自動でベンダープレフィックスを付与してくれます。
汎用的なクラス名つけない！
例えばh1のクラス名にtitleをつける的な感じです！
他のh1で使わないなんて、だいぶ気を使わないときついですよね。
クラス名に正解はないので、その案件毎に設計するべきですが、汎用的なタイトルをつけるのだけはやめましょう！！
Lv2 急ぎの案件でなければやりたい
列になっている要素は増えた時の並び方を確認
例えば要素が3つ横並びになっているデザインでも、要素が4つになった際に2×2の並びにしたりなど、並び方が変わってくる場合があります！
フレックスボックスにしていると柔軟に対応できますが、「そもそも要素が増える想定なのか」、「増えたら並び方が変わるのか」は確認しておくと良いです。
コンテンツの寸法の規則性に沿う
ほとんどのデザインがpaddingやmarginの値やコンテンツの大きさに規則性を持たせています。
これらの規則性に則って(読み取れなかったらデザイナーに聞いて良いと思う)コーディングを行うと、カンプの再現率が上がります。
細かくファイルに分割していく
LPの様に縦に長い制作物だとindex.htmlのコード量もとてつもなく長くなってくると思います。
しかしこのままだと、デバッグ時に該当部分を探しにくいので、ファイルを分割していきましょう。
一例として200行を超える様なら見にくいファイルになりつつあるので、分割を検討しましょう！
ブレイクポイントの切り替わりをデベロッパーツールで確認
ブレイクポイント周りで大きさを変えてみるとデザインが崩れてたりします。
どこまで対応するかは案件次第ですが、大きく崩れている部分は無いようにしましょう。
Lv1 ここまでやってれば優秀！！
コピーライトはpタグじゃなくてsmallタグ
セマンティクス的にはsmallタグがふさわしいっぽいです。
参考：https://webkaru.net/html5/small-element/
z-indexを一箇所にまとめる
z-indexはお互いの影響しあう度合いが大きいので、どこか一箇所にまとめて一元管理できると良いでしょう！！
sassのミニファイ
ミニファイとはsassをcssにコンパイルする際に、コメントや空白などを自動で抜き取ってくれる機能です。
cssファイルは実際にブラウザで読み込むファイルなので、極力小さい状態を目指すべきです。
余裕があればミニファイまでやっておきましょう。
まとめ
こう振り返るとありがたいほどに多くのフィードバックを受けてきましたね。
フィードバックしてくださった方々には本当に感謝しています！！！
僕自身、もっとweb制作の案件を経験して、知見をためたいと思った今日この頃です。
最後まで読んでいただきありがとうございました。