こんにちは、システムチームのKです。
現在入社9ヶ月目、
本格的なHTML、CSSコーディングは2回目のメンバーのコーディングを見ているのですが、
何点か思うところがあるので、
ブログに書いてみようと思います。
それは、「コーディング内容の見ていることに違いがある」という点です。
結論から言うと、上司は次の3点を見ています。
・カンプと1pxのずれもなく再現されているか
・画面サイズを変えても、1pxのずれもなく、は守られているか
・カンプに表現されていないレイアウト時のコーディングが漏れていないか
「カンプと1pxのずれもなく再現されているか」
これは言葉の通りです。
カンプ上に表現されている要素が、WEB上で1pxのズレなく配置されているか見ます。
「px」で計測できるものはすべて対象です。
‐ width、height
‐ 余白(margin、padding)
‐ フォントサイズ(font-size)
‐ 行間(line-height)、文字間(letter-spacing)
‐ top、left、right、bottom値
良く出てくるものはこれらです。
これらをキチっとカンプから測って、CSSに落とし込んでいるかを見ています。
「画面サイズを変えても、1pxのずれもなく、は守られているか」
カンプはあくまで、画面幅を固定して作られたものです。
しかし、ユーザ側の画面は様々なサイズがあり、
それらに漏れなく対応することが求められます。
【参考】
「カンプに表現されていないレイアウト時のコーディングが漏れていないか」
少し例を挙げてみると、
・見出しが複数行になったときはどうなるのか
・画像の枚数が1枚⇒4枚になったときはどうなるのか
・グローバルメニューの数が減ったときはどうなるのか
などなど…
特にデキテルを含め、CMSにおいては、ユーザ側で変更できる箇所が多いため、
カンプに表現しきれていない項目が多数出てきます。
逆にそれらを表現できているカンプが出てきたら、
コーダーの負担を減らそうと工夫してくれている、デザイナーの思いやりだと思うので
素直に感謝しましょう。
経験が少ないコーダーは特に3つ目の
「カンプに表現されていないレイアウト時のコーディングが漏れていないか」
で差し戻されることが多いです。
これは、経験が少ないと
基本的に見えているもので、合っている、間違っているを判断するからです。
今画面に表示されている要素だけしか見ていないということですね。
見出しや本文に入る文字、文字数を変えたり、
画像の位置や枚数を変えてチェックする必要があります。
経験の少ない部下が陥りがちなこと
「綺麗なコードを書く」
綺麗なコードを書くことは悪いことではありません。
ですが、これは+αの内容です。
求められているのは
「サービスが対応可としている環境下で崩れが起こらないHTML・CSS」
です。
綺麗なコードが書けた ≠ 崩れが起こらないHTML・CSS
特に、デキテルのCSSコードのように、
一度リリースしたものから大きく変えることが無いものは、
コードが汚かろうが、WEB上で見たときに、100%崩れなければ問題ないわけです。
新しいデザインを作るときは、
別のCSSファイルになりますからね。
綺麗なコードを書くと、
メンテナンス時のコストを減らすことが出来るメリットがありますが、
結局メンテナンスを頻繁に行わないコードならば、その恩恵を感じる機会がそもそもありません。
綺麗なコードを書くために時間を使うくらいなら、
汚くても良いので、正しく動くコードを書いた方が良いです。
汚いコードは長く、パフォーマンスに影響がでるというかもしれません。
確かにそれは正解で、その着眼点をもつことは良いですが、
それならもっと改善すべき点があります。
【参考】
CSSが数百行変わる程度で劇的に変わるものではありません。
「トリッキーなコードでうまく表現しようとする」
代表例は
・position:relative、absolute を使った要素の配置
・疑似要素before、afterを使った背景配置
・transform系 のプロパティを使った表現
例、、、と言いましたが、この3つがほとんどです。
この3つを使うことに違和感を感じない人が多いなと思います。
ググったときに、CSSテクニック系のサイトを見れば、
やり方を書いているサイトがいっぱい出てくるので
それも当然なのかなと思います。
ですが、基本的には、やるべきではない実装方法です。
HTML・CSSコーディングは、
「長方形」の要素を「上から順に隙間なく並べていく」ことです。
上で挙げた3つの実装方法は、
上記の定義に反することになります。
しかし、これらを使うことで表現の幅が広がることは確かなので、
使用することを禁止するわけにはいきません。
ここで伝えたいのは
「使わない方法があるならその方法で実装しなさい」
ということです。
むやみやたらに便利だからと飛びつくと、
崩れの収拾がつかなくなってしまうからです。
少し長めになりましたが、
見ていることの違いについて書いてみました。
なにか書いてあることに質問や、疑問点があれば
僕で良ければ受け付けますので、気軽に聞いてください。