日本語とScalaでプロダクトを作る

LoLの世界大会から目が離せない高嶋(@takashima0411)です。
SKTvsRNGはあまりに熱い展開でした。
話は変わりますが、この度短命で規模の小さいプロダクトを作成する機会に恵まれたので、
普段は英語でコードを書いているところを日本語でコードを書いてみました。
とは言えすべてを日本語にしたわけではなく、DDDを意識し、ドメインモデルに相当しそうなとこだけ日本語にしました。
以下その感想をまとめてみました。
(注意: 筆者の英語力は英語ドキュメントなら辞書を引きながらなんとなく読める程度です)

環境

今回の開発環境は以下のような感じです。

開発用マシン: MacOSX
IDE: IntelliJ 2017.3
言語: Scala 2.12
ビルドOS: AmazonLinux (latest docker image)

ハマリポイント

弊社では現在CIにgitlabを導入試験中です。
gitlabからビルドさせるためにDockerを利用するのですが、ここでは少し注意が必要です。
AmazonLinuxのDockerイメージのlocaleに「ja_JP.utf8」が含まれていません。
なので入れてやらないとビルドが出来ないのでご注意ください。
今回はサボってyum updateで対応しました。
ちなみにエラーメッセージは以下のように日本語になっている部分が「????」となって表示されます。

/builds/Hoge/project/routes: 5: Compilation error[')' expected but '?' found]
GET      /fuga/     controller.Controller.index(????, ??????)

良かった点

変数名で迷わない

例えばSeqでfilterした後、英語が堪能ではない僕は説明的な変数名を付けるのが下手なので甘えてfilteredとしたり、
そもそも変数にしなくても良いようにひねったり、できるだけ短い変数名にしてお茶を濁すことがあります。
言うまでもないですが、これはあまり褒められたものではありませんよね？
filteredという名前は後から見返したときに「filter」してんのは見りゃわかるんだよ！！！！ってなりますよね。
そうではなく、filterした後のSeqが何を表しているかなどがすっきりかけて快適でした。

POと同じ言葉を使える

今回はスピード優先であることもあり厳密にはPOと言葉の統一をできなかったのでここは感想です。
DDDではPOや顧客を始め業務に関わる人々がが話す言葉に耳を傾け、同じ言葉を用い、彼らと開発者の間で無駄な翻訳が発生しないようにすることが大事だとされています。
しかし、英語でプログラムを書いてしまった場合、POが日本人である限り絶対に日本語から英語への翻訳が発生してしまいます。
僕のように英語が堪能でない人が間に入った場合はそれはもう最悪で非常に小さいボキャブラリーからそれっぽい単語を選んでいくことになります。
本来必要であった意味が抜け落ち、POが見てももはや意味不明な物体が出来上がります。
さらにはPOに英語でいうとこれなんですかね？とかいい始めPOの仕事まで増えて本当に酷い感じですよね？
しかし、ドメイン周りだけでも日本語に統一すればそういった心配は一切なくなります。普段はPOと一緒に言葉を決定していって、コード上の表現用の英語の対応表を用意したりしていますが、
後者のコストをなくすことが出来たらうれしいですね。