ソフトウェアの技術選定

ソフトウェアの技術選定についてぼんやり考えたので書いておく、

さまざまな場面で技術選定を迫られることがここ1年ほどで多い。チャレンジできる環境なので本当にありがたいなと思うものの、毎回同じことを考えてる気がするのでここらで整理してみる

技術選定をするためには色々なことを考慮する必要があって、大きく3つに分けれる気がする

マイルストーンがどこに置かれているか
- どんな技術を選択したとしてもマイルストーンを満たす必要がある
アジャイル開発かウォーターフォール開発か
- アーキテクチャ・FWが技術で分割されたものか、ドメインで分割されたものか
  - ソースコード間の距離に大きく関係する
- ウォーターフォール開発では技術ごとに実装することが多いので、技術で分割されたアーキテクチャ・FWが有利
- 逆に開発ではユーザーストーリー（≒ドメイン）ごとに実装することが多いので、ドメインで分割されたアーキテクチャ・FWが有利
新規参入者が多いか少ないか
- 新規参入者が多いということはソースコードをreadする機会がwriteに比べて多い
- readを重視するのであればeasy to readである必要がある
QCDのバランスがどうなっているか
- CやDを重視するのであれば、多少のカスタマイズ性を犠牲にしてでもよりプリセットなフルスタックFWを利用しスピードを上げコストを下げる
- Qを重視するのであれば、カスタマイズ性を最重要視するべき。カスタマイズ性がないものを無理にカスタマイズすると、大幅に実装コストや将来的な管理コストがかかるので

高度なパフォーマンスが求められるか
- レイテンシは言語のモデルと深く関係する
  - CPUバウンドな処理が存在する場合はRustやGoなど低レイヤに記述できる言語が推奨される
  - そうでない言語でも金銭的コストや時間的コストを投入すればCPUバウンドな処理を解消できなくはない
  - 普通のHTTPでやりとりするAPIサーバー作るのであれば何でも良いと思っている
- スループットが重要であれば、言語・FWが非同期I/Oを利用できるかどうかによってスループットが大きく変わる
長期間保守をすることが想定されるか、使い捨てか
- 使い捨てであれば、ソースコードをread/writeする機会のうち、writeする機会が相対的に多い
- そうでなければ、ソースコードをreadする機会が相対的に多い
- readを重視するのであればeasy to readである必要がある
仕様が一般的な仕様・ベストプラクティスに沿うか
- 沿うのであればプリセットなフルスタックFWを利用できる
- そわないのであればプリセットなフルスタックFWを利用しにくい
  - カスタマイズ性がないものを無理にカスタマイズすると、大幅に実装コストや将来的な管理コストがかかるので

それぞれが現在何のスキルを持っていて、選択した技術を習熟するまでどのぐらいのスピードが必要か
- 習熟するまでの時間をマイルストーンと比較して効果があるか
  - 例えば特定のFW初心者が人並みに実装するようになるまで6ヶ月かかるが4ヶ月後にリリースを控えているという状況では、そのメンバーの真価が出ない
メンバーが流動的か
- 流動的であれば、参入直後のメンバーが状況把握しやすい技術を採用するべき
  - 状況把握しやすい→easy to read
- これは技術だけでなくドキュメント・オンボーディングの濃さにも関係するイメージ
色々な役割を跨いで作業することがあるか
- フロントエンドのメンバーがバックエンドを触ることがあるか、逆も然り
- 同様に、状況把握しやすい技術を採用するべき
  - 状況把握しやすい→easy to read

SimpleとEasyの話はまだ咀嚼できてない

色々他にもありそうやけど眠いので寝る

tech