Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

This article is a Private article. Only a writer and users who know the URL can access it.
Please change open range to public in publish setting if you want to share this article with other users.

【長期インターン】料金計算APIの実装

Posted at

はじめに

2024 年 6 月から大阪のベンチャー企業で週 1〜2 回ペースの長期インターンに参加しています。2024年11月から3月にかけて、デマンド交通システムの料金計算APIの開発を担当しました。
既存システムではフロントエンドの JavaScript で料金を計算していましたが、サーバー側で処理をできるようにし、他のシステムからも利用できるようにするため、料金計算 API の PHP 版を実装しました。

デマンド交通システム

image.png

株式メタ・イズム公式HPより引用

料金計算 API について

機能概要

緯度・経度を受け取り、走行距離と利用者属性に応じて料金を返す REST API です。呼び出し元は以下の 2 つ。

  1. Web 予約画面 ― ユーザー向け
  2. 管理者画面 ― 管理画面向け

自治体ごとに適応される割引条件が異なり、障害の有無とその種別、未就学児、幼児など条件を満たす利用者には割引が適応される。
今回の案件では以下の割引条件を考慮する必要があった。

  • 幼児(3歳児未満)は無料
  • 未就学児(3歳以上5歳以下)は300引き
  • 利用者本人が障害を持つ場合、300引き
  • 利用者本人が重度障害区分の場合、同乗者1名のみ300引き

なお、もし「未就学児」で「障害を持つ」利用者が配車予約した場合には、600円引きとならないよう、最大300円引きまで適応されるようにした。(割引組み合わせ管理)

api_get_feeクラス

主なメソッド

機能 説明 メソッド
1 エリア判定 緯度経度からエリア ID を取得 get_area_by_id()
2 基本料金算出 料金マスタを参照し、エリア ID から基本料金を取得。 get_default_fee()
3 予約者割引判定 ユーザーIDから、障害者・未就学児・高齢者などの割引適用可否を取得 check_discount_adaptive()
4 料金計算 基本料金に割引を適用し金額を算出 calc_fee()
5 同乗者料金計算 同乗者がいる場合は、同乗者の属性を確認し料金を算出 calc_fellows_fee()

主な参照先DB

テーブル 用途 主なカラム
customers 顧客属性 id, age, disable
fee 基本料金 area_id, from_lon, from_lat, to_lon, to_lat,default_fee
discount 割引管理 discount_id
discount_combo 割引組み合わせ管理 discount_combo_id

使用した技術

  • 言語: PHP
  • フレームワーク: Laravel(たぶん)
  • DB: PostgreSQL
  • バージョン管理: Git

できるようになったこと

  • オブジェクト指向でコードを書けるようになった。
    • これまで用語としては知っていたけど、実際に意識して書いたことはなかった。
    • 実務ではほぼ全てオブジェクト指向で書かれており、理解していないと結構苦労するなと思った。
  • GitHubの使い方を学んだ。
    • これが意外と大きな成長。
    • 最新の状態を取得し自分の変更をpushするまでの一連の流れを抑えた
    • 実務ではrelease, develop, featureブランチと3つに分けていることを知った。
  • Chromeの検証機能(DevTools) の使い方を学んだ。
    • 「ネットワーク」を見て、リクエストがどこに送られているか、レスポンスはどうなっているか確認できることを知った。
    • console.logしたログの確認の仕方を学んだ
  • 社員の方にコードレビューをしてもらって、誰が見てもわかるコードの重要性を知った
    • 個人開発では「動けばいい」と思いがちだけど、実務では保守性や可読性、バグに繋がらないかどうかが重視される。
    • 特に変数名のわかりづらさ、不要な分岐処理、渡ってきたデータのバリデーションチェックなどが指摘された。
    • プロのエンジニアの方にレビューしていただけるのは非常に貴重な経験。

苦労したこと

課題 苦労したこと
オペレーター画面と Web 予約画面でレスポンス形式が異なる 片方は配列、もう片方は文字列を必要とし、キー名もバラバラだった。
どちらの画面でも使えるように、必要な形式をすべて含んだレスポンスを API 側で構成して返すようにした。
オペレーター画面からAPI叩いても料金計算が動かない APIリクエスト先を切り替えるswich文でbreakを書き忘れていたため、APIがレスポンスを返せていなかった。
気づくまでに時間がかかった。
履歴から特定の地名を選ぶと、別の地名が表示される 住所は同じでも地名が異なる候補が存在したため、JavaScript 側の一致判定を修正する必要があった。
緯度経度が一致するかどうかで判定し、正しく一致する地名だけを選ぶようにコードを修正した。
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?