assertを使いこなす(こなしたい)

もちろんコレ!のインスパイア!!

speakerdeck.com

 

の話で。

プリンシパル・プログラミングにも書いてあったが、改めて意識したい点として「コードは書く時間より読む時間(人、回数)の方が多い」であり。
読み手にフレンドリーである事がとても良い。どうやるか。考える(べき)ことを減らす。
その一環として「表明」。「ここは、こうである」と。「AかBがCかそれ以外」を考慮するよりも「AかBか、それだけ。他はあり得ない」としてくれると楽だ。件のスライドを読み返したら書いてある、「想定しな蹴らばならない状況が減った」は正にこれだな望ましいな・・・

この「あり得ない」をコード上でサクッと「表明」してしまえ、というassertである。こいつと仲良くしたいな、という話。

自分としては、割とシンプルな条件の時に限って assert()を使うかもな、みたいな好みがあって複雑なときにはそりゃもうLogicExceptionなどを投げるんだけど。
ただ、使い分けが曖昧〜・・・・

  • 「複雑な」というのは、例えばif-elseif-elseで最終のelseに入るような呼び出し方は見直したほうがいいぜ?というときは、exceptionのthrow
  • 「複雑じゃない」というのは、例えば「RDBトランザクションが発生している状況でしか呼ぶなよ?」というメソッドにおいて、 $driver->inTransaction() みたいなくらいならassertで済ませるかも

メリットとしては「本番で無視されるからコストないぜ!!!!」っていうところか、ただしこの資料にあるように、「環境の差異減らしたいぜ〜」というサイドのみかたもあるかも。とはいえerror_reportingとかは分けるだろうから、自分としては「便利さに溺れていこうぜ!!」ってことでアサートは有効にするかな


って思って書きながら調べてたら、この記事とかは基準になるかもなー。

www.infiniteloop.co.jp

さすがのインフィニットループ様やでぇ。。。


  • 悩みとしては、「実例が少ない」     * 実際にどう使うか観点で、「めっちゃ判然とした!!」ていうレベルのプラクティスに出会えてないんだよなー
  • 気持ちとしては「どんどん推進・活用していきたい」

という温度感。
「本番に入る前に確実に防止できる(発覚する)、という自信ないし保証がある」ってところか。
あーさっきの記事の例も踏まえて考えると、「publicなAPI(web api、ではなく)」での利用は慎重になるべきかもしれない。逆に言うとprivateメソッドだと「目が届く」ので「呼び出し方・使い方を間違えてしまう」というのを、防ぎやすいというか。

いずれにせよ、テストカバレッジを一定以上に保っておかないと「見落とし」確率が高まって危険かもな。。


「コードは、何をするかは示しやすい、どうやるかも示しやすい、ただし何故やるのかを示しにくい」というので。この「なぜ」の部分、背景やらコンテキストやらを埋める手段として = 筆者の気持ちを考えなさい問題を回答する際のヒントとして、assert()いいよね〜の話
LogicExceptionとの住み分け、使い方、基準を自分の中で洗練させていかないと・・・