Zenn
Open8

Sustainable Web Development with Ruby on Railsを簡単に要約してみる<Introduction>

Rails
Web
book
メモ
要約
HironHiron

sustainablityとは？

ソフトウェアを維持していくこと　＝　(ユーザーの)ニーズを満たし続けること

変更しにくいアプリは維持していくのが難しい。

HironHiron

なぜ持続可能性が大事なのか

ユーザーのニーズというのは曖昧で主観的なものであるので、すぐに理解することは難しい。

ゆっくりと時間をかけてユーザーのニーズを定義付けていかなければならない。

そのため、ソフトウェアもそれに合わせて時間をかけて継続的な改良をしていく必要がある。

HironHiron

ソフトウェアを持続的に開発していくために必要なこと

筆者は、持続可能性を追求することを「投資」に例える。
つまりは短期的に報われることはないし適切な方法で行われなければ決して報われることがない。

ソフトウェアにどのような機能を持たせるべきかという情報だけでは足りない。
いろんな情報が技術的な問題の決断に影響を与える。

ex)
持続可能な開発環境を構築するために数日を費やしたい。
↓
会社の成長予測やチームの採用計画を指摘することで、その作業を簡単に正当化できる

事業の成長戦略、長期的なビジョンを知ることが大事。そこからどのくらいの規模感のエンジニアチームが必要かとか、対処しなければいけない課題を推測できる

HironHiron

筆者の考えのベースとなっていること

チームは変わる

  • メンバーの在職期間が短い
  • メンバーの経験レベルやスキルセットも年月が過ぎるごとに変わる

持続可能性、一貫性、質を大切にする

  • 一貫性は、デザイン、システム、プロセスなどがある一定のルールに基づいているべきであるということ恣意的に異なるものであってはならない
  • チームメンバーの個人的な好みではなくて、なにか論理的なルールに基づいて意思決定がなされる必要がある。
  • 一貫性を大事にするチームは持続可能なチームで持続可能なプロダクトを作れる
  • 品質の追求は毎日行っていくべき
    • 技術的負債をあとで返済するのはとても難しいから

その他

  • ソフトウェアは明確な目的を持っている
  • ソフトウェアは何年も存続していく必要がある
  • ソフトウェアは進化する
HironHiron

oppotunity costとcarrying cost

エンジニアにとって最も役立つ2つの概念

  • oppotunity cost
    • 何かを作るための一回限りのコスト
    • 結構な負担があるのだが、たまにそれに投資する価値がある
  • carrying cost
    • ずっと払い続ける必要のあるコスト
    • carrying costが何よりも持続可能性に影響を与える
      • コードの1行1行がcarrying cost
HironHiron

MVB??

RailsはMVCフレームワークと言われるが、筆者曰く、MVCの概念はRailsには正確にはマッチしないらしい。（MVCの歴史を掘り下げていくとRailsとの関係性を見出しづらいっぽい）

筆者はRailsの構成要素を4つのカテゴリーに分けて考えている。

boundaries

  • 入力を受け取って内容を理解する
  • ビジネスロジックをトリガーする
  • ビジネスロジックの出力を調べて、それを提供する

ex) コントローラ、メイラー、rake task、active storageなど

views

  • 情報を表示する

models

  • 大体の場合データベースとやりとりするために使われる(active record)
  • データベースとやりとりしないモデルもある（active model）
    • active recordもactive model、両者ともに属性を直接的に操作できるデータ構造体
  • 一般的にビジネスロジック置き場として使われている
  • データベースのスキーマを作り出すデータベースマイグレーションも含む

Everything else

その他すべて

ex) Gemfile, seed data, tests 　など

HironHiron

Railsの良いところ、悪いところ

良いところ

  • コードの構造に関して事前にいろいろ考える必要がない
  • railsのアーキテクチャに沿って簡単に持続可能なアプリが作れる
    • 常にrailsをどう使うかに集中して、Railsがガイドを出していないところに関してはギャップを埋めていく必要がある

悪いところ

  • データベースを使うアプリ用に作られたフレームワークのため、データベースを使わないアプリには向かない
  • ビジネスロジックをどこに置けば良いかというガイドがない
HironHiron

User Focus

実現したいユーザー体験がわかれば、我々エンジニアが書くコードもその体験を実現することにフォーカスを当てたものになる