2013/04/23更新

[取り組み] フロントエンドでコーディングスピードをアップさせる６つの方法！と思って書いてたら30個も書いちゃった。

こんにちは、@yoheiMuneです。
フロントエンドとしてHTML,CSS,JSを中心と開発を行うことを仕事にして早くも半年が経ちました。最近はだいぶ効率的にコーディングが出来てきたとやっと実感してきたので、ブログにも自分のコーディングスピードアップのコツを書きたいと思います！

「こんなのよりももっと良いのあるよ」などたくさんの感じる点があるかと思います。ぜひTwitterなどで教えて頂けると助かります。

コーディングをスピードアップする６つ＋αのポイント

自分が思うにコーディングをスピードアップする最も大切なポイントは以下ではないかと思います。

めんどくさいと感じること、そして改善に動くこと

幸い自分はかなりのめんどくさがり屋で、コーディング中も「これ手動！？」「マウス使うの？」とかいろいろと文句ばかりw。
それに伴い改善を行っていくことでいろいろとスピードアップしてきました。

今回紹介させて頂くスピードアップのコツは以下です。

確認サイクルを頻繁に行う、そして自動化する
スニペットを集める
Emmet(Zencoding)を使う
プロジェクト内テンプレートを作る
CSSプリプロセッサを使う
ノウハウのたまる記事を読む、ブクマする
その他もろもろ

では１つずついきまーす！！

１、確認サイクルを頻繁に行う、そして自動化する

確認サイクルを頻繁に行うことで、デバッグ時間を最小化しよう

コーディングスピードアップのコツで一番大切なのは、以下だと思います。

「コードを書いて、デプロイとかコンパイルとかして、ブラウザで確認する」という手順を頻繁に行うこと

自分の場合は、JavaScriptを１行なり1関数なり書いたらブラウザで動作確認し、CSSもmarginやheightなどを1行変えたり、新しいクラスを定義するたびにブラウザで動作確認を行います。
実装していて確認なしに10分委譲実装し続けたり、100行以上書いたりするとすごく不安になってきますw。

確認を頻繁に行うメリットは、「デバッグがめっちゃ楽」という点です。 JSエラーやスタイル崩れなどのバグが発生した場合に、疑うべきは自分の書いた"数行"コードのみ。デバッグ範囲が大変小さいのですぐにバグの箇所が判明してすぐに直すことが出来ます。

もしデバッグ範囲がJSファイル全体（300行とかあったり！！）とか、CSSの大範囲（HTMLの親要素や先祖要素も含むとか！！）という場合には、デバッグに10分とか1時間とかもしかしたら半日かかってしまい、すごく時間が無駄になると思います。

ということで頻繁に確認を行うことは、開発スピードを上げる上で超重要なことだと思います。

確認サイクルの手間を自動化して、確認サイクルを苦にしない

そして頻繁に確認作業をする手間（＝コンパイルやビルド、ブラウザへの反映など）を自動化することが重要です。頻繁に確認を行うたびに例えば10秒の手間がかかるとしたら、１日では30分？１時間？ほどの手間になるのではないでしょうか。確認を行う手間を最小限にすることにすごく注力するべきです。

自分は確認作業の自動化をgruntで行っています。
gruntで開発対象のファイルを監視し、ファイルの保存の度に、CSSプリプロセッサのコンパイル、ファイル結合、SFTP、ブラウザリロードなどを行い、自動でブラウザに反映されるようにします。

2013/04/23追記
gruntでブラウザリロードを行う方法を、こちらのブログに詳しく書きました。もし良ければご覧頂けると幸いです。

また多くの案件ではgruntでCSSやJSのミニファイを行いますが、開発中はデバッグしやすいようにミニファイはしない方が良いですかねー。

２、スニペットを集める

スニペットとは、「プログラムコードの断片」という意味です。
ある機能を実現するスニペット（例：リスト表示するHTMLとCSS、画面中央にダイアログを表示するJSなど）を集めておくことで、開発効率化を行います。そうです、いわゆる「コピペ」をするためです。

私はこのスニペット良いなぁと思ったら、このブログに残すようにしています。ブログを書くときにスニペットを自分で書いてみて、いろいろと理解するようにしています。先人の知恵を自分ものにするという感じです。例えば以下のような感じです。

- [CSS] HTMLとCSSを使って三角形を作成する方法
- [CSS3] display:boxを利用した実装サンプル６つ
- [CSS3] ビジュアルを変化させるCSS3Filterの内容説明と、Filter機能を体感できるページを作りました

完全コピペでいける場合は良いですが、少しずつ実装をアレンジする必要がある場合も多いので、一度自分で書いて理解することが良いかなぁと思います。

３、Emmet(Zencoding)を使う

急に具体的な話になりますがw、様々なブログで紹介されているEmmet（Zencoding）ですが、フロントエンドの開発ではやっぱり使うべきだと思います。特にHTMLのマークアップには必須です。

例えばこんな感じで入力して

div#header>ul#nav>li*4>a

変換を行うと、

<div id="header">
    <ul id="nav">
        <li><a href=""></a></li>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
    </ul>
</div>

こんな感じに展開されます。
少ないタイピングでたくさんのHTMLを生成できるのは本当に便利！！
なおEmmet（Zencoding）はCSSにも対応しているのですが、CSSは各種エディタが変換候補を出してくれることが多いので、私はEmmetのCSS用機能は使っていません。

４、プロジェクト内テンプレートを作る

これはHTMLとCSSに関するお話で、プロジェクトで色々なページを作る際に出来るだけコピペで対応できるような環境を作ると良いです。
１つのWebサイトやアプリケーションで、以下のような要素はいろんなところでほぼ同じデザインで使うことが多いのではないでしょうか。

ボタン
h1やh2などのタイトル表示
写真などのサムネイル表示
状態や属性を表すためのアイコン

上記のような多くの箇所で使われる素材は、templete.htmlを用意して使い回しができるように作成します。

また私はもう一歩やりすぎてw、１つのページでしか使わない特別なコンポーネントもテンプレートに突っ込んでおきます。テンプレートを見て、「このコンポーネント、こっちの画面でも使いたいなぁ」とか同僚と話すことも多いので、コンポーネントの共通化の会話のネタにもなってます。

テンプレートを作ることで、以下のメリットが生まれます。

コピペによる開発効率アップ
デザイン修正が簡単。テンプレートのCSSを直すとサイト全体が修正される
デザイン統一が出来る
マークアップのテスト（表示崩れが無いかとか）が1画面で大部分のテストが出来て効率的！

ということで、プロジェクト内のCSSテンプレートを作るといい感じに作業効率が上がります。

５、CSSプリプロセッサを使う

順番がバラバラw、次はツールのお話です。
CSSプリプロセッサをご存知ですか？使っている方も多いかもしれませんが、SCSS, StylusなどのCSSプリプロセッサを使うと作業効率がアップします。
CSSプリプロセッサとは、CSSを出力するためのCSSライクな記述を作成し、それをコンパイルすることでCSSを出力することが出来ます。例えばSCSSを用いた場合にはこんな感じになります。

// コンパイル前
.area01 {
  width: 320px;
  height: 320px;
  .label {
    display: block;
    padding: 10px;
    text-align: center;
    font-size: 150%;
  }
}

と書いてコンパイルを行うと、

/* コンパイル後のCSS */
.area01 {
  width: 320px;
  height: 320px;
}
.area01 .label {
    display: block;
    padding: 10px;
    text-align: center;
    font-size: 150%;
  }
}

何が便利かというと、自分は以下の点が良いと感じています。

入れ子構造で書くことで視覚的に分かりやすい: 視覚的に分かりやすいということは、理解もしやすく、メンテナンスもしやすいです。
Mixinとか関数とかいわれる共通処理を作ることができ、各所で利用できる。: Mixinや関数を定義することで、同じような処理を複数箇所で書かない（DRYの原則）をCSSでも行うことが出来、コードが綺麗になります。
ファイル分割も楽々: import機能を使うことで、コンパイル時に自動的にファイルを結合するなど、開発のしやすいファイル単位を構築できます。

CSSそのままだとプログラム言語とは言えない非力な感じですが、それを補うことの出来る機能がCSSプリプロセッサだと思います。 CSSプリプロセッサについては色々なブログで紹介されていますので、ぜひ使ってみてください！個人的には、Scssが入門にオススメです。CSSの記法は100%サポートされているためです。

６、ノウハウのたまる記事を読む、ブクマする

「最後は知識を貯えることは吉」ということを訴えたいと思います。
フロントエンドの仕事は（どの仕事も同じかもしれませんが）、知識量が品質と作業スピードに強く影響すると思います。「こーゆうこと実現したい」という内容や、「こーゆうところのバグは注意」など知識があればそれだけ問題解決への時間が短くなります。

自分は以下のブログ（一例ですみません）をRSSなどで読むようにしています。もしご参考になれば幸いです。

- はてぶITの人気記事
- PHPSPOT開発日誌
- havelog
- クラスメソッド開発ブログ
- OpenWeb
- ヨモツネット
- dotHTML5
などなど。

他にもいっぱいあるのでまた違うブログで、整理したいなぁと思います。ということでたくさんの情報を集めることがいいかなと思います。ぜひこのブログも宜しくお願いしますっw！

７、その他もろもろ

上記であげた以外にも、考えていたらいろいろと効率化でやってることあるなーと出てきたので、ずらずらと紹介したいと思います。

全般

疲れたら休む: 疲れを感じたら休みます。例えばJS実装中にセミコロンやカンマなしなどの不注意なミスを出し始めると、実装していてもちっとも進みません。休んで気分を一新してからまたコーディングに打ち込みます。
ググる時はEnglish！！: 技術的なことでググるときには、積極的に英単語を検索キーワードに入れて検索します。日本語情報はあんまり無いことが多いので。Google検索の設定で、英語をデフォルトにすると、いい感じの検索結果が上の方に出たりします。でもチュートリアル的な内容や基本機能は、日本語記事も充実しています。
StackOverflowはWelcome☆: 技術的なことを調べると良く出てくるStackOverflow。見っけたらラッキーと思うくらいな気持ちで読んだ方が良いと思います。解決策のヒントがいっぱいです。英語でも踏みとどまるべし！
毎日コーディングする: 毎日コーディングするとタイピングが早くなるし、メソッドの使い方とか忘れません。ただそれだけですが重要なことな気がしてます。
リファクタリングは、後でじゃなくて、今！: CSSでもJSでも書いていると、「前にも同じようなこと書いたなぁ」とか「このメソッドが肥大化してきたなぁ」と感じることは絶対あるはず！それを感じたらすぐにリファクタリングします。「このページの機能を作りきってからリファクタリングやろ」と思ってたら、やらずじまいになる可能性もあります。機能の実装が終わったらその機能への興味は薄れ、次の機能に興味が移っちゃいまして。。常にコードは綺麗な状態を保ちましょー。
DRYの原則はやっぱり大切です: DRY（Don't Repeat Yourself）という原則があります。同じことを繰り返すな、同じコードをそこら中に書くなといった意味です。共通化することは本当に大切です。共通化すれば変更時の対応がすごく楽だし、同じような機能で異なる差異を認識することも出来るようになります。
ソースコードはアート: 正確に動くかという機能要件、高速に動くかという非機能要件、どちらにも当てはまらないことですが、コードをめっちゃ綺麗に書くことは重要だと考えています。綺麗さ、エレガントさを追求するべきです。機能設計やコードの空白、コメントの割合など常に最高のものにすると良いと思ってます。
常に最高を追い求めると、次に似たようなことを書くときに、以前最高と思っていたラインから始めることが出来、さらに良きプログラムに飛躍できます。また最高の作品に指摘をされると、なぜだか素直に受け止められます（人によりけりだと思いますが）。

設計について

設計と実装は別々: 設計と実装は別々に行います。私は、実装中に設計も考えていたら頭が混乱するしコードも汚くなってしまいます。綺麗に設計できたものをすらすらと実装すると気持ちいいし、綺麗なソースコードを書くことができます。
メソッドのファイル行数は、最大でも画面の縦幅の2/3。でもできれば7行以内: 行数の多いメソッドを見るのは苦労するし、嫌気もさします。「あなたは簡単に言うと何者？」という問いに明確に答えられるぐらいの限定された責務でメソッドを定義すると、後から読んでもすんなり理解できます。
クラスファイルは200行以内: クラスについても同様です。「これもやってあれもやってそしてあっちもやって」的な責務の多いクラスは、理解しづらく、実装中から混乱します。例えばControllerクラスを定義する際に、入力チェックもやって、Modelも呼び出して、例外処理もして、Viewも呼び出してと処理いっぱいは読みづらい。適宜、DelegateパターンやTemplateパターンを使って責務を分担していくと綺麗な設計になりそうです。
難しいとは絶対に思わない。簡単に解けると信じ込む。: 気持ちの持ちようの話ですが、自分なら出来ると信じ込むと問題が解決します（ナルシストとは言わないでくださいw）。逆に「難しいなぁ」って思ってたらほんとに難しく考えてしまい解決しない気がします。気の持ちようの話です。
色々な言語に触れる。機能を学んだり、設計指針を学んだり。: フロントエンドで開発していても、node, ruby, Java, Objective-C, PHP, Cなど色々な言語に触れるべきです。また各言語で良く用いられるフレームワークにも接することが出来ると良いです。それぞれ言語やフレームワークから設計思想やコーディングルールを学ぶと、自分がメインで使う言語でのコーディングにもすんごく役に立ちます。
本も読んで学ぶ: 技術的なことのほとんどはググれば理解できますが、本を読むことも重要です。ググると断片的な情報を入手して満足してしまいますが、本を読むことでその他の情報も含め包括的に学ぶことが出来ます。包括的な知識（例えるなら大学で学ぶ１期分の講義）は応用力の源泉です。
githubをうろちょろする。人の書き方から盗む。: 最近流行のライブラリとかはGithubでコードが公開されていることも多いです。ぜひそのコードを読むべきです。読めば、色々なコーディングルールで書かれたコードがすらすらと理解できるようになるし、メソッドの分割単位、コメントの書き方、設計などをたくさん学ぶことが出来ます。
CSSのクラス設計をきっちりやる。: CSSは、モジュールという概念ものとに再利用・拡張が出来る設計を行うべきです。「基本形にこのクラスを追加すると、背景色が変わる」とかとか。経験も必要かと思いますが、変更に強い設計をCSSでもやるべきです。
JSの機能分割、ファイル分割、メソッドの責務はちゃんと考えて実装する。: また、JSも同じく設計を重視するべきです。例えばjQueryを使って長々とJSファイルを書くことで機能を実現することも出来ますが、あとあとの改修が大変。クラスやメソッドの責務を考えた設計をすべきです。最近では、gruntやrequireを使って開発しやすいファイル単位にファイルを分割しても開発することができるので、１つのファイルに500行とか書いちゃだめです。
将来の機能拡張を予想する: 実装を行う際には、将来の機能拡張をある程度予想します。「こーゆう機能ならあとでこんな機能追加もあるかも」とか「このデザインあとで変えたくなりそう」とか経験が必要な部分かもしれませんが、予想は大切です。予想はだいたい的中します。ただし、機能拡張のために無駄なコードがたくさん増えるなら、機能拡張があるまでやらなくていいです。無駄なコードは不要です。

開発環境について

軽量なエディタを使う: プログラムを書くなら、さくさくと変換候補が出たり、さくさくとタブが開いたりする軽量なエディタを使うべきです。EclipseやDreamWeaverなどの重量級を使って、ファイル保存に1秒待つとかファイル開くのに1秒待つとかはストレスになり、作業効率を落とす気がします。でもEclipseもドリもかなり便利なのですけどね。今私はSublimeText2を使ってます。
slowビルドは極端に嫌う: slowビルドとはビルド作業に時間のかかることを意味します。頻繁な確認を行う際に、CSSプリプロセッサのコンパイルなどが遅いとイラっとするし、効率も大変落ちます。ビルドやコンパイルが遅いなと思ったらそのときにすぐ対応すべきです。例えばCompassのコンパイルが遅くなったら、こんなのとか便利かも（つくりました、宣伝ですw）。
grunt-compass-multiple@github
PCのスペックには妥協しない: 開発するPCはやっぱり高スペックが良いです。メモリもいっぱいあって、CPUもコア数多くて、などなどさくさく動く環境で開発することが良いですね。
やっぱり広い画面がいい！: Macを使うならやっぱりThunderboltディスプレイが使いたい！広い画面は効率に直に影響します。

デバッグについて

怪しいところには、console.debugを、出来るだけログでわかるように。: デバッグツールはいっぱいあって便利ですが、個人的にはログでデバッグできるのが一番いいなと思ってます。デバッグツールをぽちぽちクリック（ブレークポイント設置やステップ実行など）は面倒です。怪しいと感じる箇所（引数ほんとに来てる？）的な部分にログを事前に仕込んでおいて、ログ見てパっと判断するとデバッグが早い気がします。デバッグログはどの言語でもだいたいは、プロダクションモードでは無効にするなど出来ますので、デバッグログは積極的に書くと良いと思います。
CSSのデバッグは、Chromeを活躍させる: といってもCSSのデバッグにログ出力は使えないので、こればかりはデバッグツールを使います。CSSのデバッグはやっぱりChromeの開発ツールが便利ですね。ぽちぽちと値を変えて変化をリアルタイムに見る感じ、好きです。
どーしてもつまったら、人の目を借りる: デバッグなどでどーしてもつまったら人の目を借りると良いです。ほんとに些細な問題（Functionをnewし忘れてるとか）の場合に、第三者の目はすぐにバグを発見してくれます。「ちょっと見てほしい〜」ってヘルプの声を出すときっと誰かが助けてくれます。
リファレンスを読むよりコードを読んだ方が早いときも。: 「このライブラリなんだか動かない」ってことありませんか？そんな時はリファレンスを読んで使い方やオプションとかを詳しく調べるよりも、ライブラリの該当コードを読む方が解決に早いことも多いです。「こーゆう実装だからこうしなきゃ動かないのか」とかリファレンスには無い良質な情報をたくさん得られます。

最後に

6つと思ったのですが、書いているとやっぱり全部書きたいと思って全部書いてしまいました。１つでも参考になることがありましたら幸いです=*＾-＾*=
「他にもこんな効率化してるよ！」とか「ここ詳しく！」っていう話がありましたら、ぜひTwitterなどで教えてください！

最後までご覧頂きましてありがとうございました。