ニコニコ生放送がwebサービスを大人数で開発する際に辿ってきたフロントエンド アーキテクチャ - Qiita
この記事はドワンゴ Advent Calendar 2018 25日目の記事です。 ドワンゴでニコニコ生放送のPC Webフロントエンジニアをやっています、 @kondei です。 いつまでも新人気分だったのに、いつの間にか入社5年目になり、この前ナチュラルに新卒に歴史的経緯を語る立場になっていて勝手にショックを受けました。いにしえの時代（最後期のとはいえ）から現在まで実際に開発して知っているフロントエンド開発者が数人になってしまって貴重なので、いい機会なのでまとめようと思います。 内容的には ニコニコ生放送の watch ページを MobX で作り直している話と重なる部分もあります。 はじめに まず、大人数のフロントエンド開発でアーキテクチャをどうするべきかの一つの解を得たので、それを述べます。 そして、どうしてそうなったのか、つまりニコニコ生放送が過去にどういう問題を抱えてきて、どうい
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
