明日になったら「明日」になるから、多分、綺麗にならない

親方

なんかつい最近も似たような事を書いたような記憶が、なくもないのですが(
ソレはきっと、ビューティフル・ドリーマー - gallu’s blog )。

今回は(も)、端的には「技術負債を作らないために」的な話でございます。
んと……定期的に耳にするのが
・今は時間がないから、仕方がないから汚くてもまず実装して仕上げる
的なお話。

まぁ「汚い」のレベルにもよるのですが、一旦「そのままにすると負債になるレベル」と仮定します。
「時間が無いから締め切りがあるからやむを得ず一端」というのはわかりますしきっとその気持ちに嘘はないのだろうと思うのですが*1、端的には
・いつまでも負債は支払われず、それは重くのしかかってそのうち自重崩壊する可能性が上がっていく
事が多いかなぁ、と思われます……ってのを、もう少し噛み砕いて。

どこかで何か所かで拝見している、意味合いとしてはこんな内容の文章がありまして。
「綺麗に書ける人は時間をかけなくても大抵綺麗なコードを書くし、汚く書く人は時間を与えても大抵汚いコードを書く」
これを見た時に「あぁ、たしかにある程度そんなもんだろうなぁ」とか思ったりすることが、少なからず。

或いは「一旦忙しいから(ダメかもしれないけど)今までの慣習通りで書いて、しっかりした考察は後回し」ってケースが、時々、見受けられます。
まぁ「締め切り直前」とか、気持ちが「全く完全に1mmも理解できない」とは言いませんが。が。が。

ちぃと違う切り口としましては、曰く
「ベテランは"後で直せる"事を理解しているから、簡単に書く。非ベテランは"後で直せる"事を理解していないから、後で直さなくてすむように複雑に時間をかける(けど、後で直さなくてすむなんてことはあり得ない)」
けだし名言だなぁ、と思うところでございます。

汚く書く人の一番困るのは「後で直しにくいような設計で書く」のが一番の困り者でして……プログラムにしてもデータ設計にしてもテーブル設計にしても。
「綺麗にクラスが切れていて綺麗にメソッドが切れているんだけどメソッドの実装がちぃと泥臭い」であれば「そのメソッドを書き直す」とかで片付くことが多く、ちゃんとテストがかかれていれば「書き直した、テストした、OK」で終わるので、そんなに高い負担にはならないものでございます。
データ設計やテーブル設計だと「後での追加が比較的容易になるように丁寧に設計して、その詳細項目は一旦、欠けのある雑な設計」だと、「足りなくなったら追加しよう」で事足りるので、やはり、そんなに高い負担にはならないものでございます(まぁ「プログラム側が、カラムの追加に対してDRYであること」ってのが追加で入ってきますが)。

つまり、「汚い実装」は、割と多くの場合において「そもそも設計レイヤーでコケている」ケースが多い、というのがまず１点目としてあります。

で、その１点に追加をすると。
「綺麗な実装」ってのは、知っている限りでは「それなりに脳みそで汗をかいてもんどりうった先にある」事が多いように思われるのでございます。
つまり、ある程度の「熟考して立ち止まって３歩すすんで２歩さがってスクラップアンドビルドを繰り返して無理な要求とリファクタで悲鳴を上げながら」スキルが上がってくる側面が、どうも、あるように思われます。
その辺をやらずに「とりあえず汚いコード/テーブル設計を書き散らかす」を繰り返すと。「綺麗な実装」に対する経験値が積めないまま時間が過ぎ去ってしまう、ってのが、どうもちらほらとあちこちで、ごくまれに、例外的に*2見かけられるように思われるのですが、如何でしょうか？

次に「急いでるから一旦汚く書く」ケースで「じゃぁ、いつ、リファクタするの？そのスケジュールは具体的に抑えてるの？」って質問がありまして。
……書いたの最近だなぁソレはきっと、ビューティフル・ドリーマー( https://gallu.hatenadiary.jp/entry/2019/02/05/012839 )にある通りなんですが「そのうち」ってのは「いつまでもやってこない」時間軸なんですよねぇ大概。
だって未来は暇じゃなくて「次の作業」が鮨詰めに詰められているんですもの。

で、ってことは「あとで」は来ないので「綺麗に書く経験も苦労も悲鳴も怒号もないまま」に進んでしまうので。
そうすると結果的に「いつまでもコードが綺麗にならない」し「綺麗に設計するための修練を積むことができない」から結果として「汚いままで綺麗にする術がない」んですよね。

勿論「運用で苦労するもの」ではあるんですが、……その辺、認識できないと「他人に運用を押しつけて回避」とか「運用なんてこんなもんだ」くらいで、意識が出来ないまま無駄なコストを食らいまくっていくものでございます。
「極寒の地で全裸で凍えながらなぜつらいのかわかっていないようなものこれ以上心身に負担をかけると死にかねないよ」とは、けだし名言だなぁ、と。
「寒いのは当然、凍えるのは当然」とか言っていると、そのうち凍傷になって、場合によっては絶命するんですよねぇ。サービスにしてもエンジニアにしても会社にしても。

勿論案件なので「締め切りがある」ってのは重々承知しているのですが。
とはいえ、どこかで巻き返さないと、なんとなし「ジリ貧にならん？」とか思ったりするんですよ。
「巻き返してそれなりに修練を積むことの重要性」って、なんとなく、割と軽視されているように見えるんですが。

その辺、ど～なんですかねぇ？？

*1:「お気持ち」だけなら、ねぇ……

*2:≒大量に、頻繁に

2019-04-16

新学期も始まったのでまずは「学び方」

専門学校2019 必読書良書

ちょいとラインナップも変更になってきたので、頑張ってこの1年、また備忘録していきたいと思います。

まず初っぱなは「学び方」を学びましょう、ということで、毎度おなじみこちらから。

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

作者: Dave H. Hoover,Adewale Oshineye,柴田芳樹
出版社/メーカー: オライリージャパン
発売日: 2010/07/08
メディア: 単行本（ソフトカバー）
購入: 12人クリック: 221回
この商品を含むブログ (53件) を見る

併せて、これも毎年なんですが。

Bjarne Stroustrup: 標準C++を新しい言語として学ぶ
こちらから、この文章も、毎度毎度、使わせていただいております。

プログラムは書きやすく、正確で、保守可能であり、受け入れられる程度に効率的であることが望ましい。したがって、この理想に最大限に近づけるように C++(そして、その他のプログラミング言語)を使用すべきである。

それではこの1年、頑張って行きましょう！！

2019-03-26

Twig チートシート

PHP Twig

「あんちょこ」って大分と古くてあんまり使われてない単語なんだなぁ……というあさってな方向からの感想を述べつつ。

単置換

一番の基本だよねぇ。いわゆる「この変数を出力」ってやつ。

{{ variable }}

配列は．(ドット)でつなげる感じ。

{{ array.key }}

フィルタ

いろいろなフィルタがあって、割と便利。

{{ variable|filter }}

filterは、 https://twig.symfony.com/doc/2.x/ とかみるとわかるですが、なんか結構山盛り。
いくつかかいつまんで、使いそうかなぁ、って思えるものを中心にいくつか。

HTMLエスケープ。ただ、単置換でも普通にエスケープしてくれるからなぁ。
「js用のエスケープ」は、もしかしたら、便利、かも。

{{ variable|escape }}
{{ variable|e }}
{{ variable|escape('js') }}
{{ variable|e('js') }}

小文字になぁれ、大文字になぁれ

{{ variable|lower }}
{{ variable|upper }}

「改行をタグに」

{{ variable|nl2br }}

数値のフォーマット変更各種。PHPのnumber_format()関数と一緒

{{ variable|number_format }}

エスケープ無し。気を付けて使わないと危ないけど、とはいえ「必要な時は(稀に)あるよねぇ」というフィルタ。

{{ variable|raw }}

URLエスケープ

{{ variable|url_encode }}

コメントはこんな風に。

{# コメント #}

ある程度書いておいたほうが、後々、楽だよねぇ。

条件分岐

いわゆる if 文。

{% if variable == 'hoge' %}
    HTML
{% elseif variable == 'bar' %}
    HTML
{% else %}
    HTML
{% endif %}

演算子は、andとかorとかを使いましょう。

{% if 18 < variable and variable < 21 %}
    HTML
{% else %}
    HTML
{% endif %}

あと、変数が「あるかないか」とか配列が「あるかないか」とか配列の個数とか、その辺は「length」のフィルタ使ってチェックします。

{% if variable|length  %}

とか

{% if array|length  %}

とか。これは「戻り値が０なら、空文字(空配列)か存在しない変数のどちらかだからfalseになるよねぇ」って感じで使います。

反復

いわゆる「PHPのforeach」は、こんな風に。

{% for key, variable in array %}
  {{ key}}の値は{{ variable }}<br>
{% endfor %}

{% for variable in array %}
  値は{{ variable }}<br>
{% endfor %}

「for文で数値の反復」は、rangeを使います。

{% for i in range(0, 10) %}
  {{ i }}
{% endfor %}

また、ループでは「特別な変数」があって、それを使うと色々なことが出来ます。

loop.index  ループ数 1スタート(1 2 3 4 ...
loop.index0  ループ数 0からスタート(0 1 2 3 ...
loop.first 最初のアイテムならtrue
loop.last  最後のアイテムならtrue

変数の設定

あんまり使わん気もするが……どうしても「テンプレート内で変数を定義したい」場合は、こんな風に。

{% set variable = 'hogeramugera' %}

テンプレートの継承

{% extends 'layout.twig' %}

って書いておくと、継承してくれます。

あとは。継承元のファイルで

{% block XXXXXX %}{% endblock %}

って書いておいて、継承先のファイルで

{% block XXXXXX %}これを出力{% endblock %}

とかってやると変換してくれるので。
よくやるのが、headのtitleとかを

{% block title %}{% endblock %}

で宣言して継承先で

{% block title %}ほにゃららページ{% endblock %}

とかって使ったりします。

includeもあるんだけど、あんまり使わないなぁ。
使いたいときは

{% include "parts/include.twig" %}

とかって書式で。

大体、これくらいかなぁ。
過不足あったら、適宜修正していきまふ。

2019-03-17

フレームワークって「マシントレーニング」な側面があるよね

その他プログラミングフレームワーク

いやまぁ言いたいことはタイトルそのまんま、なのですが。
お題は「フレームワーク」。
見方を変えると「ライブラリとフレームワークの違い」の一端、かもしれない。

元ネタ
http://concierge.diet/column/leader/kawabe20151230

これが自重での筋トレですと、やるごとに負荷がかかる場所がズレたり、疲れてきて余計な動きが出てしまったりと安定しません。
-中略-
あとは安全性が高いのもマシーンのメリットですね。固定されているものなので、変な方向に動くことはないので。

元ネタの記事の趣旨からは結構おおきく大暴投している気がいたしまするが(笑
自重トレーニング、あるいはフリーウェイトと比較しての「マシントレーニング」が、フレームワークなんじゃないかなぁ、と思うのですね。

もうちょいとばかり技術的な側面からの発言だと、この辺が非常に得心のいくところですかね。
http://qiita.com/Jxck_/items/ec8e928f69d099b25764

Rails は、フレームワーク自体が単に機能を提供するだけでなく、Web アプリを開発する上での指針を示している。これはレールと呼ばれ、 Rails が敷いているレールにきちんと沿った開発をすることは、 Rails を使いこなす上では非常に重要になる。

Railsに限らず、基本的に「ほとんどのフレームワークが」このあたりの特徴を持っていると思うのです。
つまり「そのフレームワークが敷いたレールにきちんと沿うことが前提」。

http://concierge.diet/column/leader/kawabe20151230

このマシーンの正しい使い方も、トレーナーに指導してもらうべきですね。

にもある通り、「マシン(フレームワーク)を使ってれば無問題」では絶対になくて、そのマシン(フレームワーク)の「正しい*1使い方」を知り、或いは把握し、チームで共有する必要があるんですね。
後まぁ、そもそもとして「そのマシン(フレームワーク)は何を目指して作られているか、を知る事、とか(足を鍛えるためのマシンで胸筋鍛えても、色々と面倒なだけで効率が悪いものでございます)。

まぁ、フレームワークは「ある程度の、レールから外れた処理への許容度」というのがあるのですが、あんまり自由度が高すぎると「それはマシンいわんで、フリーウェイト言うんちゃうか？」という突っ込みが入ってくるので。
「レールへの強制度が高い」ほど、案件を選びますが、全体の粒度は割合とそろいやすい傾向にあると思います……あくまでも「傾向」程度、ですが。
んで、逆もしかり。「自由度が高い」フレームワークは、フリーウェイトっぽい作りになってたりしますが、その分「ある程度の自力が必要」なので、使う人を選ぶっちゃぁ選ぶ感じでしょうかねぇ*2。

まぁ、その辺は以前にも「■[親方]フレームワークの選定の仕方( https://gallu.hatenadiary.jp/entry/20120907/p1 )」で書いているのですが。

後、これ以外にも
http://concierge.diet/column/leader/kawabe20151230

トレーナーをつけることのメリットとして他にも、自分自身のカラダの特徴を客観的に知ることができるという点があります。

なんてお話があって、これなんかは、ソースコードレビューを彷彿とさせるものがあるように思うのは気のせいでしょうか？

「全く違う業界」のお話って、割とどこかで「通じるもの」があって面白いですよねぇ。
……………っつか、いい加減トレーニングしなきゃなぁ、とか思うのですが(……どっちかってぇと、リハビリな気もするが)。

*1:或いは、より好ましい言い方をするのであれば「適切な」

*2:MagicWeaponはもろにその系。Slimも割とそんな系統ですねぇ

2019-03-15

二種類の「死霊術」

中二ネタ堕ちゆく世界

専門以外からは一口に「死霊術」と呼ばれるこの系統は、ほぼ全く異なる２つの系統から成り立っている事を、本日は学んでいこう。
端的には「肉を扱う術式」と「魂を扱う術式」である。肉は「物質」、魂は「情報」と言い換えてもよい。
人によっては、前者を「死霊術」、後者を「降霊術」などと呼称するかもしれない。
本テキストでは、前者を「死術」、後者を「霊術」と呼称して、話を進める。

いわゆる「スケルトン / ゾンビ作成」などが死術の代表的な例である。
死術は、大まかには
・物質作成(または物質集約)
・物質編成
・魔力付与
・命令の埋め込み
の四段階で行われる。

いずれを作成するにしても、それは実際に存在するマテリアル(物質)であるために。
まずは、素材を「無から作成」または「周辺から集約」させる必要がある。
実際に「完全な無から作成する」のは些か難易度が高いため、一般的には「すべて周辺から集約する」または「核となるあたりを周辺から集約、残りを無から作成する」のが一般的である。
この「作成または集約」の時に、物質特性として「限定：死を連想するもの」という制約が(多くの術師に)ついているため、基本的には「死体」等からの作成しか、行うことができない。
また、腐肉がついていない骨だけの素材から「スケルトンは作成できるが、ゾンビは作成できない(難しい)」のも、「無からの物質作成の難易度」を示すわかりやすい指標である。
「レイス」などの「非実態 / 半実態」を作成する場合、核になるのは「空気中に散在している、死体を焼いたときの灰」である、と考えられている……が、実際にはほぼ「埃(ほこり)」であろう、と思われる。

作成または集約した「物質」は、編成によって「任意の形状」に組み立てられる。
死術において、基本的にここは「あまり色々な小細工を入れないところ」である事が多いため、ここについては「通り一辺倒の術式」である事が多い。
時々出てくる「犬の死体を３つ使ってスケルトンヘルハウンド(モドキ)を作る」などの場合は、この「編成」の術式に、それなりの工夫が見て取れる。
ただ、ここで「あまり無茶な形状」を作ると後々の性能に響くので、ここを扱う場合、基本的な生物学などを修めておいたほうがよいであろう。

「魔力付与」の段階で、特別な力を、くみ上げた物質に対して付与していく。
単純労働用のゾンビであれば多少の「筋力増強」くらいであろうし、レイスなどであればここで大量の付与をして、存分な能力増強をすることがよくある。
また、もし編成の時点で「武器や防具」などをくみ上げている場合、それらにも合わせて魔力が付与される事があり、この場合、単騎でもかなり強力な死体が出来上がる。

最後に「命令の埋め込み」によって、さまざまな命令に従わせる。
一般的なのは「作成術者の、簡単なワンワード(１語命令)に従え」である。柔軟性に欠けるが、最もよく使われる。
それであっても「基本的な動作」をすべて命令として埋め込む必要があるため、それなりに膨大な命令になる……ので、基本的には「特にアレンジをせずにそのまま、固定の命令(の塊)を埋め込む」事が多い*1。
そこから派生して、「作成術者以外に、選択されたこのメンバーの命令に従う」であるとか「多少の判断力がある」とか、逆に「固定の命令を埋め込まれて一切の変更を受け付けない」とか、そういったバリエーションが存在する。
それらのバリエーションの中に「ほぼ自由意思を持っているかのように振る舞う」高度な術式もあるが、基本的には「埋め込まれた命令にそって動いている」だけなので、自由意思を持っているように見える場合、それだけ複雑な命令が埋め込まれている、というのが実態である。
また、ここでもう１点、特殊な分岐が存在する。
それは「ベースになる素材の記憶を利用する」という術式の追加で、これは「霊術」の術式が絡むところになるが、これを使うと「プリセットにある単純な動作」ではなく「生前の、熟練した動作」を埋め込むことができるために、より強力な死体を作ることができるようになる。

この「命令の埋め込み」は、物質に固有の「色」が付くため、「破壊して新しい命令を埋め込む」のは、相応に難しい。
難易度的に「新しいモノを作る」ほうがはるかに容易であるため、「破壊して新しい命令を埋め込む」術式はあまり浸透していない、が、むろん、存在はしている。

なお「命令を全く埋め込んでいない」ものを「ブランク」と呼称する事があり。
あまりポピュラーなものではないが、一部「霊術も得手としていて、さらに命令埋め込みに特別のセンスがある術者がいる」ような時に
・ブランクまでを作る術者
・命令埋め込みに特化する術者
といった形で分業するケースが、全くないとは言わない。………まぁ「稀」ではあるが。

かように、死術とは言ってしまえば「ゴーレム作成の亜種」である。
そのため、術者の適正によっては「ゴーレム作成なども行えるようになる」ケースはそれなりに存在するし、あるいは「物質作成」「物質編成」「魔力付与」の系統が得手な場合、そちらの術式も相応に長ける、というケースはそれなりに存在する。

また。
これらの亜種として「大量のゾンビ(その他アンデッド群)がいると、そこからアンデッドが自然発生する」という事象が、一部で知られている。
この事象は、端的には「術式の共振」であり、つまり「そこに群がるアンデッドが作られた術式と同じような術式が、共振によって発生した結果、新たなアンデッドが作られていく」事になる。
この場合「魔力付与」と「命令の埋め込み」に比較的特徴があり、つまり「共振による」程度に「全体で共通の術式」が使われるため、あまり強力な魔力付与や特別な命令埋め込みは発生しない。
そのため、一般的に「低級(と呼ばれる)アンデッド」が発生する事が、圧倒的に多い。
また、高難易度のアンデッド生成の場合、術式がそもそも「外に漏れるほど非効率ではない＝共振しない」ので、「高級アンデッドの自然発生」は、そういった意味でも、まず発生し得ない。

一方で霊術は、端的には「死者(と認識されるもの)の情報」を扱う術式である。
比較的ポピュラーなあたりで「口寄せ」であるとか「死者からの情報の読み取り」といったものがソレにあたる。
一部で言われている「死霊術とは賢者の術である」といった類の呼称は、基本的に霊術を起点にした言い方であろう。

「死者」の定義が幾分難しいところではあるのだが。霊術においての「死者」とは、端的には「以降、情報の更新がないもの」を指す。
そして、霊術において「死者」とは本質的には「情報の塊」である。
記憶系の術式に長けているものにとっては常識なのだが、情報が「(突然)失われる」事は、なくはないが、基本的には「徐々に揮発していく」ものである。
そのため、多くの場合、ある程度までの過去の記憶であれば「適切にリンクをつなぎなおせば」大概の記憶を取り出すことが出来、どちらかというと「どこまで適切にリンクをつなぎなおせるか」のほうが、難易度が高い。
あとは「いつから揮発が始まり」「どれくらいで揮発するか」「揮発を食い止める、あるいは遅延させる手段はあるか」といったあたりがポイントになる。

揮発の始まりは、情報体が「生命活動を止めた」時、言い換えると「情報更新が停滞した瞬間」から始まる、と考えられる。
揮発の速度はなんとも言い難いが、弱いもので月単位から、強いものだと千年単位くらい、までの間で推移をしている。「通常の人間」であれば年単位程度、であろうか。
「揮発を食い止める、あるいは限りなく遅延させる」方法が、霊術には存在する。それが、霊術を使うものが「できるだけ新鮮な死者を欲する」理由の一旦である……最も、本当に「香一本が燃え尽きる」時間に拘泥する必要は、実際にはないのだが。

また、上述のゆえに、(特に人間の)死者はおおよそ「生前のあらゆる記憶」を、リンクの有無は別にして、保持している。
通常は適切に選択をした上澄みの情報を用いるが、その気になれば「ありとあらゆる生前のすべての、微細なものを含む情報」を得ることもできる。が、それはつまり「(極めて)短時間に、人生を１つ経験する」に等しい情報量になるため、やり方と術者の力量によっては、割と容易に廃人と化す。
そのため、例えば「口寄せ」の類であれば「言葉として表現できる」くらいにまで情報密度を下げることで、廃人と化すケースへの(簡単な)防御、としている。

ここで「魂」という問題にぶつかる。
「何をもって魂と呼ぶか」は、(信仰の拠り所などを一端置いておくと)非常に難しいのだが。
霊術を突き詰めていくと「情報の塊」が、そのまま「生物の魂」である可能性、にたどり着く。
つまり、霊術を突き詰めていくと。「死者の情報」だけでなく、「生者の情報」に対する読み取りや書き込みが出来る方向に進んでいく術式もあるのだ。

また「関わる様々な情報」の関連性を計算すると、「(多くの場合においては、基本的に割と短い)未来の予測」をすることが出来る方向の進化もある。
未来に行けば行くほど、計算の複雑度が加速度的に増すために、基本的に「あまり遠い未来」を占うのには適していないが。

一部「(生者に)死を与える(≒魂を抜き取る)」や「魂を吸い取る」といった類いの術式を連想するケースがある、が、これについての分類は、もう少し細かい理解が必要となる。
「死を与える(≒魂を抜き取る)」場合、これは単純に「対象に"現象としての死"を与える」ような術式であり。
この場合「生者に」であれば、それは「生命系の術式の一種」と見なすことが出来るので、本質的にはそもそも死霊術ではない(それっぽくはあるが)。
近似の術式として「無機物に死を与える」ようなものもあるが、多くの場合においてこれは単純に「物質を劣化させる」という、物質操作の一種になるので、ギリギリ、死術に近しいものではある、が、術式構成はかなり異なる。

一方で「魂を吸い取る」と評される術式のコアは基本的に「抜き出した魂を使って何かをする」であり、これはつまり「対象の情報を抜き取ってどうにかする」術式であるために、こちらの構成は霊術と近似になる。

これら以外にも、一般に「死霊術"とされる"」術は多々存在するが。
死霊術は、まず大きく2種類(「物質を操る死術」と「情報を操る霊術」)が存在し、またそこからの分岐や亜種が諸々に存在している。
また同様に「一般に"死霊術とされる"が、実際には死霊術に属さない術式」も、少なからず存在している。

勿論それら「全て」を修めるという目標も興味深くはあるが、まずは1系統、自分が「最も馴染む」系統を深く学んでみるのもよいのではなかろうか。

本文は、そんな「未来の学徒」達に捧げよう。

*1:このあたりは、興味があれば「プリセットプログラム紅殻のパンドラ」で調べるとよいだろう

2019-02-26

「平和な時」こそが「戦争」の「本番」だ

親方

いやまぁ色々とそのまんまど真ん中なのですが。
元ネタはこちら。

魔法少女プリティ☆ベル 24 (BLADE COMICS)

作者: KAKERU
出版社/メーカー: マッグガーデン
発売日: 2018/02/10
メディア: コミック
この商品を含むブログを見る

P17～19

だが残念
「有事」の勝敗は
「平和な平時」に
決まるのさ
「平時の準備」が
「本番」だ
ああ…
何度でも何度でも自戒し
繰り返すべき言葉だ
本当に本当に
忘れがちだからだ
びっくりするほど
すぐに忘れちまうからだ
「平和な時」こそが
「戦争」の「本番」だ
やべぇとなってから
慌ててももう遅いんだ
「もう遅い」
んだよ

これはまぁ戦争(大規模バトル)のお話なのですが。
これ、このまんま「技術の世界」でも通用します。

「平時の準備」である勉強をしておかないと、「本番」である何かがあったとき、には「もう遅い」となります。
「何かがあった時」に、そこから初めて「調べて、必要な前提を学んで、さらにその前提を咀嚼して」とかやってる時間は、まぁ、ないです。………そもそも「学ぶ必要性」とか「調べる必要性」に気づけなければそれまでですしねぇ*1。

なので。「平時の準備」としての、特に基礎系の勉強は色々と不可欠なのですが。
まぁその辺はつい「後で」「必要になったら」としてしまった瞬間から「もう遅い」に片足を突っ込みます。

でも、何割かは負けても「運が悪かった」「相手が悪かった」「案件が悪かった」「相性が悪かった」で片付けてしまって、準備不足に気づかないし気づけない。
下手をすると「負けたことにすら気づかないし気づけない」。

ある程度のキャリアを積んだエンジニアが「学習を継続する」理由とか、この辺が一番、骨身に染みる所なんじゃないですかねぇ？
とか思うんですが、どうなんでしょ？？

*1:例：脆弱な実装