[dart] null許容型の扱いについて👀

dartはnull許容型を提供してくれていますが、

今回はその扱い方について色々と考えてみたいと思います。

null許容型にすることでnull値で表現され得るデータを扱うことが出来ますが、

それは同時にそのデータがnullに成り得るということを示します。

設計、実装、テストにおいてはこれを考慮に入れなければならず、

ある種の並行的な思考が求められるのだと思われます。

問題はこれが散財することであり、

クリティカルな部分で発生してしまうことにより

不必要に認知上の負荷を高める可能性が高くなることだと思われます。

そして1箇所でその表現を許せば、あとは易きに流れるのが人間の性というもの。。。

ますます複雑性が増すものと思われます。。。

しかしながら、人間は完璧な存在ではありません。

それはどんな人間であってもです。

諸々の理由で人間はエラーを犯すものであり、

それが欠陥を作る可能性を高め、

それに起因する故障と、

それによる影響を及ぼすことにも成り得ます。。。

これはJSTQB FLのシラバスにあるとおりです。

このような人間の性質を鑑みるに、

認知上の負荷を高めるつくりにしてしまえば、

その結果は火を見るより明らかになるものと思われます。。。

このように考えてみると、

目の前のnull許容型は本当にnull許容であるべきかを問うことが重要であると思われ、

安易にnull許容なデータを作ることは負債にも成り得るのではないかと思われます。

この場合、そのようなデータはnullを取らないように設計、実装することが

求められるのではないかと思われます。

ただ諸般の事情により、その見直しが難しいこともあるのかも知れません。。。

その場合はE2Eテストも含めて自動テストを充実化させて、

振る舞いを保証していくしかないのではないかと思われます。

nullチェックを強化したり、

nullの時の処理内容について考えたりなど、

レビュー(セルフも含む)という静的テストで

色々と懸念点を考え、提案することも効果的ですが、

それも隈無くやり切ることは難しいので。。。

または以下のように考えることも効果的かも知れません。

設計や実装のあらゆる部分にnullが存在しえるものと見立てて、

その想定のもとにテストをすることで、

欠陥による故障、影響を未然に防ぐという『エラー推測』を行うというものです。

自動テストでカバーしきれない部分を

手動による経験ベースのテスト技法で補完し、

カバレッジを高めることで対処していく、

というものです。

システム全体にnullの余波が及んでいるとすれば、

その功罪を鑑みて全体的なリファクタリング、

またはレガシーマイグレーションを試みつつも、

それらのコスト次第では先述のテストを充実化させること、

それを組織的にサポートすることもまた求められるのかも知れません。。。