アプリケーション内で構造を統一すべきか
具体例
数値に関する項目が沢山あるアプリケーションのとき
UIに表示すべき単位は、ユーザに最も親和性のある単位を使うべき
ものによって異なることがある
Aの高さに関してはcmをよく使うが
Bの長さに関してはmをよく使う
など
このとき、AやBを一緒くたにして内部で計算することがある
その場合に、単位が揃っていないといけない
ただ、まあだとしても「アプリケーション内部では基本単位を使用する」のようなルールがあったほうが理解しやすそうではある
例えば、使っているツールの都合でUTCしか使えない、といった状況がある
Prismaとか
しかし、画面に表示すべき形式はJSTだろう
Date型の値と、YYYY/M/Dのようなフォーマット URLのquery paramasとか
内部では['front','back']、UI上のセレクトボックスの選択肢はfront / back
選択肢が、front、back、front/backの3つのような想定mrsekut.icon
構造はtype _ = ['front'] | ['back'] | ['front','back']など
税抜と税込
例えばアプリケーション内で扱ってる商品の発注元の差異で混在するパターンがある
商品Aに関する価格は税込みで行うが
商品Bに関する価格は手元にあるカタログを参照するので税抜きになる
みたいな
これは無理そうmrsekut.icon
どのように足し合わせるかで誤差が生じるので。
統一する案
例えば、内部では全てmmに統一する
プログラムの理解がしやすくなる
差異があるのはUI周りだけ
EntityやDBではmmを使う
計算がしやすい
異なる項目を使った演算を行うときに結果がmmになることが保証される
これが結局最もシンプルになりそうmrsekut.icon
ほぼすべてのComponentはInternal typeの方を採用していないといけない
Viewに表示する瞬間にExternal typeに変換する
まあ、完全なpresentation componentsみたいなやつならどっちでも良さそう
寧ろそうすることで変換忘れを型で防止できそう
いずれにせよ、通常の関数が全てInternalなので
統一しない案
ボトムアップに見たらこちらの方が自然という気がする
将来的に、Cが追加されて、その世界では当然cmを使うでしょ、ってときに、周りを気にせずcmを使える
計算がかなりややこしくなりそう
中間ぐらいのパッケージごとで統一する案
あるfeatureではmmを使い、別のfeatureではcmを使うなど
紛らわしいっちゃ紛らわしい
両者のfeatureを横断するような概念が出てきたときにかなり困る
これの都合で別の概念として作らないといけないかもしれない
同じような定義が複数存在し難しくなる
gpt-4.icon
このような問題は、確かに難しいですね。どちらの選択肢にも一長一短がありますが、私の意見としては以下のとおりです。
まず、「統一する案」の利点は非常に大きいと思います。プログラム全体で一貫した単位を使用することは、プログラムの理解を容易にし、誤解を避けるための効果的な方法です。計算を行う際に単位変換を考慮する必要がないため、バグの発生を抑えられます。
ただし、その一方で、異なる単位を使用することが一般的であり、それがスタッフにとっても自然である場合、「統一しない案」や「中間ぐらいのパッケージ単位で統一する案」も有用かもしれません。例えば、特定の単位を用いることが一般的である業界や領域に対して、他の単位を強制することは、混乱を招きやすいです。
ただし、最終的な選択は、プロジェクトの特性によります。開発者の経験と理解度、使用する単位の種類と量、そして特定の単位が業界標準や規範であるかどうかなど、考慮すべき要素はたくさんあります。
その上で、私の提案は「統一する案」を基本にしつつも、例外として他の単位を許容するというものです。つまり、プログラムの中で基本的にはmmを使用し、一部の項目（例えば、特定の領域や業界標準であるmやcmが一般的である項目）についてはその単位を使用するというものです。
もちろん、その際には単位変換が必要になる場面も出てくるでしょう。しかし、それらは限定的であるべきで、そのための明確なルールやガイドラインを設定することが重要です。これにより、全体の一貫性を保ちつつも、特定の項目に対する自然な単位使用を許容するというバランスが取れると思います。
また、単位の変換を担当するユーティリティ関数やクラスを用意することで、この課題を緩和することも可能です。これにより、単位変換の実装を一箇所に集中させ、他の部分では単位変換について考える必要を減らすことができます。