5カ月でAngularJSとTypeScriptでSPAを開発。その技術の選択と開発過程は？（後編） Developers Summit 2016

シングルページアプリケーション（SPA）は、最近注目を集めているWebアプリケーションのアーキテクチャです。HTML全体の書き換えは行わず、変更が必要な部分だけをJavaScriptで動的に書き換えていくことにより、反応がよくユーザー体験にすぐれたWebアプリケーションを実現できます。

このSPAの開発を、技術の選択、仕様の策定、開発を含めて5カ月で行った経験談が、2月18日に都内で行われた「Developers Summit 2016」（通称デブサミ）のセッション「5か月でAngularJSとTypeScriptでSPAをつくった話」で紹介されました。

（本記事は「5カ月でAngularJSとTypeScriptでSPAを開発。その技術の選択と開発過程は？（前編） Developers Summit 2016」の続きです）

分からなければ即座に教えを乞い、まじめに答える関係を作る

開発を進めていく上で、コードの品質には妥協しませんでした。ちょっとでもヤバイなとか、ここはもっときれいにした方がいいと思ったら、スケジュールに余裕があろうとなかろうと、その場でリファクタリングしました。

開発は二人体制だったので、GitHubでのプルリクエスト方式を用いていました。そしてプルリクエストは優先的にさばく、というルールにしました。

人によっては、プルリクエストがたまってから対応するとか、朝にまとめてやるとか、いろいろあると思うのですが、われわれはなるべくすぐにプルリクエストを見て作業するようにしました。その理由はあとで説明しようと思います。

それから、分からないことがあったら即座に教えを乞う、先輩後輩関係なく、どんな初歩的なことでも分からなければ即座に聞いて、聞かれた方もどんな初歩的な質問でもまじめに答える。そういう人間関係を築くことを重視しました。これはすごく大事です。

そして2015年10月。開発も佳境にさしかかってきました。

大きな問題はなかったのですが、放置していた小さなバグが大量に積み上がってきました。二人ではさばききれなかったので、iOSとAndroidのエンジニアにも手伝ってもらいました。

彼らはあまりWebの開発知識はなかったのですが、コードを読めば分かるよ、という感じで。

そういう感じで、クロスファンクショナルで自分の担当領域にとらわれず、コミットしていく体制をとりました。おかげで1週間で50とか60のバグをつぶせました。

リリース直前に問題発生。IE9のサポートを切る決断

2015年11月下旬。もうリリース直前になってきましたが、ここにきて大きな問題が発生しました。

なんと、IE9だけで発生するクロスドメイン問題が発覚。IE9だけAPI疎通ができないんです。IE10でもIE11でもEdgeでも動く、Safariでさえ動くのに、IE9だけ動かない。

IEよ、おまえはどれだけわれわれを苦しめれば気が済むんだと。

もうIE9のサポートは切ろうか、というとき、プロダクトオーナーが弊社の別のサービスでのIE9の利用率を調べてみたんですね。そうすると8％。微妙な数字でしたが、でも切ろう、ということでIE9のサポートは切りました。

そのあと、リリース後にこの問題は改修しました。

そして2015年11月30日。「英語サプリ」のWeb版がリリースされました。

振り返るとリリースの2日前まで設計の見直しをしていましたし、リファクタリングも最後の最後まで手を止めませんでした。

開発中の残業はほぼなし、休日出勤もゼロで、ホワイトな感じで進められたかなと思います。

TypeScriptに救われた。型は正義

この開発で学んだことのまとめです。

まず、TypeScriptに救われたなと、つくづく思いました。個人的な考えですが、やはり型は正義だなと思いました。

TypeScriptは型推論言語なので、型は定義しなくてもいいようにできているのですが、われわれのプロダクションコードでは型を明示的に定義しました。

そのやり方は、コード量が増えて冗長なんじゃないか、と思われるかもしれません。が、もしそう思われるのであれば、僕はテキストエディタを見直した方がいいのではないかと思います。

もともと僕はSublime Textを使っていましたが、この案件が始まる頃からIntelliJを使うようになりました。

IntelliJはSublime Textと比べるとメモリ消費が多くてもっさり感は否めないのですが、コードの補完機能がすごく強力なので、コード量は増えましたがタイプ量はむしろ減ったように思います。

最近ですとAtomとかVisual Studio Codeとかもコードの補完機能が強力なので、そのあたりへ見直すのもいいのではないかなと思います。

それからTypeScriptはJavaScriptが苦手だな、という人にこそお勧めしたいと思います。僕もJavaScriptが苦手な一人だと思っているので。

JavaScriptではクラスの定義でfunctionを使ってそれっぽく定義しなくちゃいけないとか、ブロックによってthisの振る舞いが違ってしまうとかあると思うのですが、TypeScriptはそのあたりをきれいに解決してくれる、とてもよくできた言語だと思います。

ちょっとしたプログラムにはおおげさかもしれませんが、中規模大規模には力になってくれるのではないでしょうか。

AngularJSは学習コストを払う価値はあった

AngularJS、これも正解だったなと思います。フルスタックで大規模で機能が豊富なフレームワークなので、学習コストが高いと言われています。

たしかに学習コストは高いですが、その価値は十分にあったと思いました。

それからAugularUI Routerは規模に関係なく導入していいんじゃないかというくらい気に入っています。

この開発プロジェクトで学んだこと

そしてコードの品質に満足せず、絶えずリファクタリングをするのは大事だと痛感しました。

二人で開発をやっていると、自分が関わっていないコードの部分は理解できてないわけですが、リファクタリングを担当すると全面的にコードを見なきゃいけないので、コードをふかん的に見て理解するチャンスです。

最初は大変な作業ですが、慣れてくると200から300ファイルを書き換えるリファクタリングもやろうと思えばできるので、これは勇気を持ってやってみると見返りを得られるのではないかなと思います。

で、前に言ったことですが、プルリクは優先的にさばくようにしました。優先的にやれば相手に待たせることがなくなる、相手の作業をストップさせるのは良くないですし、たくさんプルリクエストをやっていると、お互いのコードが似てくるんです。で、似てくると、あんまりレビューすることがなくなるんです。

50、60ファイルをレビューして指摘箇所が2、3カ所になってくると、レビューのコストがかからなくなってきます。こういうところにプルリクを優先的にさばくことの意味ががあると思います。

Developers Summit 2016

• 5カ月でAngularJSとTypeScriptでSPAを開発。その技術の選択理由と開発過程は？（前編） Developers Summit 2016
• 強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016
• レイテンシに負けないプロトコルとして登場したHTTP/2～奥一穂氏による「HTTPとサーバ技術の最新動向」（前編）。Developers Summit 2016
• Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”（前編）。Developers Summit 2016
• エンジニアを成長させるためのマネジメントと組織づくりとは～アドテクを中心とする組織の取り組みの例。Developers Summit 2016