LoginSignup
7
8

More than 5 years have passed since last update.

複数ページあるサイトのコーディングで学んだこと

Last updated at Posted at 2016-08-31
  • Sass
  • LaravelのBlade

の2つを使ったサイトのコーディングをしたときに思ったことをまとめてメモ。
HTML、CSS、テンプレートエンジンを使う場合にもしかすると参考になるかもしれません。

注意

この記事に書いてある事柄はあくまで私なりのやり方です。
「みんながこうするべきだ!」 という訳ではありません。

コーディング全般について

一度作ったHTMLはできるだけいじらない

デザインどおりのコーディングがなかなか上手くいかないときに CSS、HTMLのどちらもいじってなんとかしようとするとめちゃくちゃに なりやすい。

  • 基本CSSで修正
  • どうしてもむりならHTMLを足す

詳細度の高いCSSにしてしまうとHTMLを足したところで解決できないので、やはりCSSはできるだけ詳細度の低いものを合わせワザで使うほうがよさそう。

レイアウトはDOMに大きく依存する

1つ目とも関連すること。
レスポンシブサイトをつくるときに、CSSのメディアクエリだけでやろうとすると難しかったりする。
PCとスマホで大きくレイアウトが変わる時は 思い切ってDOMを2つ作り display: none 非表示にしたりして乗り切る のもアリ。

コメントを上手く使うべき

あとでコードを見返したときにわかるように。

  • なぜこのコードを書いたのか?
  • このコードはあとで消したほうが良い

というようなことを書いておくと、未来の自分にも他の人にも読みやすいコードとなる。
すなわち 破滅しない、読むのに無駄な時間のかからないコード となる。

テンプレートエンジン、部品化について

「使い回す」には2種類ある

1. どこにでも使い回す「部品」

例えばボタンとか。汎用的に使えるようパーツとしたいもの。
この場合に大事なのは CSSを上手に使う こと。

  • OOCSS等を使ってできるだけCSSを細かくわける(スキンと構造とか)
  • CSSのクラス名は汎用的にする(confirm-buttonよりbutton-red+button-containerで対応)

細かく分けてCSSを作ることでバリエーションが増えても対応できる。(sassの@mixinがおすすめ)
また、CSSのクラス名を汎用的にしておくと 想定外のところにボタンを設置することになっても変な感じにならない。

注意点

ボタン部分はDOMもbladeで部品化したことがある。
でもそうすると 「ここはaタグじゃなくbuttonタグなんだ・・・」 というようにDOMが違った場合に対応できない。
なので、 DOMは部品化せず、CSSだけを使い回す のが良いかと思う。

2. プロジェクト内でのみ使い回す「範囲」

「利用規約」+ 「規約に同意するボタン」部分なんかは「入力画面」と「確認画面」の2ページで使ったりする。
この場合は 同じデザインになるようにするのが大事 なので agreement-area のようにもっと 具体的で、どのページにあっても内容の予想がつくような名前 をつけるのが良いと思う。

やたらめったらDOMを部品化しない

数ページコーディングしてみて 「もういい加減コピペめんどくさいわぁ」 となったぐらいで部品化するのが良いかもしれない。
コンテンツ量の多いページを「部品化したほうが見やすいかな?」と思って全部部品化したことがあるが、全体レイアウトを調整するときに 部品化のし過ぎで全体のコードの見通しが悪くなる ということがあった。
なんでも分けたほうがいいってものでもない。
部品化は基本的に 使い回すときのコピペの手間を省くため ためだと考えるようにする。

納期はかならずやってくる、ということについて

コーディング初日なんかは時間があるせいでスケジュール感を意識せず進めてしまうことがある。
だけど 必ず納期はやってくる。
なので焦りすぎることはないが、次のようなことは頭の片隅において以後進めようと思う。

「概ね完成」の「概ね」を具体的に設定しておく

ある程度形になってくると 「細かいんだけど、できていないこと」 にとらわれるようになる。
そうなってくるといつがゴールなのかや 優先順位がわからなくなったり する。
「コーディングはレイアウト以外だけ終わらせる」など具体的に決めておくと、仮に終わらなくとも最初のスケジュールとのズレが把握しやすいので プロジェクト全体の遅れ には至らないような気がする。

完璧は目指さない、でも最低ラインは超える

もちろん完璧に越したことはない。
でも完璧を目指しすぎて 納期に間に合わないなら、いい仕事の仕方ではない。

恐れずに「何が遅れているのか」を書き出す

スケジュール通りにいかないこともある。
でも大きな遅れではなく、後でちゃんと対応できるのであればOK。
そこで大事なのは きちんと書き出し、他のプロジェクトメンバーとの共有 かなと思う。
「遅れ」に目を向けるのは少し勇気がいるけど、きちんと向きあえば「なんだ、これ来週にはフォローできるやん」と案外小さな問題であることに気づけたり、他のメンバーに手伝ってもらえる可能性も。
そして、仮に自分が体調を崩したとしても迷惑を最小限に抑えられるかなと。

7
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
8