例えば、最近僕が体験した事例を挙げると、
Dataflow の例
Google Cloud Dataflow のパイプラインを実装していた。Dataflow その名の通りデータ処理を行う基盤で、例えば、データベースから取ってきたデータを CSV に変換して Google Cloud Storage や AWS S3 にアップロードする、といったコードが書ける。
Dataflow は各処理のステップに名前をつけることができる。例えば、データベースからユーザーのデータを取ってくる処理に「Fetch User Data From Database」とつけたり、CSV に変換する処理を「Transform User Entity to CSV」とつけたりできる。
一般的には、「Fetch User Data From Database」を「Fetch Database」や「Fetch User」と省略するとわかりづらくなるので、通常は「Fetch User Data From Database」のように、必要な情報が全部得られかつ簡潔な名前がいい。
ただし、Google Cloud Dataflow の UI では、ステップ名が15文字程度しか表示されず、溢れた分は表示されない。この場合は「Fetch User」のように、多少情報が欠落していても、UI上でちゃんと表示される名前が良い。
interface の例
例えば、DDD (ドメイン駆動設計) を取り入れて「依存性の逆転」を導入したとする。データベースのアクセス部分について interface を使って、Domainレイヤーが Infrastructure レイヤーに（コードの見た目上は）依存しないようにする方法だ。
一般的にはいい設計であると言われるが、IDE でコードジャンプする際に一回 interface を挟むことになるため、効率が悪くなってしまう。
それでも interface を使った方がいい場合もある。その方がテストのモックを注入しやすくなったり。ただ、私はあまり interface 好まない。素直にコードジャンプできる方が嬉しい。
私の経験上 interface を効果的に使える人間は少ないので、interface を導入するメリットよりも、IDE で一発でコードジャンプできるメリットの方が圧倒的に大きいと思う。
さいごに
このように「良いコード」は Google Cloud や IDE の仕様など、周りの環境に大きく左右されるし、Google Cloud や IDE の仕様が変われば「良いコード」も変わる可能性がある。
