課題 (ServerSide Challenge2) 電気料金のシミュレーションアプリ

[tontoko]

概要

ServerSide Challenge2 の課題です。
電気料金のシミュレーションアプリを作成しました。

RailsのAPIとAstroのフロントエンドで構成されています。

1.-.-.Microsoft.Edge.Beta.2025-02-10.00-43-57.mp4

機能

• 契約アンペア数(A)と1ヶ月の使用量(kWh)を入力すると、登録された電力プランごとの金額を確認できる
  • 要件 https://github.com/tontoko/coding-challenge/blob/5b53ec5e0987445ca292efa7806533d0951c0253/serverside_challenge_2/README.md#L104-L118
• csvファイルをアップロードすることでプラン情報を一括で作成・更新できる

テーブル構成

erDiagram
    ELECTRICITY_PROVIDERS {
      bigint id
      string name
      datetime created_at
      datetime updated_at
    }
    ELECTRICITY_PLANS {
      bigint id
      string name
      bigint electricity_provider_id
      datetime created_at
      datetime updated_at
    }
    ELECTRICITY_PLAN_BASIC_FEES {
      bigint id
      integer ampere
      decimal fee
      bigint electricity_plan_id
      datetime created_at
      datetime updated_at
    }
    ELECTRICITY_PLAN_USAGE_FEES {
      bigint id
      integer min_usage
      decimal fee
      bigint electricity_plan_id
      datetime created_at
      datetime updated_at
    }

    ELECTRICITY_PROVIDERS ||--o{ ELECTRICITY_PLANS : "has"
    ELECTRICITY_PLANS ||--o{ ELECTRICITY_PLAN_BASIC_FEES : "has"
    ELECTRICITY_PLANS ||--o{ ELECTRICITY_PLAN_USAGE_FEES : "has"

Loading

実装上気を付けたポイント

• テーブルの命名
  • ガス会社などを追加した場合に分かりやすい・名前被りが発生しないよう、明示的に電力会社であるという名前にしています。
• 従量料金のテーブル設計
  • READMEの従量料金の範囲(0-120kWh, 121-300Kwhなど)をそのままそれぞれカラムに当てはめるとレンジ被りのデータ不整合が起きうる設計になってしまうので、各区間の下限のみをカラムに持つようにしました。これであれば各プランの最も高い区間の範囲(東電なら 301-∞kWh)も表現できます。
• csvデータのインポートには、複数モデルの更新をまとめたフォームオブジェクトを使用しました。

やっていないこと

• tailwindなどで見た目を整えた方が良いですが、バックエンド課題なこともあり今回は行いませんでした。

[RyuyaIshibashi]

Suggested change

	next unless usage_kwh > current_fee.min_usage
	next if usage_kwh <= current_fee.min_usage

の方が可読性に優れているように見えますが、unlessを使用した理由はありますか？

[tontoko]

たしかにifの方が可読性が高いですね、この場合ifにすべきだと思いました。
この形で書いておいてなんですが、個人的にはunlessはrubocopで禁止しても良いかなと思っています。
(条件がbooleanの入った変数1つのみであればアリかなとも思います)

[RyuyaIshibashi]

frontendの実装的にはintegerが来ることが自明ですが、backendのバリデーションとしてこのタイミングでintegerに変換することは適当でしょうか？

[tontoko]

to_iだと不正な文字列の場合に0に直されてしまうので、Integerで変換した上で例外処理で400を返してあげるべきでした。
入力値バリデーションが長くなっているので、Serviceクラスにバリデーションを移動するか、こちらもFormオブジェクトにしてバリデーションしてもよいかと思いました。

[RyuyaIshibashi]

TEP従量電灯で、121kWhでリクエストすると使用量は19.88 * 121と計算されそうですが、これは正しい実装でしょうか？

[tontoko]

whereの条件が間違っていますね、終点を含む(..usage_kwh)形が正しかったです。。