コーディングを教えていると聞かれるよくある質問のひとつに「どういう順番でコーディングしていますか？」というものがあります。
その度に、口頭で説明するのも大変なのでまとめてみようと思いました。
順序もそうですが、なぜその順序でやるのかや、その行間にある考えなんかも伝わればと思います。
一応の注意事項ですが、
- 自分がこうやっているというだけで、これが「正しい」ということではありません。
- 初学者はとくに真似をしてはいけない部分や、真似しようにも難しい部分もありますのでご注意ください。
という感じです。
違いがあってもそれでいいのです。
他の誰かがどのようにコーディングしているのかは常に参考になります。
ライブコーディングが流行っていますが、もしも誰かがコーディングしている様子を見られる機会があるのであれば、可能な限り見てみることをオススメします。
前提
とある商品のサイトかコーポレートサイトっぽい20ページ前後のサイト（LPなど1ページだけではないサイト）を「一人で」コーディングする場合を想定しています。
複数人でコーディングすることになった場合も多少は視野に入れますが、最初からコーディング規約でガチガチに縛らないと危険になるようなプロジェクトではないという前提です。
デザインは自分以外の誰かがやっていて、なんらかのデザインファイルを受け取ってコーディングをするという想定で、かつ、ワイヤーフレームはデザイナー以外の人が作っているという想定です。
中盤以降は数ページのポートフォリオサイトや、コーディング模写時にも参考にしていただけると思います。
最初に
まずですが、いきなりエディターとは向かい合いません。
登山をするのにいきなり山に登らないと一緒です。
まずは計画をたて、準備をして、それからです。
最初はワイヤーフレームをじっくり眺めます。
この時に見ているのは
- どんなページとどんな機能があるか
- 抜けているページなどはないか
- 要件外のページや機能が存在していないか
- 意味がわからない箇所はないか
- どんな構成のサイトなのか
└20ページ全部バラバラなのか、いくつかのページは共通レイアウトなのか - プログラマーに渡さなければならないページや要件はあるか
- スマートフォン/レスポンシブ対応の要件はどうなっているか
こんなところです。
言い換えればディレクターのワイヤーフレームに、ミスや漏れがないかなど、認識が正しいかを確認しています。
そしてここで疑問が出たら、即座にディレクターへフィードバックします。
ここで出るような疑問は基本的にクライアントに確認が必要なことが多く、正しい情報が揃うのに時間がかかるからです。
まぁ、実際の仕事現場では事前に工数見積もりなどをするので、その際にこの手順は終わっていることも多いでしょう。
ざっくりと工数配分をおこなう
次はざっくりと工数をイメージします。
これはデザインの内容にもよるので、ワイヤーを見ながらの時点では本当にざっくりです。
- TOPページに1日かかるなぁ
- 1日5ページやったとして、1週間でざっと仕上がるかなぁ
- あ、でもこのスタッフページは流し込みだからそんなにかからないなぁ
- ここまで今週中にできていればいいかな
- あ、でも水曜日飲み会だったな
- ここの情報が固まってないから先にこっちのカテゴリーからやった方がよさそうだな
- テスト環境ってどうするんだっけ
- あー、さっきのディレクターへの質問の中に入れるの忘れたなぁ
などなど、スケジュールに関わることをイメージして、同じく誰かに質問しないといけないことはないかを確認します。
コーディングだけではないですが、仕事を請ける際にどれくらい工数がかかるのかを見積もる能力はとても大切になります。
特に後輩を指導している時や、誰かに何かを依頼した時に感じますが、もちろん素早く仕上げてくれるのは嬉しいのですが、何よりも困るのが申告してくれた日時に出来上がらないことだったりします。
これはフリーランスとして仕事を請けたいと思っている人も肝に銘じて欲しいことです。
もちろんスピードは武器になります。ただ、しっかり守りを固めることも忘れないようにしてください。
コーディング規約を確認する
これがあるかどうか、どう運用されているかは環境次第だと思います。
会社で厳しく決まっているところもあれば、ほぼフリーダムなところ、クライアントから指定があれば守るという感じのところなど。
自社の規約であれば身についていることが前提となりますが、クライアントからの提示があればそれをじっくり読みます。
HTMLもCSSも基本的には仕様が存在するものですので、突拍子もないことが書いてあることはあまりないでしょう。時々ありますが…。
どちらかと言えば、厳しいか厳しくないかという確認が主で、厳しいといっても、ファイルの命名規則やCSSのプロパティの順番、インデントの付け方などが決められている感じかと思います。
これらの規約に対し、自分が普段おこなっているコーディングとの差分がどれくらいあって、どれくらい工数へのインパクトがありそうかを確認しておきます。
デザインを確認する 1回目
ワイヤーを眺めたのと同じ感覚でデザインを眺めます。
見ている点は、前述したワイヤーフレームを見る際の視点と同じですが、それに加え「ワイヤーフレームとデザインとの間で矛盾がないか？」もチェックしています。
- ワイヤーフレームとデザインとの間で矛盾がないか
- ワイヤーフレームを見た際の工数イメージとデザインを見た際の工数イメージに大きな差がないか
- デザイン漏れがないか
など、これも言い換えればデザインに、ミスや漏れ、ディレクターとの認識の祖語がないかなどを確認しています。
ここでも気になることがあれば直ぐにデザイナーに確認し、必要であればディレクターも交えて共通の認識を持てるようにします。
ディレクターやデザイナーがその案件に注力している間、マークアップエンジニアは他の案件をやっていたり、それも納品前の佳境であることが多く、基本的にその案件への参加が後手になりがちです。
ディレクターとデザイナーの間で共通認識が持てていることでも、遅れて案件に参加する以上は必ず確認した方がいいでしょう。
意外と新鮮な目で確認すると、当人たちでは気が付かなかった何かに気が付くこともあります。
デザインを確認する 2回目
ここからは脳内で簡易マークアップをします。
もう少し正確に言えばマークアップではなくCSSをイメージします。
デザインファイルを1ページずつ開きながら、
- 複雑なレイアウトはないか
- 使いまわせるセクションやオブジェクトはどの程度あるか
- ヘッダー/フッターは全ページ共通か
- 自分が苦手そうな箇所はあるか
- JavaScriptの実装はどれくらい必要か
- 画像はどれくらいあるか
- 画像以外で特殊なフォントを使っているか
- スマートフォン/レスポンシブ対応の要件はどうなっているか
- ブレークポイントどうしようかな
- おー…このページだけ全体の横幅が違うな
といった感じでコーディングをしながら出てくるであろう疑問を洗い出します。
なるべく確認したいのが、
- 自分だけではできないかもしれない箇所
- とても時間がかかりそうな箇所
- 調査が必要な箇所
- 要確認箇所が1回目のデザイン確認で漏れていないか
といったところです。
不確定要素と言った方がわかりやすいでしょうか。
とにかく先になんらかの手を打っておいた方がよさそうな不安要素を洗い出します。
コーディング開始
いよいよコーディング開始です。
ほとんどの人がここから読みたかったのではないかと思いますが、ここからはあっという間かもしれません。
プロジェクト用のフォルダを開いてファイルを作りますが、多くの人が自分なりのスタートセットを持っていると思います。
前プロジェクトのコピーでもよいですが、企業名などの書き換えを忘れて怒られているケースを何度も目にしているので基本的にオススメしません。
なるべく早い段階で自分なりのテンプレートセットを作ってしまうことをオススメします。
作ってしまたら、DropboxなりGitHubなり、任意の方法で管理しておけばどこからでも読み出せて便利です。
極端な話、最初は何も書かれていない index.htmlファイルと画像格納用フォルダだけでもよいかもしれません。
エディタ遍歴については別途書く予定ですが、最近はVSCode（Visual Studio Code）を使用しています。
マークアップ
ワイヤーフレームでもデザインファイルでもどちらでもいいので、テキスト情報が正しい方のデータを開きマークアップしていきます。
僕はあまりやらないですが、ファイルからテキストデータだけを抽出して一気に貼り付けるという方法もあります。
また、デザインデータ次第ですが、自動でHTML掃き出しをするツールを使用してもいいかもしれません。
最近はAdobe XD や Sketch で作られたデザインカンプを自動でHTML出力してから自分なりの調整を入れるといったやり方もよいかもしれません。
なるべくキーボードを打っている時間や、コピペをしている時間を減らした方が早くなります。
前述したように、自動出力されたHTMLやテキストに対し、マークアップをし直すのが早いとは思います。
もちろん、これは基礎力を持った人や経験豊富な人がやれる手法で、あまり知識や経験のない方が「これでいいじゃん」という姿勢でやるべきことではありませんので注意しましょう。
そしてこの時ですが、全部を完璧にマークアップしないことがあります。
具体的には、全体をざっくりと進めていき、時間がかかりそうなセクションは、sectionタグだけ書いておくことがあるという感じです。
特に文字列が多くてコピペが面倒な個所や、なんとなく修正が入りそうなところ、他のページと共通パーツになっているところなどは後回しにします。
これは、先に確認した時間がとてもかかりそうな箇所については特にそうする場合が多く、そうする理由としては以下のようなことがあげられます。
- なるべく全体感を先に掴み、残工数を読み易くする
- 指示変更によるやりなおしを極力減らす
- 汎用性のあるパーツを作れるようにする
この辺りのことは経験からくるものも多いので、初めのうちは全部マークアップしてあげるのがいいでしょう。
強いて言えば、
例えば「スタッフ紹介」のようなセクションで、必ず「写真・名前・役職・コメント」がレイアウトされていて、既に10人分のデータが入っていたとしても、一人分をまずは作ったら、残りの9人分は全部一人目のものをコピペしておくというくらいのことからやってみるとよいかもしれません。
理由としては、
- 名前の表記が間違っていた
- 役職が変わっていた
- コメントを差し替えたい
- 写真はまだ仮の状態
こんなことが起こりうる中で、10人分、全部画像の切り出しも含め100％実装しておく優先順位は低いからです。
特に画像の配置はしないか、したとしても同じ大きさのダミー画像を用いることが多いです。
この「あとまわし」を覚えてくると、コーディングのスピードだけでなく、修正などの対応も素早くなり、臨機応変な対応が可能になってきます。
CSSを書き始める
SASSやCSS変数などを使用しているのであれば、各種定義をおこなっていきます。
ワイヤーのチェックやデザインのチェックをしっかりやっていれば、何を変数にするのが望ましいかが8割くらいはわかると思います。
もちろんここで完璧にする必要はありません。
この値も変数化してしまえと思うたびに追加すればよいでしょう。
SASSなどを利用していない場合はそのままCSSを書いて行きますが、この段階ではCSSの分割はあまり考えません。
- サイト全体に関するもの
- ヘッダー
- フッター
- レイアウト
- 汎用class
- 汎用パーツ
- ページごとに書くべきもの
くらいをざっくりとコメントをつけて分けながら、ひとつのcssファイルに書いていきます。
最初からファイルを分割すると、ファイルの往来に時間がとられるからです。
また、スマホ用、PC用、どちらから書くかはその時次第ですが、僕の場合は基本的にはPC用から書くことが多いです。
モバイル（スマホ）ファーストであることと、CSSをどちらから先に書くべきかに相関性があるわけではないからです。
そもそもPC用といったような書き方自体がナンセンスかもしれませんね。
画面の幅がより広いものから書くことが多いですという方が適切かもしれません。
そして初期実装中はPCとスマホを行き来したりしないです。
どうしても気になる箇所はChromeのデベロッパーツールで確認するようにしています。
必ずしも上から順番にCSSを書くわけではない
昨今のデザインはそうでもないですが、一昔前はヘッダからファーストビュー、メインビジュアル部分が一番凝っていて、一番時間がかかることが多かったです。
そこに時間をとられると、半日かけて1スクロール分も進んでいないというようなアウトプットになります。
すると最初のうちは残る部分にどれだけの工数が取られるか正確な判断が難しいため、焦りが出てきます。
ディレクターなどからの「まだそこまでしか進めてないの？大丈夫？」的な視線も感じるかもしれません。
もちろん、難しい箇所をあとまわしにして「出来なかった」では済まされませんが、その確認はコーディング開始前に終わっているはずです。
要は、どれだけ時間がかかるかだけの話なので、時間配分を考えながら簡単なところから進めてしまう方が自分も安心しますし、ディレクターなどにも「ここまで進んでいます」と進捗を報告することができるでしょう。
そうやって内外の雑音を減らすのもスピードを上げるコツです。
僕は全体のレイアウトを行ったら、フッターを組み上げてしまうことが多かったりします。
デザインルールから外れているものがあれば確認する
CSSを丁寧に書いているとなるべく共通化したくなるのが普通だと思います。
そんな中、ずっとmargin-bottomが40pxであったはずの箇所が、とあるページだけ45pxであったりすることがあります。
揃えてしまいたくなりますが、それが意図的にそのようにされているのかもしれない場合、揃えてしまうのはエゴになってしまいますので、必ずデザイナーに確認するようにします。
こういうやり取りが少なくてすむ方がスムーズではありますが、こういった細かいやり取りの中でデザイナーの癖や特長なんかを理解していくのも、後にツーカーの仲になるには必要かもしれません。
お互いがプロフェッショナルで、何も言わなくてもデータのやり取りだけで成立するのが格好いいのはその通りですが、もうすこし人間味があってもよいのかなと僕は思います。
実装中の確認はChromeだけ
もちろん途中提出や納品前には他ブラウザでも確認しますが、実装中はあまり多くのブラウザを行き来しません。
IE9以前のブラウザが対象ブラウザに入っていたり、ベンダープレフィックスが必要そうな新しめのCSSを使用する場合は確認するようにしますが、それ以外はだいぶブラウザの差異もなくなってきているので、よっぽど斬新な書き方をしない限りは大きくズレが出ることは少なくなってきています。
ブラウザを行き来する時間を節約しましょう。
どうしても心配であれば、1ページ単位くらいで確認するのがオススメです。
また、もしもそれで別ブラウザで崩れている場合、残念な気持ちになるかもしれませんが、それはそれでレベルアップするためのとても重要な意味を持ちます。
なぜ崩れたのか、なぜ意図した表示にならないのか、このなぜを突き詰めるのが次のステップへの足掛かりになるからです。
これを解明していくことこそが教材には書かれにくい経験の部分だったり、自分の理解が足りていない箇所だったりします。
案件の最中だったりすると焦りの方が強く、なかなかそのようには思えないかもしれませんが、コーディング模写や訓練の際は、むしろ「自分専用の課題が提示された」くらいに思ってもいいかもしれません。
画像を中心にレスポンシブ対応を行う
画像アセットの書き出しや軽量化は時間がかかってしまう項目のひとつです。
もちろん要件にもよりますが、特にレスポンシブ対応する際の画像サイズの決定やパターンの書き出しは気をつかうところでもあり、あまり何回も繰り返したいものではありません。
きちんとFIXした画像で1回で終わらせたいものです。
気になっているところや、まだ実装できない部分をリストアップする
あとは全ページコーディングすれば基本的には完了ですが、原稿が揃っていなかったり、写真の差し替えが必要だったり、自分の実装が納得いっていない箇所だったりが残ることがあると思います。
イメージする納品物との差分ですね。
特にmeta情報、OGPの情報、Goggleアナリティクスのタグなどなどは最後に入れることが多いかもしれません。
これらのやり漏らしが無いように、リストアップします。
faviconなんかは忘れがちかもしれませんね。
表現物として完成したらコードを整形する
説明が難しいですが、クライアントがブラウザで最終確認しているくらいのタイミングになったら各種コードの整理を行います。
SEO向けのチューニングと言ってもいいかもしれません。
- 汎用CSSをまとめる。または分割
- CSSやJavaScriptをミニファイ・圧縮
- 画像の軽量化
この辺りが主ですが、各種便利ツールや優秀なエディタ・プラグインを利用していれば既に終わっているかもれません。
1日～2日おいてコードの確認やブラウザでの確認をする
仕事ですとこんな余裕はないかもしれませんが、なるべく作品を客観的に見るタイミングを作るのが望ましいです。
成長中の人は特に「コードは書いた瞬間から古くなる」というくらい、よりベターな書き方が見つかると思います。
また、没頭中には気が付かなかったケアレスミスなんかも見つかることがあります。
「自分が書いたものではない」というくらいの気持ちで粗さがしをするといいでしょう。
ファイルの命名規則の違反や、単純なスペルミスなんかも見つかるでしょう。
細かいことですが、こういった確認が納品物の品質や、普段の作業の品質向上に繋がります。
さいごに
以上がだいたいの流れです。
「デザインを確認する 2回目」が一番頭を使う部分で、これが終われば実際に手を動かす前ではありますが、コーディングの半分くらいは終わった感じになります。
最初のうちは難しいと思いますが「コーディングしながら考える」ということはだんだんしなくなり、「考えてからコーディングする」という順番になってくると思います。
経験を積めば積むほどパターンが蓄積されていくので、デザインを眺めながら頭の中でCSSを書けるようになります。
この脳内コーディングはPCの前に座っていなくても練習は可能です。
新聞でも雑誌でも、電車内の広告でも、人からもらった名刺でも、食品のパッケージでも、目につくものであればなんでも題材になります。
「勉強」の時間がとれなくても隙間時間で「訓練」はできると思いますので、コーディングのスピードを上げたいと思っている方は試してみるとよいかもしれません。
もちろんコードを速く書くことも大事ですが、それに付随する各種作業をいかに滞らせないかや、同じ作業を何度もやらないようにする工夫など、全体を通して効率化していく方法というのも大事になります。
もっと速く、もっと速くだけを求めず、全体を最適化しつつ、無駄を省いていくことにも注目してもらえたらと思います。