もちろんコレ!のインスパイア!!
の話で。
プリンシパル・プログラミングにも書いてあったが、改めて意識したい点として「コードは書く時間より読む時間(人、回数)の方が多い」であり。
読み手にフレンドリーである事がとても良い。どうやるか。考える(べき)ことを減らす。
その一環として「表明」。「ここは、こうである」と。「AかBがCかそれ以外」を考慮するよりも「AかBか、それだけ。他はあり得ない」としてくれると楽だ。件のスライドを読み返したら書いてある、「想定しな蹴らばならない状況が減った」は正にこれだな望ましいな・・・
この「あり得ない」をコード上でサクッと「表明」してしまえ、というassertである。こいつと仲良くしたいな、という話。
自分としては、割とシンプルな条件の時に限って assert()
を使うかもな、みたいな好みがあって複雑なときにはそりゃもうLogicExceptionなどを投げるんだけど。
ただ、使い分けが曖昧〜・・・・
- 「複雑な」というのは、例えばif-elseif-elseで最終のelseに入るような呼び出し方は見直したほうがいいぜ?というときは、exceptionのthrow
- 「複雑じゃない」というのは、例えば「RDBのトランザクションが発生している状況でしか呼ぶなよ?」というメソッドにおいて、
$driver->inTransaction()
みたいなくらいならassertで済ませるかも
メリットとしては「本番で無視されるからコストないぜ!!!!」っていうところか、ただしこの資料にあるように、「環境の差異減らしたいぜ〜」というサイドのみかたもあるかも。とはいえerror_reportingとかは分けるだろうから、自分としては「便利さに溺れていこうぜ!!」ってことでアサートは有効にするかな
って思って書きながら調べてたら、この記事とかは基準になるかもなー。
さすがのインフィニットループ様やでぇ。。。
- 悩みとしては、「実例が少ない」 * 実際にどう使うか観点で、「めっちゃ判然とした!!」ていうレベルのプラクティスに出会えてないんだよなー
- 気持ちとしては「どんどん推進・活用していきたい」
という温度感。
「本番に入る前に確実に防止できる(発覚する)、という自信ないし保証がある」ってところか。
あーさっきの記事の例も踏まえて考えると、「publicなAPI(web api、ではなく)」での利用は慎重になるべきかもしれない。逆に言うとprivateメソッドだと「目が届く」ので「呼び出し方・使い方を間違えてしまう」というのを、防ぎやすいというか。
いずれにせよ、テストカバレッジを一定以上に保っておかないと「見落とし」確率が高まって危険かもな。。
「コードは、何をするかは示しやすい、どうやるかも示しやすい、ただし何故やるのかを示しにくい」というので。この「なぜ」の部分、背景やらコンテキストやらを埋める手段として = 筆者の気持ちを考えなさい問題を回答する際のヒントとして、assert()いいよね〜の話
LogicExceptionとの住み分け、使い方、基準を自分の中で洗練させていかないと・・・