開発ロードマップ
制約
シングルスレッドサーバーの構築を目指す。
方針
インクリメンタルな開発手法で進める。
つまり、作品開発をそれぞれのタスク区間で分け
各区間が終了するたびに何らかの要件を満たす、動作する状態のシステムが出来上がることを目的にする。
c.f. 低レイヤを知りたい人のためのCコンパイラ作成入門
c.f. Abdulaziz Ghuloum: An Incremental Approach to Compiler Construction
タスク区間の名付け方は、AtCoderっぽくする
これは単純に、自分が今AtCoderにハマっていることによる。
創造的なタスクを単純な実装タスクに落とし込んでいるという意味合いも込めて、そういった命名をとった。
終わったタスクについても、番号づけを行うことにした。
終わった後のタスクについては内容が変更される可能性が少ない。
Gitのコミットメッセージに記述できる内容になりうる。
大量のアクセスを想定しない。
具体的には
シングルスレッドサーバー
最適化はしない。
つまり、データの通信量が無駄になりそうな方法でも、実装が楽になる場合はその方法を採用する。
データのコピーが発生することを恐れない。
clonedを使う場合がある。
後々最適化の際に回収していきたい。
あとで最適化できそうだと思った箇所には#OPTIMIZEのコメントをつけておく。
最適な設計手段を探索しようとしない。
あまりに過度に、今後のことについて考えすぎない
どうせ書き換える
基本貪欲的に開発を進めていく。
冗長で単純なコードが本当に問題になるかを考えるべき
/appbirdNotebook-public/構造化されたプログラムが常に最適であるとは限らない
しかし、次の画面は使い回す。
投稿画面
記録入力画面
記録詳細画面
本質的な部分のコードを使い回したい
タスク区間で分けて管理する。
AC.icon 0 The first step 2024/04/01
AC.icon A Hello, Server 2024/04/02
AC.icon B Hello, Client 2024/04/18
WJ.icon C Dummy Data
WJ.icon D Tagging
WJ.icon E React and UI components
WJ.icon F submission
WJ.icon G Login System
WJ.icon H Detail of Record
WJ.icon I Database
WJ.icon 運用テスト
実際に2名の(TAをしている)ユーザに依頼し、インタビューする。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
以下はExtra
無くてもKSSRsの本質自体は動作している...が
ユーザビリティをもっと高めるために必要
WJ.icon A Auto Completion
WJ.icon B Related Records
WJ.icon C User Menu
WJ.icon D Notifications
WJ.icon E User Settings
WJ.icon F Better Interface