やったこと・書いたもの{2021,01}

やったこと・書いたもの

OSS

github.com

5分弱でマージされてビビった・・・w

勉強会・LT

その他

torana.co.jp

お声がけ頂いて、記念すべき第1回目のゲストとして参加しました。
(リハーサルも本番も、ただ自分も興味あることを楽しくお喋りさせていただいただけ・・

エラスティックリーダーシップを読んだ

読書記録

f:id:o0h:20210123200040p:plain 『エラスティックリーダーシップ ―自己組織化チームの育て方』のレビュー Roy Osherove (にちようびさん) - ブクログ

ということなので、他の本と並列しながら隙間隙間で読んでいったり〜で、11月に読み始めて年末に読み終えた。
(自分の場合、ブクログは「読み始めたタイミングで本棚に登録」「読み終えたら読了日を記録」という使い方をしている。)

コレはとっても良い本で、2020年は良い本との出会いがたくさんあったなぁと感じるが、個人的に年間ベスト5に入るかも知れない。
ふと「読書記録を晒していなかったんだな〜」と気付き、折角なので読みながら手元で付けていた読書メモを転記してみる。

全篇を通読してはいるが、「10章: 管理職のためのマニフェスト」は今の自分が読んでも中々遠く想像がつきにくいような印象があったので、特にメモはとっておらず。
また、本書の「後半」にあたる第Ⅴ部・第Ⅵ部については、オムニバス的なエッセイ集という趣があり、今回は「前半」ほど熱心にメモを取らなかった。内容については、ところどころ刺激的だったりハッとさせられるようなものが含まれている。また折に触れてこっちも読み返したいし、その際にはなにかのメモを作ったりもするかも知れない。

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

  • 作者:Roy Osherove
  • 発売日: 2017/05/13
  • メディア: 単行本（ソフトカバー）

ということで、以下は雑多に作った読書メモからの転記。

続きを読む

「is_null()を使うか === nullを使うか」と何気なく聞いてみたら面白かった

PHP

と軽い気持ちでツイートしてみたら知見が寄せられて面白かった話。
「全然その辺りは好みの問題じゃないかな〜？」というのがあったんですが、1発目・2発目からガッチリ論拠のある意見をもらって「おぉ、なるほど・・・」となった次第。

そもそも

PHP 8 で作る JSON パーサ / php8-json-parser - Speaker Deckを見ていて、「お！ ===だ！」と思って気になったんですよね〜。 該当コードは↓。 github.com

(ちなみに発表内容がすごく面白かったです、今だとLIVE配信のアーカイブ観れますが恐らく後日セッションごとに切り分けられたものが？上がると思うので、動画のリンクは止しておきます)

自分的に「is_null の方が読みやすくない？」って思っているフシがあったので、さてどっちだろうな〜と。

※ 他の方のツイートを埋め込み表示にするの何となく気がひけるので、リンクの明示だけにしておきます

わたしは

is_null() を使う事が多いな〜と思っていて、

  • null と「同じ」である、という表現が何となく気持ち悪いような
    • これ多分SQLのせいだなーって話をしている内に思った
  • 自分は「名前がついている処理」はなるべくソレを使いたいな〜という性質がありそう
    • 「それが用意された」のに相応の理由があるのかな、という気がする
    • 関連して「目立たせておくべき」で「書き換えor読み間違いにくい」というような気もする

落とし所としては

  • 書き方が揃っている ことが最重要な気がする、それさえ抑えていれば「些細な問題」に収まる範疇なのかな？という感覚
  • それを決めるための「論拠」があった方が良い、というのは間違いないです！
    • === null の方が「しっかり」してそうだな、って話を聞いてて思った
  • また、こういうのを「ルール」にしたら(人の力に頼らず)linterに仕事させたい！！

ってことで、以下寄せられた意見

=== null 派

パフォーマンス的な面

「FQSENで記述しないとオーバーヘッドが大きくなる」というもの。
このレスが速攻で飛んできて「すげぇ！」「ありがてぇ！」ってなってしまったw
(いや本当に、反応もらえたとしてもゆるふわっとした感じだと思ってたので。)

PHP的に is_null($v); は2通りの解釈ができて、

  1. 自身が属するnamespaceにおける関数、 ns\is_null() というもの
  2. グローバル(組み込み関数)としてのis_null、すなわち \is_null() というもの

もし \is_null() と明示的に呼ばれていれば問題は起こらないが、そうでない場合、まず1のis_nullを探してから2のis_nullを呼ぶ、というものになる。

もちろん use function is_null; と書けば問題はない、が、面倒くさいのでは・・・？と(個人的に)思った。
それだったら最初から === null でいいじゃん、というもの。

コレ自体は「言われてみればそうだな、確かに確かに」と思ったんだけど、補足のリプで「opcodeを追ってみればこんなに自明」という風に情報を示されて、「なにそれ面白い早く俺もそっちに行きたい」という感情を刺激されてしまった・・・・

また、別観点として「そもそも明示的に \hoge() と書くの良いかもな〜」というのも思った。
誤読が少ないし、分かりやすい。

ちなみに、逆に言うとルート空間の明示を省略して書くことで「関数をぶっ壊す」というのも可能で、実際にfile uploader周りのテストを書く時に「is_uploaded_file()を無理やりtrueにする」みたいな処理を過去に使ったことがある。

<?php

namespace Vendor\Package\FileUploader\Uploade {
    fnuction is_uploaded_file($filename)
    {
        return true;
    }
}

みたいな。

シンプルさの面

if (is_null($v)) とした時に、

  1. まず is_null: bool がチェックされて
  2. 次に if (bool) が チェックされて

とか何なん！的なもの。(って書き方だとニュアンス伝わりにくい、「関数をコールするよりは式のほうがシンプルじゃないか」的な)

また、「他の値(例えば is_true())の時もそうやってやるんか？？」と言われ、なるほど〜見方によっちゃ揃ってないな？という。
これもまたなるほど・・・

is_int とか is_string とかは使い道ありそうだけど、「nullかどうか」は「null以外はnullじゃないの」となるので、違和感があるな〜とも思った。
「値が1つしか存在しない」というのを前提にすると「nullを特別扱いするか？」が恐らく感覚の境目になってきて、

  • nullは特別だからis〜 でやろうよ
  • is〜を使うことで「値が1つ以上あるから、値の種類で判定したい」みたいに誤読しない？

という対立する判断に進みそうかもな。報われない気持ちを整理したくなるな。

そういや全く関係ないけど、is_string() に Stringable が来たらどうなるんだろうな？勿論「objectなんだからstringじゃない」と言ってもらわないと困る気がするけども。
(お、こういう時にphptを見れば早いのでは・・？💡)

他言語だと == じゃね？

GolangやTSを例に引いて、「”無”なオブジェクトとの比較も == で行うしね、違和感とか覚えなくて良いはず。寧ろ自然じゃないかね？」というもの。

言語特性としてPHPは「色々な歴史がごちゃまぜになっている」という面があると思うので(良い悪いではなく！ただ、間違いなく特徴ではある)、使い手側が「負債を引きずり込みすぎない」というのは意識した方が良いよね〜って気持ちも個人的にあります。
(しかしそういう「PHPのゆるさ」みたいなところについて、RFCでこの仕様はこの言語の暗黒時代の遺産を引き継いでいるって表現を見た時は笑ったw)

その観点から言うと、「他の言語やコミュニティの例に倣う」というのは時に効果的だな〜って思います。

is_null() 派

SQLだとさぁ・・・

SELECT * FROM table WHERE a = NULL;

って書きませんもんね・・！ 全く違う世界の話を引きずらないで、と言われればそうなのですが、やっぱり「nullは中身が確定していない事を表す」はずなのに「イコールで比較とは果たして・・？」っていう気持ち悪さが頭をよぎります。

という人が他にも居てよかったw

(なおココでpy の if v is None: を挙げている人がいないのは、私のTLの偏りだと思います😃)*1

ちなみに、@d_horiyama_webさんにもらった「lintに従う」というのは凄く良い判断基準だよな〜と思っていて、まさにこういう「自転車置き場の色」は機械に覚えさせておいて判定させる、というのが良いですよね。*2

静的解析等で「=== nullを使え」という風になっていれば、それは凄く正しいというか「そうしましょう、なぜならそうすることが良いからです」みたいな話に落とし込めるので現実的に素敵な話。
ただ、これは独自に拡張していたルールなのかな・・？パッと探ってみて見つけられなかったです💦
Pslamでの挙動が一時的に不吉だった時期があったのかな？
=> is_null($value) not treated same as null === $value · Issue #2578 · vimeo/psalm · GitHub

実際問題、そういうのルール作って良い気がする。

f:id:o0h:20201214000919p:plain Psalm - a static analysis tool for PHP

f:id:o0h:20201214000941p:plain Playground | PHPStan

f:id:o0h:20201214001031p:plain Phan in Browser

て感じで、Psalm、PHPStan、Phanだと検出されたIssueなし。PhpStormでもソレらしきInspection見つからなかった・・かな？

「専用の表現あるなら使えば」派

「nullを示すもの」を判別するための「専用の書き方」があるのであれば、それを利用することで読み手の注意を引いたり「何をしたいのか」を判読するコストが下がるのでは？というもの。
(割と期間を一緒に働いていた元同僚なので、そういう温度感を互いに共有していたのかもな〜というメタな感想もいだきましたw)

それと、このツイートで情報として「PHPCSがsquizのrulesetで is_null() を禁止している」という情報が 💡
確かに、見てみるとForbiddenFunctions として設定されています。

github.com

なるほど、PHPCSの文脈で探ると何かあるかな・・？と思ったら、PHP-CS-FixerのIssueで興味深いものが出てきますね。

github.com

ここでベンチマークもはられていて、何だか条件によっては\is_null() の方が有利になる？という話も。

  • PHP 5.6: is_null($x) is 2.5x slower than null === $x with opcache disabled, and 2.2x slower with opcache enabled
  • PHP 7.0-7.2: the performance of both is the same, with and without opcache
  • PHP 7.3-7.4: is_null($x) is 1.2x faster than null === $x with opcache disabled, with opcache enabled there's no noticeable difference (but still, is_null() is 0.2% faster).

とはいえ、このIssue自体は「はっきりしたことが分かるまでは積極的にやる程でもないかなぁ」「生じたとしても微細な差分なので、今までのやり方を変えるほどかどうかは微妙？」というような温度感になっています。
(closeはされていないけども)

ということで

どっちかっていうと === null の方が分かりやすいのかもな〜って気がしてきました！
が、

  • まぁチームの好みに合わせて
  • lint入れてガッとやっちゃうのが健全じゃないかな？
  • でも多分、世の中の多くの人は大人なので「別にどっち来ても気にしないよ(表向きはね)」で済ませているんだと思います

というものです。

ちなみにアンケートも実施されているのですが、=== が優勢かな 😗

あと、他に「is_null() が (isset()と違い)関数なのこんがらがるね」という声もありました。
「is_hogehogeとishogehogeがあるの命名ばらばらで気持ち悪い」と思うか、仮に is_set() だったとしたら「is_hogehogeという命名の中で関数だったりそうじゃなかったりするの怖い」と思うか・・・？
って考えると、脳みそが痛くなりそうですね！とか思ってﾌﾌｯてなりました。

なんにせよTwitterで色々と意見もらえたのが楽しい、こういうのあんまり仕事とか同チーム内でやると変な疲れ方しそうでもあるので・・！

*1:これ https://twitter.com/tadsan/status/1338075560979779584 は私も思うところ、というかinstanceof だけ文章っぽいのが違和感あるんだよなぁ。。

*2:今回の場合、技術的な観点での「こっちの方が良い」という意見が寄せられてますが、「readabilityに勝るもの無し」な差だと思うので「些細な問題」と言わせてもらっています。もちろん、意見表明(まして根拠の説明)をしてくれた人を軽んじるとかそういうアレじゃないです！！！

「光遅い」と言い放ったエンジニアさんの影を未だに追いかけている

PHP

いや、タイトル「何が何だか」って感じですが・・・

#phpcon2020にて喋ります〜

明日、どころか・・もう日付変わって本日行われるPHP Conference Japan 2020にてお喋りしてきます 🎉

fortee.jp

自分は「Composer2.0」の話をしますよ〜とプロポーザルを提出し、採択して頂きました。
実は「Composerの新バージョン」については、昨年のphpconでも取り扱おうとしていた話題ではありました。単純に発表時間が足りなかったのと、また開発状況としてもまだまだ途上だったので見送っています。

それが、1年越しに開催される同イベントで、CfPオープン期間には「v2リリースの目処が立ち」本番を迎えるまでに「安定版がリリースされ」・・・と、着実に続く時代の流れを感じながらも「もしかしたらずいぶん遠くに来ちまった」とも思ったりしちゃっています。

さて、そんな訳で今回お話する内容は自分の中では「前回の内容に引き続き」という面もあります。
(ただ、結局のところ実際にスライドに落としてみたら独立した内容になりましたがw)

その内容を知らなくても理解できる・・というか「読んでいたところで直接の役には立たん」かも知れませんが、
このセッションタイトルやプロポーザルに反応してくれた方であれば「Composerの話」は面白がってくれるんじゃないかな？ということで、紹介しておきます。

続きを読む

プロダクトのための技術力をどう上げるか: ⓪なぜ技術力は必要とされるのか

考え事とか

イントロ

自分は「どうやったら技術力を上げられるかな」という点に興味があり、また最近では「組織から継続的に"成長"を与え続けられるのだろうか」という点に興味がある。
まずは自分の中の認識や仮説みたいなものを形式知としてみようと、取り留めなく散文を吐き出していたのだが、その中で幾つか重要なエッセンスがある事に気付いた。

「取り留めなく」と書いたが、実際に気づいた事や感じた事を1つの文書に纏めようとすると、実際かなり散らかってしまっている(し読むのも書くのも疲れる)。なので、ポイントを絞りながらそれぞれを複数の文書に分け、現在の観点・思考を表して見ようと思った。
この記事がその第1段である。

あくまで「自身の内にあるこんがらがった思考を解きほぐしておきたい」というのが大きな狙いであり、セルフ壁打ちのような効果を期待して取り組むもの。

記事の作成のためのメモ

  • ビジネス対する要求は複雑化し続ける
  • ゆえにソフトウェアも必然的に複雑化し続ける
  • 要求に応えるためには「リスク」が避けられない
    • このリスクをミニマムにしていく事が重要
  • 何がリスクを増大化させるか
    • 本質的な命題の難しさ。「答えのない問い」であること
    • 打手の少なさ。
  • 何がリスクを最小化させるか
    • 仮説を築き、世に問うまでを短くする
  • 技術力の価値 = アジリティを高く保つ武器といえる

本論

まずは「そもそも技術力とは何のために求められるのか」という所を考えてみたい。

勤めている会社などにおいて、「組織の技術力を高める」という命題が標榜されたとする。以下の疑問が湧く。

  • 「技術力」という言葉を安易に使いすぎなのでは、という嫌いがある
    • 自分もそうだし、恐らく他人もそう
  • そもそも「技術力」というのが何であろうか？っていうのが曖昧なままで過ごされている気がするし、あるいは「目的」なき「手段」として存在が許されていないか？とすら思う

この中核にある「技術力」という概念、これに対する「なぜなのか」「なにであるのか」を真正面から捉えることなしに、「それを高める」という夢は叶えられないのではないか。つまり空中分解しかねない。
今回のテーマは、そうした問題意識を下地として思考を試みたものだ。

以下、先に社内向けに書いた文章が先に公開するに至ったので、そちらをベースに転記。
(・・・なかなか主語がでかい話であり不安はあるけど。。)

「目的」から考える技術力

技術力が開発に何をもたらすのか？おおよそ、これらの3つの価値を提供するものと考えている。

  1. スピード
  2. 品質
  3. 妥当性

この3つを兼ね備えると「アジリティ」っていう価値がもたらされ始めるはず。何故アジリティとやらが必要なのか？どう良いのか？は、noteのマガジンで秀逸なのものがある。是非読んでみてください。

note.com

これらのパラメーターが強化されることから、「技術力が高まることは勝ちにつながる」ものといえる。

スピード

開発するスピードが「良さ」なのは特に説明いらないと思う。ソフトウェアやシステムを進化させるのが我々の仕事なのだから、同じ仕事が10時間を必要とするよりも2時間で終わった方が良い。

品質

品質は、例えば「バグを生まない」とか「拡張性が高い」とか「読みやすい」とか。ざっくりいうと「良いコード」というのは「品質」って言葉に代替可能だと思う。もっと言うと、結構「品質の高いコードとはどんなものか？」に対しての回答は人それぞれかもしれない。1つの示唆として、品質という話であればマーティンファウラーの記事に気付きが多い。

martinfowler.com

「どう良いのか」は語れる。が、「何であるか」は難しいかも知れない。むしろ、「良いコードとは」という問いに対する答えを、個々人が持っていると良いと思う。(自分の場合、長らく「リファクタビリティ」が良いコードを言い表すものだと思ってたけど、最近はもう少し広い意味で「書き換えやすさ」かなーって感じ)

妥当性

(コレが1番分かりにくいかな?)
例えば「RDBにするか検索エンジンを使うか」みたいな選択はあるし、ECSかGKEかみたいな選択もある。そこを失敗すると、サービスのスケーラビリティの問題だったり(非)機能要件への適合が難しくなったり。ソフトウェアで言っても、例えばよりミクロな話、外部ライブラリを使うか自前で薄いコンポーネントを使うかみたいな選択とか。オーバーエンジニアリンクになるか、腐敗臭のするデザインになるか?という所にも繋がる。

そしてアジリティ

この3つが満たされれば持続的な成長を維持し続けられるようになるでしょ、それを保証するのが「技術力」だよ、と。
アジリティとは「機敏さ」という意味で、これがあると「柔軟さ」が獲得される。
この「柔軟さ」がビジネスの価値を高める、成功の確度を上げるための強力な武器になる。

anti複雑さ

なぜ「ビジネスの進化には柔軟さが必要」か？

そもそもの大前提として、「ビジネス」は複雑であり、ビジネスを微分したものである「ソフトウェア」や「ソフトウェア開発」も複雑なものである。
何がマーケットに受け入れられるか？自社、競合を取り巻く環境は？顧客や潜在的なターゲット層の「気分」は？
それらは正確に「計測」することも難しければ、正解を教え導いてくれる師範もおらず、更に悪いことに「次の瞬間には状況が変わっている」ということが常である・・・という、複雑さ。

そんな複雑な問題に、どう対処していくか？ 1つのアプローチが「実際のマーケットに、1回でも多く問い、フィードバックを回収し、また次の一手を打つ」というもの。

アジリティを得ることで、「素早く・小さく失敗し、地に足のついたフィードバックを元にして、要改善点を克服し、また素早く世に問う」というループを回せるようになる。
「1発の大振りで成功するかわからないから、100回打席に立ち、その度にフォームをチェックし、修正し、珠に当てにいく」というもの。その逆に、「大振りをするための準備が整うまで、打席に立たないでいる」となれば、フィードバックを得ながら改善をするための(あったはずの！！)機会が損なわれいてく。必然的に、失敗へのリスクが高まる。

アジリティと、スピード・品質・妥当性

とにかく「打席に立つ回数」が必要、ということで「スピードが重要になる」。
スピードが遅いと、打席に立てる回数が減り、「失敗した時に取り返しがつかない」という硬直性も高まる。また、少ない打数で上手くやるには、非常に綿密で高度で正確な「予測」が必要になる。・・・市場はあんなにも気まぐれな生き物だというのに！

品質はどうだろうか？
これは、先に上げたファウラーの記事に詳しい。「内部品質の低下は、速さの逓減をもたらす」というもの。付け加えるのであれば、外部品質だって、低下すれば顧客の離反を招く・・・すなわち「得られるフィードバックの量が減る」という結果をもたらすはず。

最後に妥当性。
「適切な選択」というのは、そもそものスピード(初速)に大きな影響をもたらす。あるいは、「初期の誤った選択」は、後に取り返しのつかない致命的な「負債」となるかもしれない。これも、やはり硬直性を生じさせる。

結局、スピード・品質・妥当性はそれぞれ不可分であり、また高いアジリティを実現し維持し続けるためには、これらを突き詰め続ける必要があるのだ。

「複雑さ」に対する補足

「ソフトウェア開発は本質的に複雑さを伴うものである」という点について。
「変更しやすい」ことを以て「ソフト」な資産、と称される。裏を返せば、「変更されること」が存在価値として織り込まれている、とでも言うべきか。そうやって、次々に「進化していく」ことが宿命付けられている。

「なぜソフトウェアは進化する(させられ続ける)のか」という論点について、論文があるという。

いわく、「使われ続けると、利用者(やその代理人たるプロダクトオーナー)からの要求が生じ、それに応えることで進化を求められる」「ゆえにソフトウェアは進化し続ける(複雑さを増し続ける」ように考えられる。

ソフトウェア開発はとても複雑なものである。

アジリティを備えたプロダクト組織になる

何のために会社がありビジネスをやっているのか？といえば、経済的な価値を生み出すためだと思う。それは、顧客価値を中心に生み出される付加価値の総和である。
顧客価値は創るのが難しい。そのために、複雑な問題に挑む必要がある。
複雑な問題に立ち向かうための武器がアジリティ。
そして、(働く上での)技術力の目的・・「何のための力なのか？」という問いに対して、今の所の自分の見方が「プロダクト開発のアジリティを高めるため」である。

それって、我々に何かメリットありますか？

ここまでずっと「ビジネス」「組織」を主語において話をしてきたので、「なぜ良いのか」がピンと来にくい。
なんだか「正論」という感じで、それが「開発者1人1人にとって関係のあることなのか」については、説得力を持っていないような。

「高いアジリティを持つ組織」で働く、というのは開発者にとってどんな体験だろうか？
結論から言えば、恐らく「そこで働いていてワクワクしながら開発に携われるようになる」というものだと思う。

開発に対するモチベーションというのは人によってそれぞれだというのを前提としつつ、広く共通するのは「何かを良くしたい」という想いではないか。
例えば「ユーザーを喜ばせたい」とか「自分の納得が行くような綺麗なコードを書きたい」とか「より高いパフォーマンスを実現したい」とか。
そうした際に、組織がアジリティをもって開発できていたらどうなるか？恐らく、これらの前向きな気持ちを持った人たちには嬉しいと開発体験につながると思う。

「ユーザーを喜ばせたい」人たちにとっては、「開発コスト(時間、リスク)が高いから難しい」という理由で、望ましい機能の実装提案を却下される場面が減り、「良いと思えるものを作って、リリースする」ことに集中できている状態。或いは「新機能をデリバリーする」ことへの組織が持つコストが低く抑えられることで、リリースした後にユーザーの反応を観察し、取り入れながら更に良い機能を開発していく！というのに集中できる。
これらはスピードが低ければ難しいし、品質が低いようだと「保守に当てるリソース」によってエンハンスメントやアイディア出しのための力が逼迫されることになる。

「良いコードを書きたい」という人たちにとっては、実践的なツールやサービスの導入も、しっかりリスクをコントロールした上で試してみることも出来る。
開発者というのは、『ソースコートを通じて活動する」のだから、ある側面では「自分たちのプロダクトのユーザー」でもある。自分たち自身を「ユーザー」として、開発体験についてのフィードバックとそれを踏まえた改善のサイクルをクルクルと回しながら「より良い開発」を獲得できる事が重要。
プロダクトと一緒に開発チーム自体が進化のペースを保ちやすい状態だ。「高い生産性を生む」という価値実現に向けて、不確実性を制御しながらの前進がもたらされる。

そして深く広い見識と自信から来る「妥当性」は、品質・スピードを安定的に支えるために欠かせない。もし妥当性に関する意識が低いようであれば、「なんでもやってみる」の後の棚卸しが実現せず、負債が貯まり続け硬直性の増加を招く。

「どんな願望もアジリティによって叶えられる」・・・などと言えば眉唾物になるが、しかしながら、実際問題として「前を向き本質的な”コト”に意識を向ける」ための基礎力として「アジリティ」というのは非常に重大な価値を持つ。その獲得のために、やはり技術力というのは重要な下地となる。

—✁—切り取り線—✁—
なんか偉そうな文体で書き始めてしまったばかりに！！
あまり気持ちが籠もらないのですが！！

「技術力つけるときっと楽しい事をたくさんやりやすくなるぜ〜〜！！」って思っています！！！！という事！！！

あ〜〜〜〜楽しいことやりたくない！？！？
楽しいことって、どうやったら出来るんだろうね！！

??? 「 アジリティです、アジリティについて考えてみるのです・・・ 」

って感じ
—✁—切り取り線—✁—

結び

結局の所、組織人としての観点から考えれば、働く上での「何が目的か」というのを平たく言えば「ビジネスを成功させるため」となる。
しかし、ビジネスやプロダクト開発は複雑で大変に難しい。成功の確度を上げる必要がある。その為には「いかに柔軟に動けるか」、「高速にフィードバックループを回せるか、すなわち『問う・観察する・学ぶ・活かす』のステップを繰り返せるか」に拘る必要がる。それがアジリティという言葉で表せる。
そのアジリティを実現する事こそが、開発組織にとっての『技術力の価値」ではないか？と、自分は考えている。
ざっくりと「技術力」というと余りにも大味な表現になるが、「スピード」「品質」「妥当性」という、それぞれが相互に密接に関わりつつも個々が重要な意味を持つエッセンスに着目し、拘り、磨きたい所。

「ビジネスを上手くやる」のに集中できている状況において、人は「コト」へ集中し、本質的な価値創造に取り組めるようになる。
すると、それが「ワクワク出来る開発業務」へと至るはずだ。

その辺りを追求することで、「ビジネス的な価値」「自身の欲求に対する回答」の折り合いがつく場所に到達できるのではないか？と考えている。

「\Throwableをcatchしないで」と伝えていく

PHP

「Throwbaleをcathcしない方が良いよ、って前に言われたことあるけどアレってソースある？」と言われまして。

f:id:o0h:20201128140525p:plain f:id:o0h:20201128175047p:plain

※ 画像はイメージです

自分としては、どちらかというと「考えていったら自然とそう思えたので」という生き方をしており、確かにソースか〜探したことなかったなぁ。。。となり。即答できず。
「理屈はわかる」のと「毎度説明するのが面倒」は別物ですよね。
(寧ろ、折角PHPの本を書いたのだからそこで言及しても良かったかもな〜)

f:id:o0h:20201128140847p:plain

「話すの面倒くさいと説明のクオリティが毎回変わる」ので、あまり気持ちよくありません。
かといって、「毎回ちゃんと説明する」のは非常に骨も折れるので、それもやっぱり気持ちよくありません。

ということで、「Throwableってなに？Exceptionと何が違うの？調べてみました！」です。

  • tl;dr
  • いんとろ
  • 前提: ポケモンキャッチ
  • 改めて \Error とは
    • なぜ Error(throwable) が必要だったのか？
    • 捕捉・復帰ができない
    • エラーハンドラとの兼ね合い
    • finally, __destructとの兼ね合い
    • RECOVERABLEであってもRECOVERするには扱いづらい
  • Error が何か？を理解すると、catchしたくなくなる(はず)
  • まとめ

・・・書いていたら思いの外長くなったので、tl;drをつけます😌

tl;dr

これらの文献のうち、特に顕著な表現としてtrowski氏とThrowbaleのRFCの表現がわかりやすいです。これが「何かソースありますか？」に対する回答、ということで良いのではないか？

Error should be used to represent coding issues that require the attention of a programmer. Error objects thrown from the PHP engine fall into this category, as they generally result from coding errors such as providing a parameter of the wrong type to a function or a parse error in a file. Exception should be used for conditions that can be safely handled at runtime where another action can be taken and execution can continue.
Since Error objects should not be handled at runtime, catching Error objects should be uncommon. In general, Error objects should only be caught for logging, performing any necessary cleanup, and display an error message to the user.

https://trowski.com/2015/06/24/throwable-exceptions-and-errors-in-php7

また、ThrowableのRFCでも「キャッチすべきではない」と端的に説明されとります

catch (Error $e) and catch (Throwable $e) may be used to catch respectively Error objects or any Throwable (current or future) object. Users should generally be discouraged from catching Error objects except for logging or cleanup purposes as Error objects represent coding problems that should be fixed rather than runtime conditions that may be handled.

PHP: rfc:throwable-interface

この辺りが、「ちょっと調べてみよ＆ブログに残しておこ」と思ったきっかけに対する答えとなっております！

以下本編。

続きを読む