IT系女子ログ

4年目Webデザイナー目線のあれこれ話。デザインもコーディングも勉強中。

新人Webデザイナーの私が、1年目で指摘されたことを振り返る[コーディング編]

Knowledge Work Code Web

f:id:tosssaurus:20150321135745j:plain

未経験からWebデザイナーに転職して、2年目に突入しました。
1年間チャレンジしてきて、数々の失敗をしましたし、注意も沢山して頂きました。まだまだ勉強が足りないなぁと思う次第です。
新人でなくなってしまうので、指摘されたこととその反省、2年目の目標を書き残しておきたいと思います。

おそらく皆様から見ると、当たり前すぎて書く程でないものも沢山あるでしょう…。"無知の知"ということで、私も1年後には、そのような気持ちで読み返せるよう、しっかり勉強したいです。

前回はデザインに関してまとめましたが、今回はコーディングに関してまとめていきたいと思います。

 

コーディング環境

Windows 8、Dreamweaver CS6を使用しています。
私の個人的な反省ノートとして、社内独自のものやDreamweaver固有のものも少し書いてあります。ご了承ください。
長々と書いており読みづらいかと思いますが、ご容赦頂けると幸いです。

 

指摘されたこと一覧

1. スライス

2. HTML

3. CSS

4. JavaScript

5. 全体的に

 

スライス

スライスする前にコーディングの目安をつける

f:id:tosssaurus:20150412160927j:plain

仕上がったデザインを渡され、コーディングをお願いされたら、いきなりスライスしてはいけません。まずは全体を見て、どのようにマークアップすべきかを考えます。
私が行っている方法は、まず1ページ全体を余白を多めにしてプリントアウトします。（私はA3でプリントしていました。）書き込みしやすいからです。
必ず確認するのは、見出しの順番やリスト、floatの方向やclearの必要な箇所です。これを書き込んでいきます。
余裕があれば、主要な要素のmarginとpaddingも、どの方向に何px必要か書き出します。そうすることで、marginの相殺がないか確認しておけますし、ボックスの幅も計算しておけます。

印刷して書き込んでいくというのは面倒でもありますが、コーディングが完了した後の振り返りができるので、初心者には特におすすめします。先輩に見て頂いて、どこの考え方が違うかも確認しやすいです。
先輩に見て頂くのであれば、多少キレイに書いておく必要がありますが、自分の理解だけの為であれば、気にせず好きなように書き込んでいけば良いと思います。まだ、スライス、コーディングと作業が残っているので、あまり時間をかける所ではないですもんね。

最近は慣れてきたので、単純なレイアウトのデザインの時は、頭の中で確認するだけですんなりスライス、コーディングと出来るようになりました。

スライスをする前にWebサイトをイメージする | Webデザインとグラフィックの総合情報サイト - MdN Design Interactive -

無駄なdiv要素やclassだらけのマークアップから卒業する方法 | コリス

 

デザインがズレていると感じたら必ずデザイナーに確認する

f:id:tosssaurus:20150412164733j:plain
※説明用で編集した画像です。実際はキレイにコーディングされています。

他の要素からズレて配置されてある要素は、忠実にズレを再現して良いのでしょうか？
1pxなどの中途半端なズレの時はミスの可能性が大いにありますので、必ずデザイナーに確認します。
コーディングはデザインを忠実に再現すべきなので、ズレがあるのは当然デザイナーに落ち度があります。しかし、コーディングが終わってから、実は1pxズレていたので修正を……なんて言われたら恐ろしいですよね。

ミスはつきものなので、ダブルチェック出来る機会があって良かったと思いながら確認しています。

コーダーから見た美しいデザインデータのつくりかた 素材作成編 | SRIA BLOG

http://qiita.com/tnj/items/10fc85b2dbcc30d576eb

 

スライスの名称に使用するのは半角英数字、
"-"（ハイフン）、"_"（アンダーバー）のみ

サーバーやOSによって、大文字小文字の判別方法が異なり、不具合が起きてしまう為です。
ローカル環境（自分のPC上だけ）ではうまく表示されるのに、サーバーにアップしたらうまく用事されない…なんてことも。
また、HTMLで大文字小文字の区別はないことや、プログラムでは大文字が特別な意味を持つ言語もあり、ネーミングルールは小文字で統一しています。

ファイル名の付け方

On SGML and HTML (ja)

 

画像を使用するのは最小限にする

f:id:tosssaurus:20150412205152p:plain

画像に頼りすぎたコーディングをしていては、画像が表示されない時にもの凄くみっともないページになってしまいます。
スマホサイトで良く見かけるのですが、PCと同じように画像を沢山使っているので読み込みが遅く、読み込まれるまでのあいだデザインが崩れてしまっていることもあります。

例えば、黒っぽい背景画像の上に白いテキストがあるデザインですが、もし背景が表示されなかったらデフォルトの背景色は白なので、画像が表示されるまでテキストが読めません。
表示されるまで待たされるユーザーはイライラして、ページを離れてしまいかねませんよね。最適な背景色を指定しておくことも大切なのですが、特にスマホサイトは画像は多用しない方がいいでしょう。

また、検索エンジンが読むのはテキストだけです。見た目の問題だけでなく、SEO的にも画像を多用しすぎるのは好ましくないでしょう。

動画読み込み時間、ユーザーが我慢できるのは2秒まで : ギズモード・ジャパン

iPhone 6対応!? スマホサイトに求められる３つのポイント

 

画像は最適にスライスする

たった1px、されど1pxです。ユーザーから見ると、角丸が途中で切れていたり、ジャギーが生じていたり、荒かったり、結構目立ちますよ。
反対にモノクロのベクター画像をJPGで書き出すなんてしていませんよね？最適な書き出しをして、少しでもデータを軽くしましょう。

JPGとPNGとGIFの違いを理解できるときれいで軽い画像が作れる！ | delaymania

Fireworksを教えることに！！ （スライスツールとWebに書き出し） | nuritategomen.com

 

デバイステキストの背景画像は可変するようスライス、コーディングする

レスポンシブデザインがいよいよ主流になりそうなこともあり、可変デザインは当たり前のことになってきました。
前回のデザイン編では、可変するところは、可変した際のデザイン崩れが起こらないよう想定してデザインする。と書きましたが、同じ内容です。可変する箇所を想定してコーディングしなければ、デザインがどれほど素晴らしくても、実際にユーザーが見る時は残念な表示になってしまうかもしれません。

また、可変を想定していないような画像を使っているのであれば、可変用の画像を作成するかどうか確認するべきでしょう。

グラデーション角丸＋リキッドレイアウトをCSSでコーディングする時の考え方 | Blog hamashun.com

新人Webデザイナーの私が、1年目で指摘されたことを振り返る [デザイン編] - IT系女子ログ

 

HTML 

HTMLのバージョンにあわせた文法で書く

以前、JSのコードをコピペしたときに正常に動作しなくなってしまったことがあります。コピペ元では正常に動くのに……。
原因を調べると、HTMLとXHTMLの記述の違いにありました。
以下のサイトがとても分かりやすいので、是非ご一読をおすすまします。

scriptタグを<script src="〜" />って書くと、なんで上手くいかないかまとめてみた - かせいさんとこ

HTML5でも<script src="hoge.js"></script>としなければならない理由は何か？ - C++ ときどき ごはん、わりとてぃーぶれいく☆

意味のないマークアップはしない

マークアップの本来の意味は文書の定義付け。「ここが1番目のタイトルです」「こことここは順不同のリスト」「ここは文章」などなど。マークアップ文書だと宣言しているのに、マークアップのルールを守らないなら、検査クローラーからの信用がなくなってしまうのも当然です。適切なマークアップは、SEO対策の基本とも言えます。

meta、title、discriptionは必ず正しく記入する

f:id:tosssaurus:20150412211130g:plain

これはSEO対策の中でも基本中の基本でしょう。ディレクターでなくとも気をつけるべきです。ディレクターが忘れてアップしようとしていたら突っ込みましょう。
とりあえず仮の文言を入れてアップしておく…なんてNGですよ!
一度間違ったものを検索クローラーに読まれてしまったら、訂正してアップしなおしても、反映されるのに数日かかる場合があります。大炎上になり兼ねません。検索クローラーの巡回があるまで反映されないらしく、2、3日かかることもあるとか。
例えば、"口腔外科"の診療所のタイトルやdiscriptionを"外科"と間違ってしまったら…。世界中、全国に不正な情報を故意に流していると見られてしまったら……。
クライアントからお客さんや業界からの信用を奪ってしまうでしょう。恐ろしいですよね。 

id、class名は適した意味の英単語を使う

これも、検索クローラーが読んでいるらしいです。SEO対策&英語の勉強になると思って、その都度調べています。
ただし、スペルが間違っていると検索クローラーが読んでくれない&外部の人に見られ時に恥ずかしいので、自信のないものはしっかり調べましょう。

固有の共通するスタイルを当てる箇所は、共通のclassを使う

なるべく単純明快、シンプルコーディングを心がけましょう。
分かりやすいのはもちろん、修正が入った時にひとつづつ探さなくても、一括で変更出来るので楽ですし、モレも少ないです。

h1は1ページにひとつだけ、hタグは順番通りに記述する

これもSEO対策になる、Web準拠コーディングの基本です。

空白文字やbrを使ってレイアウトしない

空白をいれると検索クローラーに単語が区切れていると判断されるため、正しくテキストを読んでもらえないようです。見た目調整はCSSでしましょう。

空白文字や"&"、">"、"<"など、
特殊文字や機種依存文字は文字コードで記述する

OSやブラウザによって表示されない可能性があります。必ず文字コードにしましょう。

imgタグにaltを必ず入れ、正しく記入する

SEO対策、Web準拠だからというのもありますが、ユーザビリティの視点からも入れておいたほうがいいでしょう。
万が一画像が表示されない場合、重要なテキストを画像にしていたら、文章の意味が通じなくなってしまったり、ユーザーに伝わらなくなったりしてしまいます。また、altの内容も音声を読み上げてくれます。 

ulの直下はliしか置けない

よくやってしまっていたのですが、ulの直下にli以外のタグを置くことは文法上間違いです。liの中はpでもdlでも割と何でも入れられます。

ul 要素に関する Tips - Neareal

IE6などのクロスブラウザに強くなる、22のHTML+CSSコーディングの基礎｜Web Design KOJIKA17

 

検証またはlintチェックを必ずする

目視チェックではどうしても限界があるので、HTMLの記述が正しいかどうか点数をつけてくれるlintチェックをしましょう。
始めからlintチェックだけでも良いでしょうが、私は自分の目を養う為にも、目視チェック後lintさんとの答え合わせをお勧めします。

lintさん、結構厳しいです。学校でコーディングしていたときは、平気で20点くらい取っていて赤ばっかりでした。

Another HTML-lint gateway

Another HTML-lint 5

 

リンクは正しく記述する

コーディングでデザインを再現することや、Web準拠、SEO対策はバッチリでも、リンクが間違っていたら、せっかく作り上げたサイトの効果が半減してしまいます。完成したら最後に、全てのリンクが正しいか確認しましょう。
また、別タブで開くかどうかも確認した方が良いでしょう。

【SEO】外部サイトへのリンク切れをチェックする - 検索サポーター

リンク切れをチェックする必要性と、オススメのツール３選をまとめてみた

 

CSS

意味のないスタイルはつけない

なんとなくwidth:100%とか指定していませんか？
「見た目は問題ないから、多少スタイルが重複してても気にしなくていい」というコーディングが許されるのは、趣味レベルまでです。なんとなく付けたスタイルが影響して、後々上書きしなければならなかったり、把握できていない見た目のズレが発生したりと不具合の原因になってしまいます。
何より、自分以外の方が修正しなければならない時にキチンと説明できなければ、すばやく引き継げないです。
シンプルでキレイな明快なコーディングをすることも、大切な業務のひとつです。

bodyは特別な理由がない限り使用しない

bodyは一番外側の要素です。
プログラムを入れて動的にする時など、どうしてもbodyにスタイルを書かなければならない場面があります。その時にbodyに書いてあったスタイルが上書きされたりすると、見た目が崩れてしまうかもしれません。
また、デザインが変わってどうしても外側に要素を置かなければいけない状態になってしまったら…大幅な修正が必要になってしまいます。
スタイルをつけるときは、bodyは使わないようにするのが無難でしょう。
 

HTMLの記述順に書く

自分のコーディングしやすい順番でスタイルを書くのは良いのですが、最後にHTMLの記述順に合わせてCSSの記述順も整理します。

これも、今は覚えているから支障はないかもしれませんが、後々の修正の時には自分の順番が変わっているかもしれません。自分以外の人が修正するかもしれません。

私は、最後に順番を入れ替える作業を増やすとミスの原因になるので、はじめからHTMLの記述順にスタイルを書くようにしています。

ただし共通のスタイルは上部にまとめて記述する

例えばテキストリンクの色などの共通のスタイルは、把握や変更がしやすいようにまとめておく方がいいと思います。
どこでも構わないと思いますが、必ず目にする、一番上に書くのが分かりやすいと思います。
 

子孫セレクタは不用意に使わない

修正しにくいコーディングの原因ですし、CSSが重くなる原因でもあります。
便利なのですが、divをulに変更しなければならなくなった時など、後々大変な作業を作ってしまうかもしれません。理由がなければ使わない方が良いでしょう。

CSS3以降の文法を使う際は都度、対応のブラウザチェックを行う

f:id:tosssaurus:20150412222331j:plain

css3は多様にデザイン出来るのでとても便利なのですが、まだまだ対応していないブラウザの需要があるのも事実です。
css3からのスタイルを使うときは検証してから使うようにしています。
反対にスマホ向けサイトは、現実的にcss3非対応のブラウザを使う状況は極々マレだと思います(と言うより、どうやってインストールするのか知りたいほどです)ので、あまり気にしすぎず使っています。

ショートハンドは不用意に使わない

子孫セレクタと同様、後々困りそうです。また、ブラウザによって不具合の原因になったりするらしく、社内では理由のない使用は禁止されています。

marginの相殺に気をつける

marginの相殺は、コントロール出来なくて相当悩ませれていました。
margin自体は要所要所で役に立つ、コーディングに欠かせない、頼りになる良いヤツです。よく理解してあげ、適度な距離で接することで仲良くなれると思います。
 

floatさせた方向にmarginはとらない

不具合の原因になるので、どうしても間隔を空けたいときはpaddinを使うといいでしょう。

font-sizeの単位は原則、%を使う

最適な背景色を指定しておく

スライスの項目で書きましたが、画像を使うときは、表示されない時の見た目を考えておく必要があります。ユーザーの環境によっては画像が表示されず、残念な見た目のサイトを見せてしまうかもしれません。

背景画像を使うなら背景色の指定も忘れずに [ホームページ作成] All About

画像を使用するのは最小限にする

 

JavaScript

必要な記述だけする

コーディング全般に共通することですよね。
 

意味の分からない記述があったら極力調べる

何もせず置いておくのが一番まずいです。それでは進歩がないので、苦手ですが、都度調べるようにしています。 
 

特定のJSが効かないときは、JSをひとつずつ追加していって検証するといい

私のJS不具合の原因TOP3は、

1. 外部ファイルのパス書き間違い

コピペの愚行です。本当、すみません。

2. スペル間違い
ここは面倒臭がらずコピペするようにします。すみません。

3. jQueryをリンクできていない
本当すみません。

以上経験則から、案外単純なところに原因があるものです。

 

コーディング業務全般

自分で書いたコードは必ず全て見返す

見返すことで、間違いに気づくことが出来ます。自分の良く間違えがちな箇所を知っておくことで、ミスはかなり減ってくると思います。
コードの整理をすることでキレイなコーディングができます。

2年目は、単純明快でキレイなコーディングを目指します。
Simple, clear & beautiful !

適切にコメントを使用して、読みやすいコーディングをする

今後の更新性を高める為に、書いておきましょう。自分はもとより、自分以外の誰かのためです。

リーダブルコードに共感出来ない人とは一緒にコーディングしたくない - ぼっち勉強会

ダメプログラマの8つの特徴 - Hack Your Design!

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

  • 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2012/06/23
  • メディア: 単行本（ソフトカバー）
 

 

サーバーにアップするファイルは把握しているものだけ、反映箇所は必ず確認する

大丈夫だと思って、フォルダごと一気にアップしていたのですが、テンプレートや使っていない画像など不要なファイルごとアップしてしまうと、容量が増え、表示が遅くなる原因です。
当初は不要なファイルをアップしていたことも把握していなくて、厳しく注意されました。今は、ファイル単位でアップするようにしています。

また、複数ファイルをまとめてアップすると、どこが反映されたかの確認が大変です。把握していない箇所があると、アップし忘れや、先祖返り(同じファイル名の古い方のファイルを上げてしまったりして、最新の状態から古い状態にしてしまうこと)などトラブルが起こってしまいかねません。
サーバーにアップするということは、自分だけしか見れない状態から、誰でも見れる状態にするということです。すなわち、アップした時点でクライアントやユーザーも見れます。

ミスはクライアントの信用にも関わってきますので、本番アップ作業は、とてもとても緊張します。

 

社内のコーディング規約を厳守する

ここまで長々と書いてきましたが、社内ルールがあればもちろんそちらが優先です。
チームで仕事をする以上ルールを守るのは、当たり前だけど大切、でも何故か怠りがちなんですよね。私も新年度なので、社内ルールを復習しようと思います。
また、Web業界は特にブラウザや書式自体のルールの変化が早いです。なので、数年前に作られた社内ルールでは、今の環境では最適でなかったりします。(テーブルレイアウトを推奨している制作会社はもう存在しないと思いますが…)
「今の環境に対応していないルールだな」と気づいたら、どんどん先輩や上司に確認するべきでしょう。

作業が詰まって、自力で解決できなさそうなら早めに報告する

「どうしても表示が崩れるから質問したいけど、先輩たち納期が詰まってて忙しそう…。これぐらいのこと聞くな！って怒られそうだから聞きづらい…。」 と思い、自力で解決しようと2時間くらい悩んでいたけれど、ふらっと来てくれた先輩に見ていただいたら、5分で解決した…。
というのはまだ幸せな方で、解決せず時間だけ使ってしまっていては、最悪先輩が引き取ってしなければならない。なんて事になってしまうかもしれません。

タイミングを見計らったり、声の掛け方や質問の仕方を考えたり、普段からの態度に気をつけたりして、いざという時に報告しやすい、助けを求めやすい環境を作っておきたいです。

 

2年めの目標

  • Simple, clear and beadtiful なコーディングをする
  • より速くコーディングする
  • HTML5、CSS3を使いこなせるようになる
  • JavaScriptを勉強する（簡単な書き換えが出来るくらい）
  • レスポンシブに慣れる

 

以上長くなってしまいましたが、ここまで読んで頂いて本当にありがとうございます。
同じく長々しいですが、デザイン編もよろしければご覧頂けると幸いです。

 

追記

3年目もまとめました。