この記事は？
はじめまして、株式会社アイスタイル・エンジニアのmuratakです。今年はJSConfにアイスタイルがスポンサーとして初参加をし、弊社からも複数名スタッフとして協力させていただいたので、当日を振り返って参加レポートを公開し、JSConfではどのような発表が行われ、どのような雰囲気でイベントが進行されていたか？を皆さんとシェアできればと思います。
本記事では共同執筆者として弊社エンジニアの岡下も執筆に参加し、
2名での共同執筆をさせていただいております。
当日行われたLTについて
(執筆: muratak, okashitay
私たちがスタッフ業務をこなしながら、隙を見て参加させていただいたLTを見た感想と、どう業務に活かせそうか？について続けて書いていきたいと思います。
株式会社アイスタイルでは、フロントエンド、サーバーサイドの両面においてJavaScript, TypeScriptを積極採用しており、全体の(リ)アーキテクチャ及びプレレンダリングといった話題を学ぶことでプロダクト開発改善に大いに活かせそうだと考えました。
・LT: A Tour of Anti-patterns for Functional Programming
このLTでは、関数型プログラミングをする際のアンチパターンについて紹介がなされていました。執筆者はサーバーサイドのTypeScriptを専門としており、TypeScriptは関数型プログラミングとも相性が良いため、期待を持って見に行きましたが、
とても学びがある内容でした。
テーマ1) Should we use Either or Result types instead of Exceptions?
堅牢なアプリケーションを作っていくために、また耐障害性を高める必要があるため、この問いはとても大事なものだと思いました。
この問いに対して、提案された結論は以下のようにスコープによって分けるというものです。
Method-wide -> Either
Layer-wide -> Exceptions
Application-Wide -> process.exit(1)
私もとても納得しており、例えば四則演算のエラーなど、Method-wideで簡易的なエラーはEither型で捕捉しておいてロガーやUIを使って出すようなことができれば、堅牢でユーザーフレンドリーなアプリになると思います。一方で、メモリ不足などクリティカルなApplication-Wideなエラーはprocess.exit(1)でアプリ自体を止めておくべきです。その中間となるLayer-wideなビジネスロジックで生じたエラーはExceptionsとして扱い、上位にエラー情報として伝播することで適切な耐障害性を持ったハンドリングができると感じました。
テーマ2) Should the Railway Structure be the fundation?
この問いの答えとして、無理してRailway構造に遵守した実装をする必要はないということです。示された2つの比較はとても明快で、TypeScriptにおいてはasync awaitの構文を用いることができるので、それを用いてbindを書けばクリアーな書き心地に見えました。
・LT: ステップバイステップで進めるYahoo!知恵袋のフロントエンドリアーキテクト
このセッションでは、
Yahoo! 知恵袋のリアーキテクトをどのように行っていったのか？が語られていました。
私は長年の負債が溜まった@cosmeのトップ画面をPHP -> TypeScriptにリプレースし、負債を一括返済した経験があり、とても興味を持って拝聴しました。
モノリスでのcontrollerの肥大化が問題となっていたところ、
controller (本来はルーティングなど)をそれぞれ
applicationService、model、 utilityと分ける方法をとっていたようです。
重要だと述べられていたのがリファレンス(サンプル)実装で、
確かに著者の実感としても、こういったリアーキテクチャでは参照するコードがあって目指す方向があったほうがみんな実装しやすいのでとても良い方法だと感じました。
また、旧部分がJavaScriptで書かれているので単純なミスに実行時になるまで気が付きにくい問題についても述べられていました。それを防ぐためにTypeScript導入が検討され、TypeScript化していく順序として、新しく作る際は最初から、処理を切り出す際は更新頻度の高いところを率先してTS化するというのはとても理にかなった方法だと感じました。
TypeScript化のステップもフローとして示されており、メンバー全員がそれに従ってとても作業しやすかったのではないかなと僭越ながら感じました。
テストがメンテナンスされていなく、テストコードが肥大化していたことも述べられ、私はユニットテスト文化の記事を書いたことがありますが、テスト文化が定着しにくいことの原因はテストを書いたりメンテナンスが難しい構造が原因である、と考えていました。
(※ここは本記事の趣旨とは内容が逸れるので、
興味のある方は著者の記事を参照ください。)
チームにテストコードを書く文化を定着させる
テスト面の改善で提案されていた内容は以下の通りでした:
・テスト対象のコードを小さくする
・パラメタイズドテスト
・mockの初期化を行う関数の作成
・基本はinputに応じたoutputの確認
・副作用が発生する関数以外は基本的にmockしない
特にプレゼン内で強調されていたのはパラメタイズドテストで、網羅的に色々なテストパターンを与えてテストができるのでとても効率の良い方法だと感じました。
私もおそらく同じような規模の技術負債の解消を行った経験があるため、とても大変で
骨が折れる作業ではなかっただろうか？とプレゼンを聞きながらひしひし感じていました。
・LT: React への依存を最小にするフロントエンドの設計
依存を最小にする理由として、エコシステムの変化に追随する負担を減らしたいということが挙げられていました。確かに、エコシステムが変化して新しい技術が登場したときに、古い技術に依存していると移行の負担が大変になるため、とても共感できる考え方でした。
一休レストランで依存を最小にするための設計実践として、
以下のような実践例が挙げられていました。
・hooksにできるだけロジックを書かない
フックは状態管理に専念してビジネスロジックは他に分散させることで、
関心を分離できそうです。
・コンポーネントは薄く小さく
こちらも同様に関心の分離を行うことができる大事な観点だと感じました。
・依存性逆転の原則とDI
一休レストランのReactでの開発においては、Jotaiで関数を管理することで簡易的なDIコンテナとして利用していることが紹介されていました。
・腐敗防止層の導入
外部システムや変わっていく連携システムとの互換性を保つためにも、腐敗防止層は、「システムの境界」を明確にし、外部から受けるそういった複雑さから内部システムを守る防御壁として機能する設計パターンとして機能していることが窺い知れました。
・LT: LINEヤフーにおけるPrerender技術の導入とその効果
@cosmeもプレレンダリングを行っていて、SEOが非常に大事な部分になるため、期待を持って聞いていましたがとても学びがある会でした。
このセッションでは、
パフォーマンス最適化の重要な考え方の一つである先読みについて語られました。
本LTではレンダリング特性に特化した先読みがテーマになっていて、Web標準一般における先読みの手法としてpreload, prefetch, private prefetch proxyなどが紹介されていますが、
効果測定を行ったPrerender技術として、
宣言的なルールを記述し、条件に合致したリンク先に対して、prerender/prefetchの挙動を細かく制御することができるSpeculation Rules APIでの計測が発表されていました。
その結果、ページの読み込み中央値が改善したが、ビジネス指標に関しては期待するほど向上しなかったことが述べられています。技術面の向上だけで必ずしもビジネス指標に直接寄与するわけではない厳しいエンジニアリングの側面が窺い知れたように思います。
・LT: Modular Monolith Monorepo -シンプルさを保ちながらmonorepoのメリットを最大化する-
モノレポのメリット・デメリットについての話から始まり、モノレポ内のパッケージのバージョンを統一することで、メンテナンス性やセキュリティ面が強化される点について学びました。さらに、導入に際しての課題やルール作り、意思決定のプロセスについても具体的な事例を交えた話がありました。
私自身Design Docsにはあまり詳しくありませんでしたが、社内で行われた議論をもとに、意思決定のプロセスをDesign Docsにまとめる流れや、将来的な技術的負債に対応するための考え方を知ることができ、とても参考になりました。
運営スタッフとして参加してみて (執筆: okashtitay
今回はじめて、JSConfにて運営スタッフに参加させていただきました。
はじめての運営スタッフで戸惑うことも多々ありましたが、カンファレンス運営に慣れている方々に助けられながら、無事に務めることができました。
活動内容としては、JSConf前夜スポンサーブースの荷物搬入から始まり、JSConf当日の受付業務(開場から11:00頃までは戦場と化していた…)
カンファレンスルームの案内、昼食後のゴミ分別、スタバに買い出ししてコーヒートラベラー設置、さらにはスポンサーの方や来場者の方々からの問い合わせ対応、懇親会後の片付け etc…と多岐に渡りスタッフ業務に勤しんでいました。
カンファレンスが終了した時には大変ながらも達成感があり楽しく充実したイベントでした。まるで文化祭の準備をしていたような…
自分たちが携わっているサービス・業務は自分たちではない誰かが作成してくれたプログラミング言語やオープンソースが土台になっていますし、また誰かの知見・アウトプットなしでは成り立たないものだと実感しています。
今回、スタッフとして参加させていただくことにより何らかの形でコミュニティに還元できたことを嬉しく思います。
また、コミュニティが活性化し利用する技術が発展することで、より良い開発体験からユーザーサービス体験まで提供できるよう、今後も何らかの形でコミュニティへの貢献を続けていきたいと思います。
