AngularJSからNuxt.jsへ　noteにおけるフロントエンド開発環境の刷新

noteにおけるフロントエンド開発環境の刷新

fukuiretu氏（以下、fukuiretu）：では、『フロントエンド刷新中のnoteの開発環境について』というタイトルでお話しさせていただきます。よろしくお願いします。

（会場拍手）

fukuiretu：ありがとうございます。簡単に自己紹介なんですけれども、福井と申しまして、株式会社ピースオブケイクでエンジニアをやっています。普段は青森に住んでいて、今はリモートワークというかたちで働いていて、今朝6時くらいに家を出て東京に来ました。

まずnoteに関して簡単に説明をさせていただきます。noteというのはクリエイターとメディアのためのCtoCのプラットフォームになっていまして、できることとしては文章、写真、イラスト、音楽、映像などの作品を投稿することができます。投稿した作品を簡単に販売することができるようなサービスになっています。

現状こちらのnoteの技術スタックなんですけれども、Ruby on RailsとフロントエンドはAngularJSの1系とCoffeeScriptで書かれているような状況で、リリースされたのが2014年の4月なので約4年前なんですが、4年前からほとんど変わってないような状況になっています。

これはつい先日ですね。弊社のCTOからポストされた記事なんですけれども、現状このAngularJSの1系をNuxt.jsに刷新しているような状況です。

まだリプレイスはぜんぜん済んでないですけれども、一部のユーザーをデモの環境としてNuxt.jsのサーバーから配信をしているのでもしよかったら見てみてください。

明確なコーディング規約がなかった

本日のお題になるんですけれども、今日の勉強会のテーマが開発環境ということだったので開発にまつわるルールの改善状況についてお話ししたいと思っています。

まず現状ですね。明確なコーディング規約がないという課題がありまして、現状どうやってるかと言うと既存のコードを見て文脈を合わせるようなかたちでコーディングしていて、実装者に完全に依存しているような状況です。

これは例で書いたサンプルのコードで、CoffeeScriptのコードなんですけれども。演算子のエイリアスを使ったり使わなかったりというようなことがあって、シンタックスがまちまちになったりするといったことが発生しています。

これに対してまず1つ目の改善なんですけれども、ESLintとPrettierを入れて構文チェックとフォーマットをシステマチックにやるようにしました。

Nuxt.jsを入れたことによってここの黄枠の部分が主に規約になるんですけれども。

規約の例としてディレクトリ構成ですとか、ルーティングを一定のルールで自動生成してくれたりですとか、あとは非同期処理の作法を提供してくれたりですとか。あとはプラグインの機構を用意してくれたりですとか。

このへんは自分たちで準備しようと思うとわりとリソースを割くようなところをNuxt.jsが提供してくれるので、SSRの文脈でNuxt.jsが語られることが多いと思うんですけれども、このあたりの規約が手に入ることも1つのメリットかなと思っています。

このあたりの規約の話はpotato4dさんが書かれたこちらのスライドがとても参考になるので、もし興味がある方はぜひ読んでみてください。

コンポーネント設計のルールがない

2つ目の課題なんですけれども、コンポーネント設計のルールがないという状況があって。AngularJS1系だとディレクティブというAPIを使ってコンポーネント指向で書くことはできるんですけれども。この粒度が実装者に依存してしまって重複コードが大量にできてしまっているという状況があります。

これに関しては、先ほどの発表に出ていたと思うんですけれどもAtomic Designを採用しています。

とくに上から3つですね。AtomisとMoleculesとOrganisms、この3つをNuxt.jsのデフォルトでできるcomponentsディレクトリの下にそれぞれ配置して管理をするようにしています。

これは実際に3ヶ月、4ヶ月くらい前に既存のページをAtomic Designの粒度に沿って分割した例なんですけれども。

悩ましいのがMoleculesとOrganismsの境目がけっこうあいまいなところがあって。一般的には独立して存在できるかできないかというところで切り分けるんですけれども。それがあいまいなときはstoreを利用する必要があるのはOrganismsと限定していて、そこがあるかないかで判断しています。

粒度が明確になったというメリットはもちろんあるんですけれども、粒度に名称があることでチーム間の会話がスムーズになるというメリットもAtomic Designにはあるなと思っています。

Atomic Designに関する参考資料なんですけれども、五藤さんという方が書かれた『Atomic Design ~堅牢で使いやすいUIを効率良く設計する』という書籍と、Sugawaraさんという方が書かれた『Vue.jsから見たAtomicDesign』という記事がとても参考になるので、もし興味のある方はぜひ見てみてください。

今後取り組みたいこと

今後の検討事項になるんですけれども、現状テストとCIをとくにやっていないので、このへんはぜひやっていきたいなと思っています。

あとTypeScriptですね。現状はES6で書いているんですけれども、NuxtとVuexが対応してないのでそのあたりが辛いという話を見たりもするんですけれども。保守運用、可読性とかを考えると入れたほうがメリットが大きいんじゃないかなと思っているので、このへんは検証していきたいなと思っています。

あとStorybookなんですけれども、導入はしてみたんですけれども今は放置しているような状態になってしまっていて。放置してしまっている理由としてはstory書くのがちょっと辛かったりだとか。

あとはNuxt.jsのコンフィグとStorybookのコンフィグの2重にメンテをしなきゃいけないような状況になっていてちょっと面倒だなというので、今は放置しているような状況になってしまっています。

とはいえコンポーネントのカタログやリファレンスとして欲しいなと思っているので、このあたりは代替手段があるのかないのかとか、そもそもStorybookでちゃんとやっていけるのかとか、そのあたりを検証していきたいなと思っています。

サービスが大きくなればルールが必要になる

まとめです。言わずもがななんですが、中～大規模サービスのチーム開発には相応のルールが必要で、noteも4年経ってサービスが大きくなってきて必要な局面を迎えて絶賛改善中というところです。

規約はほしいけど優先度の兼ね合いでリソースが割けなかったりとか、フロントエンドに詳しい人がチームにいなかったりとか、そういう状況の中ではNuxt.jsはすごく有用だと思っています。

あと、コンポーネントの粒度を統一したいという要望にはAtomic Designが現状だと最適なんじゃないかなと思っていますので、まずルール作りの参考にしていただれば幸いです。

最後に少しだけ告知をさせていただきたいんですけれども。10月23日に渋谷のhoops link tokyoというイベントスペースでnote engineer meetupというエンジニア向けの勉強会をやろうと思っています。

内容はまだ決まってないんですけれども、フロントエンドの話もそうなんですけど、noteのエディターですとかバックエンドとか、こちらも改善中のモバイルアプリですね。Android、iOS、このあたりの話も盛り込んでいけたらなと思ってますので、ぜひ興味のある方は参加のほうよろしくお願いします。

以上になります。ありがとうございました。

（会場拍手）