NGなコーディングの進め方7選を紹介！【より良いコーディングを考える】

良いコーディングの進め方ってあるのかな？

コーディングの進め方って人によって様々ですよね。

私がまだ右も左もわからない新人コーダーの頃を思い出すと、
効率は悪いし、自分よがりなコードを書いていたし、メンテナンス性もよろしくない

今思い出すと本当に同じチームの方に申し訳なくなるやり方をしてしまっていました・・

ですが、今ではコーダー歴3年を超えてきて、
少しでも成長できたのではないかと思う部分があるので、
私なりの観点にはなりますが、NGだったなと思うコーディングの進め方について紹介していきたいと思います。

本記事を読むメリット

check_circle

効率よくコーディングを進められる方法を知ることができる
他の人があなたのコードを見たときに理解しやすいコードを書くことができる
メンテナンス性の高いコードを書くことができる

それでは早速本題に入っていきます！

NGなコーディングの進め方7選
コーディングの進め方は絶えずアップデートさせよう

NGなコーディングの進め方7選

まずは結論から先に書いておきます。

結論

check_circle

すぐにコードを書き始める
変数やmixinの定義をしない
PC・スマホのCSS記述場所を離して書く
タグが適当（セマンティックじゃない）
CSS設計が考えられていない
補足コメントが全くない
ショートカットなどの早技を使わない

それでは一つずつ見ていきましょう！

NG例 1）すぐにコードを書き始める

デザインカンプをもらってすぐにコードを書き始めていませんか？

もちろんすぐにコードを書き始めてもコーディングはできるのですが、すぐにコードを書き始める前に実施しておくと良いものがあります。

check_circle すぐにコードを書き始める前にすべきこと

サイトのデザインカンプ全体を確認する
コンポーネント（部品）として使いまわせそうなデザインがないか確認する
実装困難な箇所や不明点があれば事前にデザイナーさんに確認しておく

これらをしておくと、後の作業が楽になります。

言われてみると当たり前のことかもしれませんが、
「とりあえず早くコーディングしてしまいたい」という思いがあるばかりに、
意外にできていない人もいらっしゃるのではないかと思います。

サイトのデザインカンプ全体を確認する

サイト構造として複数ページ（下層ページ）がある場合は全ページのデザインに目を通しておきましょう。
かつPC・スマホ両方のデザインカンプもあわせて見ておきましょう。

そうすることで、サイトのデザイン感、ページのレイアウト構造や何となくのコーディングのボリューム感などが認識できます。

ちょこすこーん

つまり先に「コーディングのゴールを確認しておく」ということです。
また次項の「コンポートネント」を見つける作業にも役立ってきます◎

コンポーネント（共通部品）として使いまわせそうなデザインがないか確認する

一般的なサイトの場合、ヘッダーやフッター・見出しなど必ず他ページに渡って同じデザインが使われているものがあります。

そういったものをコンポーネント（共通部品）と呼びます。

先にコードを書き始める前に、この「コンポーネントを探す」作業は非常に大事になってきます。

check_circle コンポーネントを探す重要性

予めコンポートネントとして認識しておくことで、CSS設計やクラス命名において効率の良いコーディングができる
いざスタイルを当てるときに、CSSのコード記述量を少なくできる

コンポーネントについては、CSS設計を意識していないと上手く活用することは難しいかもしれません。
もしCSS設計を知らない方は、是非一度勉強してみてください！
（一段階上のコーダーになるためには必須スキルだと思います）

ちょこすこーん

CSS設計についてもう少し詳細な情報について知りたい方は後述しますので、参考にしてみてください！

実装困難な箇所や不明点があれば事前にデザイナーさんに確認しておく

コーディングを進めていく中で、都度デザイナーさんに質問・相談している方もいらっしゃるかと思います。

私も最初の頃はそうだったのですが、そうするとラリーが増えたり、回答待ちになって作業が進まなかったりと、
互いに負担が増えてしまうことが多くなってしまいました。

そのためあらかじめ、
・不明点をまとめて質問しておく
・相談できることはしておく

このような姿勢が大事になってくると思います。

こうすることで負担を最小限にとどめ、コーディング着手時にスムーズに作業できるようになるはずです。

ちょこすこーん

ですがコードを書いていく内に出てくる質問も当然あると思うので、事前の洗い出し作業はそこまで時間をかけ過ぎなくて良いと思います◎

このようにすぐにコーディングに着手するのではなく、デザインカンプ全体に目を通した上で、コーディング設計を考えたり、事前に不明点や課題を解決しておくと効率の良いコーディングにつながります◎

NG例 2）変数やmixinの定義をしない

前節にもあるように先に事前作業を終えたら、いよいよコードを書いていきます。

ですがここでも準備作業として、「変数」および「mixin」の定義をしておくと良いです。
※この段階では通常リセットcssなども必要になってくるかと思いますが、今回はそこまでは触れませんのでご了承ください。

変数やmixinを定義しておくと、コードの使い回しが簡単にできたり、何度も同じコードを書く必要がなくなります。

変数やmixinについては、私のこれまでの経験に基づいですが、以下のようなものを定義しておくと便利かと思います◎

check_circle 変数で定義しておくと良いもの

サイトでよく使いまわされる色（メインカラー・ベースカラー・アクセントカラー等）
サイトのレイアウトに関わる数値（インナー幅、左右padding等）
サイトで使われている文字フォント（日本語フォント、英語フォント等）

check_circle mixinで定義しておくと良いもの

メディアクエリとブレイクポイント
その他よく使いまわすコードや機能

/**
* 変数の定義
*/ 

// カラー
$text-color--base: #333;
$accent-color: #FFBF80;

// フォントファミリー
$font-family--en: 'Roboto', sans-serif;

// サイトインナー幅
%site-layout: {
  max-width: 100%;
  width: 1000px;
  padding: 0 20px;
  margin: 0 auto;
  
  @include mq() {
    padding: 0 15px;
  }
}

/**
* mixinの定義
*/ 

// ブレイクポイント
$breakpoints: (
  'sm': 'screen and (max-width: 640px)',
  'md': 'screen and (max-width: 767px)',
  'lg': 'screen and (min-width: 768px)',
) !default;

// メディアクエリ
@mixin mq($breakpoint: md) {
  @media #{map-get($breakpoints, $breakpoint)} {
    @content;
  }
}

ちょこすこーん

変数やmixinを定義するにはSassを使うのが前提になりますが、これらの作業をしておくと効率良くコーディングができます。
私が新規サイトをコーディングするときは欠かさずやっています！

NG例 3）PC・スマホのCSS記述場所を離して書く

私が職業訓練で初めてメディアクエリを習ったときは、
以下のような感じでPC用のCSSを書く場所、SP用のCSSを書く場所でエリアを分ける書き方をしていました。

オススメしない書き方

.test-el {
  text-align: center;
}
.test-el2 {
  font-size: 20px;
}

/* SP表示 */
@media screen and (max-width: 767px) {
  .test-el {
    text-align: left;
  }
  .test-el2 {
    font-size: 12px;
  }
}

同じような書き方をされている方はいますでしょうか？

この書き方の大きな問題点としては、
1要素に対してどのようなスタイルが当たっているかをそれぞれ別の場所を確認しにいかないとわからない点です。

これはかなり非効率で、レスポンシブ対応時や修正時にファイル内の行き来が多くなるため、かなりのストレスになりかねません。
PCとSPくらいのブレイクポイント数だとまだマシですが、更にブレイクポイントが増えたときはかなりしんどくなります。

そのため、以下例のようにメディアクエリを書くときは、1要素に対し、1箇所にまとめてスタイルを書くことをおすすめします。

オススメの書き方

.test-el {
  text-align: center;
  @media screen and (max-width: 767px) {
    text-align: left;
　}
}
.test-el2 {
  font-size: 20px;
  @media screen and (max-width: 767px) {
    font-size: 12px;
　}
}

ちょこすこーん

こちらの方がメンテナンス性もあがり、他の人がコードを読むときの負担が軽減されますよ◎