Open7
技術選定
やま「手慣れている」という技術選定理由
動画の12:07~
手慣れたツールを利用することのメリットには、初期のスクラップ&ビルドによるプロトタイピングの高速化、また各種技術がすでにパッケージングされておりいちいち迷うことがない、という点がある。
Ruby on Railsならテストフレームワークどうしよう？マイグレーションどうしよう？あるいはDIどうしよう？といった点でいちいち迷わずに済む。一方手慣れていない言語や比較的新しい言語は、いちいちツールの選定で迷う。そうしたコストをかけないということは、ビジネスロジックに集中してスピードや質を追い求めるうえで重要だ。
やま技術選定はインフラから
技術選定はインフラから始まって、言語についても言語というよりフレームワークで何ができるか、から選ぶ。
やま技術選定の「下ごしらえ」
「下ごしらえ」として様々な点を検証する。
特別変わったことが書かれているわけではないが、基本的な技術選定の手順や検討項目が網羅されており、チートシート的な使い方もできそうな良記事。
やまライブラリ選定に役立つツール
スター数とかダウンロード数を調べることができるツールたち
やまSQL, NoSQLの技術選定の観点
やまWantedlyの技術選定の考え方
Goを選ぶ理由ってなんだろう？と思って調べてみたが、むしろGoではなくRubyを選ぶ理由の部分が興味深かった。
ChatGPTと議論して詳細な深堀り:
- 試行錯誤のスピード向上: フィールドをいじってもコンパイル可能。ゆえに、とりあえずすぐに変更箇所のテストだけやりたい、というケースでのスピードがあがる
- 未完成部分を残したまま、なんならデプロイまでできる: 上記は個人的な作業・チケットスコープでの試行錯誤しやすさに限らず、チーム全体でスキーマ駆動開発likeなことがやりやすい。openapiとかprotobufを導入していない現場で、なおスキーマ駆動っぽいことをやるにはちょうどいいかも
- 並行開発しやすい: 動的型付けではたとえば一個のフィールド名変えるだけであらゆるファイルに変更がおよび、これはコンフリクトのリスクを飛躍的にあげてしまう。しかし、動的型付けなら、とりあえず一箇所本元の部分だけなおせば良く、一個の変更の影響を一時的に小さくとどめられるので、コンフリ防ぎやすい
- メタプログラミングみたいな魔法・おまじない的実装がしやすい。あと、動的型というよりフルスタックFWの利点だが、とりあえずベストプラクティスに従うってやり方ができる。
やまGoのつらみ