2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
noteのフロントエンド刷新中の開発環境(全1記事)
リンクをコピー
記事をブックマーク
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、このあたりの話も盛り込んでいけたらなと思ってますので、ぜひ興味のある方は参加のほうよろしくお願いします。
以上になります。ありがとうございました。
(会場拍手)
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには