こんにちは、M&A クラウドのかずへいです。

M&A クラウドの開発チームでは、スプリントごとにKPTを行い、その中でProblemとして出た課題を技術的に解決する方法を考えるMTGがあるのですが、そこで以下のような方針を決定しました。

「nullを使わず、未定義を表すクラスをちゃんと自分たちで定義しよう！」

なぜこのような方針になったかということと、やってみてどうなのかということを以下似紹介します。

経緯

あるページが特定条件で変数の中身がnullで表示の箇所で落ちるという不具合が発覚しました。

PHPerの皆さんからするとあるあるですよね。

目の前のバグはすぐ解決しましたが、その問題がProblemとして上がり、改善策をみんなで議論しました。

そもそもnullは何を意味しているのか
表示するときにnullだったら、項目ごと表示しないのか？「未設定」などと表示するべきなのか？
nullにはロジックが書けないから末端のview側でnullチェックしなければならず、nullのときの表示方法もぶれてしまうのではないか

このような議論から、

「nullを使わずに、未設定に当たる部分をクラスとして自分たちで定義することで、未設定な値についてのロジックをクラス側に書くことにより、view側にロジックが散らばらないのではないか。」という結論にいたり、試してみることにしました。

結果

結果として、今までただnullとしていたものが「削除済み」だったり、「未定義」だったり、「非公開」だったり、ちゃんとした意味を持つクラスだったということが浮き彫りになりました。

例えば、アクションを行ったユーザーが削除済だった場合、今まではnullが入っていたが、削除済のユーザー(DeletedUserクラス)を入るようにしました。UserクラスとDeletedUserクラスは同じinterfaceを持っているので、view側では全く同じメソッドが呼ばれるようになり、条件分岐がなくなります。

いままでnullに押し込めていたロジックがクラスとして現れ、それにロジックが書けるようになり表現力が上がりました。表示に関わる処理もview側からドメイン側に移すことができ、コードの重複が減るようになるはずです。