ランキング設計はどうあるべきか？ その3｜深津 貴之 (fladdict)

ここまでランキングのあるべき方向性と、実行可能なアプローチについて考察してきた。そして、いよいよプロトタイピングと実験の時間だ。残念ながら自分はサーバーサイドのコードが書けないので、ここからは開発チームに託すことになる。 妄想や実証不能なものをオーダーするのは非効率だと思う。ある程度はクラスをモデリングしておくと、エンジニアとディスカッションしやすい（ように思える）。 とりあえずnoteでのランキングは、様々な試行錯誤や実験が予想される。そのため、以下のような要素が必須となる。 ・工数最小 ・あらゆるランキングを表現できる ・拡張しやすい 今回はDecoratorパターンとCommandパターンを混ぜたような実装で、柔軟性のあるランキング計算システムのコンセプトを描いてみた。下手なコードでも、設計がある方がエンジニアさんに説明しやすい。 設計イメージとしては、まずランキングの各処理を同じイ

[pmint]

それよりもSQLだと思う。情報に目を向けるべき。/ このクラス設計はランキング入りの条件に一切関わっていない。シャッフルとブレンドは頭の中でやればいい。

[ogawa0071]

これは年収高いですわ。。

[r_kurain]

コンテンツランキングをランキング学習でやったらどうなるのかは気になるなあ。素性しだいだけどキャッチーなタイトルが上にくるのかな。

[securecat]

CXOの手順的に、この段階でこういう断片コードでのI/F設計って必要なんだろうか？

[iguchi1124]

コンセプト図なるほど

[sezemi]

雑設計ではない

[snowlong]

コードの設計まで！

[sawasawa12]

ランキング設計はどうあるべきか？ってここまでやるということを指しているのかな。

[kazoo_oo]

考え続ける力凄いな。

[koogawa]

クラスモデリングまでやられるとは…！（ここは開発者に任せて欲しい感はある）

[hdance]

おー、デザイナが概設計までやるのか。すごいな。というかプロダクトマネージャの仕事やってますね。