A Baseline for Front-End Developers

Credit

This article is translated with permission of Rebecca Murphey.
You can find original article at A Baseline for Front-End Developers

本記事はRebecca Murphey氏の了承を得て翻訳された記事です。
原文はA Baseline for Front-End Developersにて掲載されています。

A Baseline for Front-End Developers

先日、ほかのデベロッパ達に見て、学んで欲しいと思っていたプロジェクト用にREADMEを書いている際、あることに気がついた。それは書いてあることが数年前の私にとっては驚異でしかないはずのNode, npm、Homebrew、git、テスト、開発用とプロダクション用のビルドについて、いかにもカジュアルに触れているということだ。

その昔、フロントエンド開発者にとって必須のワークフローと言えば、ファイルを編集し、ローカル環境でテスト(可能な限り)し、サーバにFTPでそれらをアップロードする、というものだった。私たちは自らの能力を、IE6を説き伏せて従わせることかあるいは、クロスブラウザでピクセルパーフェクトさを達成することで計っていた。私自身を含め、コミュニティの多くの人はきちんとしたプログラミングの経験がなかった。HTML、CSS、そしてJavaScript、普通はjQueryという形で、などは独習して得た技術だった。

この数年で何かが変わった。おそらくそれは人々がフロントエンド開発に対してまじめに取り組み始めた結果か、ブラウザベンダが彼らがやるべきことの多くをやり切り始めた結果なのか、あるいは私自身を含めたフロントエンド開発者達がいくらかは安定したソフトウェア開発のプロセスについて学び始めた結果かもしれない。

それがなんであれ、我々はトリビアに価値を見いだすことよりも、ツールに価値を見いだすことに重点をおき始めているのだと思う。フロントエンド開発者として成功するための新しいベースラインとなるスキルセットが現れはじめていて、そのベースラインを満たすことができない開発者達は、特定の事柄についていちいち触れなくてもすでに知っている人達から置き去りにされていると感じ始めているだろう。

ここでは*私*が考える、開発者達が慣れておくべきと考える事柄と、もしそれらについて素早く覚えたい場合に利用できるリソースについて触れていこう。(Paul Irish、Mike Taylor、Angus Croll、そしてVlad Filippovの助言に感謝したい。)

JavaScript

もはや言わずもがなかも知れないが、単にJavaScriptのライブラリについて知っている、というだけでは十分とは言えない。それらライブラリにある機能をすべて素のJavaScriptで実装する方法を知っていなければならない、という意味ではなく、実際にいつライブラリが必要となるのか、そして必要としないと判断した場合に素のJavaScriptだけでも実装できるようになっておくべきだ。

つまりJavaScipt: The Good Partsをできれば1回以上は読んだことがあるということになるだろう。オブジェクトや配列のようなデータ構造について理解し、関数、callapplyをどうして、そしてどのように使うかを理解し、プロトタイプ継承を利用し、そして非同期性をどのように管理するかを理解しているということになる。

素のJavaScript力が弱いと感じたら、以下のリソースは理解の手助けとなるだろう:

Git(とgithubのアカウント)

もしGithubを利用していないということは基本的にフロントエンド開発に関する技術周りで立ち上がり始めたリッチなオープンソースコミュニティに参加できないことと同じことだ。レポジトリをクローンし、試してみる、は習性となっているべきで、プロジェクトにおけるブランチを使ったコラボレーションの方法についても知っておくべきだ。

gitのスキルを高めたい?

モジュール方式、依存関係の管理、そしてプロダクションビルド

依存関係の管理をページに対してスクリプトやスタイルタグを追加していく方法で行う時代は終わった。もしRequireJSのような素晴らしいツールを会社内のワークフローとして組み込めないとしても、得られる利益は非常に大きいため、個人プロジェクト内やBackbone Boilerplateの様なプロジェクトで、詳しく調査する時間を作るべきだ。特にRequireJSは小さなモジュール方式を使ってJSとCSSを開発でき、RequireJSの最適化ツールを使って、プロダクション用にファイルを結合し、ミニファイも行ってくれる。

AMDについて懐疑的? 何もしないことへの言い訳にはならない。最低でもUglifyJSClosure Compilerのような効率的にミニファイを行ってくれるツールについて知っておくべきだ。そしてミニファイされたファイルをプロダクション前に結合しておこう。

もし素のCSSを書いている場合でも、つまりSassやStylusのようなCSSプリプロセッサを使っていない場合でも、RequireJSはCSSファイルをモジュール方式にすることを手助けしてくれる。@import宣言をベースファイル内で使って、開発中は依存するファイルを読み込み、RequireJSの最適化ツールを使ってプロダクション用のファイルを生成することができる。

インブラウザ開発ツール

ブラウザベースの開発ツールはこの数年で驚異的な改良がなされてきている。そしてそれらの使い方をを知っていれば、開発に対する体験を驚くほど改善することができるだろう。(ヒント: もしalertを使ってコードのデバッグを行っているなら、多くの時間を無駄にしている。)

自分が主に利用するブラウザに搭載されている開発ツールを使うべきだが、私は最近ではGoogle Chromeの開発ツールを偏愛しているが、ユーザからのフィードバックを元に定期的に便利な機能を追加しているため、ほかのブラウザに搭載されている開発ツールを無視するのもよくない。例えばOperaのDragonflyには、特筆するべきいくつかの機能が搭載されている。例えば、(実験的な)CSSのプロファイラ、カスタマイズ可能なキーボードショートカット、USB接続を必要としないリモートデバッグ、そしてカスタムカラーパレットを保存し利用できる機能などだ。

もしブラウザ開発ツールに対する理解が浅い場合はFixing these jQueryステップデバッグを含むデバッグ手法について素晴らしい(そして特にjQuery中心というわけでもない)まとめとなっている。もし既知でなければ、これまでの人生を変えるようなことを学ぶことになるだろう。

コマンドライン

コマンドラインに関して言うと、使うことに不快ではないというだけではもはや十分ではない。もしターミナルウィンドウに向かって手を動かしていないようでは、多くのことを見逃しすぎていると言える。ターミナルを使って何から何までやらなければならないとは言ってはいない。gitのGUIツールを奪いとりたいのではなく(そのうち利用しない方がよいとは思うが)、どんなプロジェクトをしていようと、いつでもターミナルウィンドウを開いた状態であるべきだ。いくつかのコマンドラインのタスクは考える必要もなくできるようになっているべきだ:

もし何度も使うコマンドがあるなら、.bashrc.profileか、.zshrcか何でもいいので、エイリアスを作って、コマンドのタイピングを省略できるようにしておこう。~/.gitconfigに対してもエイリアスを追加することもできる。Gianni Chiappettaのdotfilesは何が可能なのかについて素晴らしいインスピレーションになるだろう。

注意: もしWindows環境の場合は、Cygwinを推薦する以外、私にはどうしていいかもわからない。いいか悪いかはさておき、Windows環境でオープンソースのフロントエンド開発者のコミュニティに参加することは実質的に難しくなりつつある。よい点はMacBook Airは非常に安価で、強力で、馬鹿げているくらいポータブルで、もちろんいつだってUbuntuやほかのLinux達も存在している。

クライアントサイドテンプレート

サーバがXHRに対してHTMLのスニペットを返すことが当たり前だったことはそれほど前のことではない。しかし、この12ヶ月から18ヶ月の間に、フロントエンド開発者コミュニティはサーバから純粋にデータを返すように要求しはじめた。それらのデータをDOMに挿入できるHTMLに変換するのはコード内で直接行うと乱雑でメンテナンスが難しいプロセスだ。
そこでクライアントサイドテンプレートライブラリが登場する。テンプレートライブラリ達はデータと結合してテンプレートをHTML文字列にしてくれる。どのテンプレートツールがいいかわからない? Garann MeansのTemplate Chooserは正しい方向に導いてくれることだろう。

CSSプリプロセッサ

Paul Irishが以前述べたように、フロントエンド開発者達が書いたコードがプロダクション時には全く異なっているというような状況が見られるようになってきた。CSSプリプロセッサで書いたコードこそそれらの例と言える。まだピュアなCSSを書くことが唯一の方法だとする人達もいるが、彼らも変わり始めている。これらのツールはCSSのデフォルトとしてすでにあるべき変数や、計算、ロジック、ミックスインなどの機能を提供している。そしてCSSのプロパティにつけるベンダープリフィックス達をきれいにすることもできる。

テスト

モジュール方式で、疎結合なコードを書くことの楽しみの1つが、書いたコードがテストするのに簡単なコードとなることだ。そしてGruntのようなツールを使えば、テストを含んだプロジェクトを設定するのは簡単にできる。GruntはQUnit連携をデフォルトとしているが、テストフレームワークの中から(JasmineMochaが私の今のお気に入りだ)自分の好みにあうスタイルから選ぶことができるし、ほかの連携するツールも多く提供されている。

コードがモジュール方式で疎結合であればテストは楽しいものだが、そうでもないコードに対してテストを行うことは難しいか不可能の間のどこかにある状態となる。裏を返すと、テストを書くことを強制することで(もしかしたらコードを書き始める前から)、考え方とコード自体を体系化する手助けとなるということになる。将来コードをリファクタする際に自信を持ってできるようにもしてくれる。

自動化プロセス(rake/make/gruntなど)

Gruntが持つユニットテストをセットアップするビルトインのサポートが自動化プロセスの例だ。非常に多くの繰り返しの作業が存在するのがフロントエンド開発の実情だ。しかし以前私の友人が言ったとおり、よい開発者はめんどくさがりな開発者だ。大まかなルールとして、もし3回同じことを繰り返すようであれば、自動化するべきだ。

makeのようなツールは長い間自動化プロセスの手助けをするために存在しきた。ほかにもrakegruntなどもそうだ。ファイルシステムに関連するようなタスクを自動化する場合はJavaScript以外の言語を学ぶことは非常に役に立つ。Nodeの非同期性はファイルを操作するのに重荷になるからだ。ほかにもタスク中心の自動化ツール、例えば、デプロイのためのツール、ビルド生成のツール、コードクオリティチェックなど、はたくさん存在している。

コードのクオリティ

もしこれまでセミコロンの抜け漏れや余計なカンマで嫌な思いをしたことがあるなら、コード内の小さなミスによる時間の無駄がどれほどのものかわかるだろう。だからこそ、JSHintのようなツールを使っているわけだ。JSHintは設定を変更でき、エディタやビルドプロセスに連携するための多くの手段も提供している。

よいマニュアル

そう、フロントエンド開発にマニュアルは存在しないが、MDNは非常に近い存在だ。よいフロントエンド開発者はmdnのプリフィックスを付けて検索エンジンで検索を行う。例えば、mdn javascript arraysのようにしてw3schoolsの利益重視の厄災から身を守るのだ。

最後に

どんなものでもそうであるように、ただ読むだけではエキスパートにはなれないし、中級者にもなれない。物事において唯一上達する方法はとにかく実行することだけだ。グッドラック。