#この記事を読むメリット
初めてのgithubでのプルリク（コードレビュー）していただく際に最低限チェックしておくべきことを大まかに知る事ができる。
レビュワーの方々の時間を必要以上に奪わず、自分の生産性も上がるはず！
#目的
作業時間を短縮する、コードを見やすく簡潔にする、生産性をあげる
制作物の見た目を整えること"だけ"に目を向けていると、サイトが重くなったり、わかりずらく保守運用のしづらいコードを書いてしまうことになります。（自分がそうでした、、、）
今回は初めてのコードレビューをいただいた自分が最低限意識しておいた方がいいなと感じたものをメモとして残します。
足らないところがありましたら教えていただけますと幸いですmm
##コード記述において留意すること
###1. 社内のコーディング規約をしっかり確認
ここが一番大事な基準になると思うのでしっかり確認しましょう
自分は見落としが多々あり余計な時間を使ってしまいました
###2. 余計なタグが記述されていないか
余計なタグがあるとコード量が増え読みにくくなる上、サイトパフォーマンスが落ちるのでなるべく簡潔に描きましょう。
特にdivタグ（DIV病）には気をつけましょう
「DIV病」とは
###3. 適切なtype属性を指定する
例えばbuttonを使う場合、type属性には「submit」がデフォルト設定されています
ボタンとして使用したい場合は
<button type="button">
<span>
ボタンだよ
</span>
</button>
このようにしてあげましょう。
###4.入れ子関係を確認
「フレージングコンテンツ（button）の中に、ヘッディングコンテンツ（h2）を含めることはできない」などです。
入れ子関係に悩んだときの秘密兵器です
###5.開発用コメントは消す
開発中のメモ書きは至る所にあると思うのでプルリク前に不要なものは削除しときましょう
###6.省略できる記述は省略する(scss)
&.btn::after {
content: '◯';
は
&.btn {
&::after {
content: '◯';
}
}
このように書く事ができます。
また、同じタグ内のクラス名の重複なども必要なければ消しときましょう
###7.クラスは保守運用しやすい命名をする
今後デザインが変更される可能性なども踏まえて、わかりやすいかつ汎用性のある命名にしましょう。タグ名などでの命名は用途が限定されてしまうため好ましくないです
###8.影響範囲を考える
サイトが大きくなるほど1つの変更での影響範囲が大きくなる可能性があるので、コードを追加する際は常にどこまで影響範囲があるのか意識しましょう（していきます）
###9.タイプミスを確認
タグのとじ忘れ、スペルミスなどサイトの崩れに繋がるので確認しましょう
##プルリク直前に留意すること
###自身がどこまでテストをして問題ないと判断したのか伝える
影響範囲の確認や成果物のデザインカンプ等でレビュワーにゴールを示す
（◯◯部分はバックエンドの処理に依存するので今回のプルリクでは範囲外など）
###ページ全体に崩れ・誤字がないか確認
レビュワーの方はデバッガーやテスターではないので基本的には自分が最終確認者くらいの気持ちでいましょう（います）
全く案件を把握していない人間にもわかるように自分の成果物を説明できる状態を目指しましょう