この記事では、二人のエンジニアが書いたWeb開発者のためのアドバイスを紹介する。一人はおすすめの有用なツールとテクニックについて、もう一人はブラウザ向けに書くときに遭遇する課題への対処についてアドバイスしている。
今年のはじめ、BazaarvoiceのソフトウェアエンジニアであるRebecca Murphey氏は「A Baseline for Front-End [JS] Developers: 2015」というブログ記事を書き、クライアントサイドWeb開発に使えるツールとアプローチをJavaScript開発者にアドバイスした。記事を要約すると、彼女はこう言っている。
ECMAScript 2015を学ぶ。 Understanding ES6、ES6 Rocks、BabelJSがおすすめだ。私たちはこのリストにAxel Rauschmayer氏の新しい本、Exploring ES6を加える。Murphey氏によると、ECMAScript 2015について今日すべてを知るのは「必須」ではなく、非同期呼び出し、コールバック、Promiseの使い方について詳しく知ることをすすめている。
モジュールを使う。 「モジュールがクライアントサイドWebアプリケーションの構成要素であるべきだということに異論はない」とMurphey氏は考える。彼女はwebpackを使っているが、全員がECMAScriptのモジュールを使う日を期待している。
コードをテストする。 コードにテストを追加すること、そしてテスト可能なコードを書くことが重要だ。彼女はInternを「特に魅力的」だと感じているが、これまでの習慣からほとんどMochaを使っているという。また彼女は、Michael Feathers氏の『Working Effectively with Legacy Code』という本をすすめている。
プロセスを自動化する。 Murphey氏はこれまでGruntとGulpを使ったことがあるが、最終的にはYeomanを使っている。これは「不慣れな技術を使ってプロジェクトをスクラッチから始める」ときや、サードパーティのJavaScriptアプリケーションの開発を標準化するときに、真価を発揮するという。彼女はBroccoliについて、将来GruntとYeomanを置き換えるかもしれないと言及した。
質の高いコードを書く。 彼女はJSCSやESLintといったツールを使って、「プロジェクトで定めたスタイルガイドに違反」したコードをリファクタリングすることを推奨する。
Gitを使う。 他人の作業上にビルドするため、フィーチャーブランチを使い、「インタラクティブなrebaseを使ってコミットをまとめ、できるだけ競合しないよう小さな単位で作業し」、ghooksを使ってpre-pushおよびpre-commitフックを実行する。
サーバでHTMLを生成する。 パフォーマンスのために、大きなプロジェクトではできるだけサーバでHTMLを生成する、おそらくは「事前にHTMLを生成し、すばやく提供できるよう静的ファイルとして格納する – 、それから随時クライアントサイドのテンプレートを使って更新することで、HTMLに「潤いを与える」」ことを推奨する。
Nodeを採用する。 Web開発者はNode.jsについて精通するよう、少なくとも、Nodeプロジェクトの初期化方法、Expressサーバのセットアップ方法、リクエストをプロキシするためのrequestモジュールの使用方法について学ぶよう、彼女はアドバイスしている。
GoogleのソフトウェアエンジニアであるPhilip Walton氏は、最近ブログにHow to Become a Great Front-End Engineerという、異なるアプローチの記事を書いた。彼はツールやフレームワークについてアドバイスするというより、この分野で目にする課題の対処方法についてアドバイスしている。「良い人と、本当に良い人を分けているのは、何を知っているかではなく、どのように考えるかである」と彼は考える。彼はこうアドバイスする。
何が起こっているか理解する。 Walton氏にとって、機能するコードを書くことは十分ではない。動くようになるまでCSSとJavaScriptにたわむれ、そうして先へ進むという人を、彼はあまりにたくさん見てきた。いつかコードは動くだろうが、なぜ動くのか開発者はわかっていない。Walton氏は深堀りすることを推奨する。
あなたのハックがなぜ動くのか理解することに時間をかけるのは、今はコストのように思うかもしれませんが、将来あなたの時間を節約することになるということを、私はお約束します。取り組んでいるシステムについて十分理解することは、将来、試行錯誤で動かすことが減るこを意味しています。
ブラウザ全体の変化を予測する。 Web開発者は既存のコードを壊す可能性のあるブラウザの変更に、たえず注意しなくてはなりません。次のコードは、IE10がやってくると、JavaScriptフレームワークを機能不全にします。
var isIE6 = !isIE7 && !isIE8 && !isIE9;
仕様を読む。 仕様を読むのは辛い作業かもしれないが、Walton氏は次のような例を示し、ブラウザのページ表示が異なる場合には必要だと説明する。
タイムリーな例は、flexアイテムのデフォルト最小サイズです。仕様によると、flexアイテムの
min-widthとmin-heightの初期値はautoです（0ではなく)。つまり、デフォルトでは、コンテンツの最小サイズよりも小さく縮小されないということです。この8ヶ月、これを正しく実装しているブラウザはFirefoxだけでした。このクロスブラウザ非互換性に遭遇し、Chrome、IE、Opera、Safariでは同じように表示されるのに、Firefoxだと違って見えることに気づいたら、おそらくFirefoxがおかしいと思うでしょう。実際、私はそれを幾度となく目にしました。私のFlexbugsプロジェクトに報告されたイシューの多くは、実際この非互換性によるものでした。たとえ提案されたワークアラウンドを実装したとしても、（この問題が修正された）Chrome 44が登場すると（2週間前）、また問題になったでしょう。仕様に従ったワークアラウンドにする代わりに、彼らは知らず知らずのうちに、正しい振る舞いを間違っていると扱ってしまっていたのです。
コードをレビューする。 Walton氏によると、「新しいやり方」に心を開いて他人のコードを読むと、たくさんの学びがあるという。これはチームで働くのにも役に立つ。実際これはとても必要なことだ。エンジニアとしての時間の大半は、スクラッチから新しいコードを書くのではなく「既存のコードに追加したり、既存のコードを変更したりするのに費やされる」ためだ。
より賢い人と仕事をする。 Walton氏は、少なくともキャリアの開始時には、チームで働くことを「強く」すすめている。より経験のある人から学び、コードをレビューしてもらうためだ。もし後になってフリーランスとしてのキャリアを選んでも、オープンソースプロジェクトに貢献することで、チームで働くというメリットを得ることを提案している。
車輪を再発明する。 Walton氏は「車輪の再発明はビジネスにとって悪いことである」には同意しているが、学びにとっては良いことだと考えている。常にではないが、場合によっては、サードパーティのコードを使う代わりに、自分でコードを書くことをすすめている。そうする過程で、学べることがたくさんあるためだ。
学んだことを書く。 Walton氏の最後のアドバイスは、これまで学んだことを言葉にすることだ。「私の経験上、書くこと、話すこと、デモを作ることは、没頭して徹底的に理解するのに最善の方法のひとつです。たとえあなたが書いたものを誰も読まなくても、そうする過程に価値があるのです。」