熱脳しゃちょのブログ -11ページ目

熱脳しゃちょのブログ

おせっかい焼SE兼プログラマ兼……の辛い日々と、思う事なぞ

歴史的に古くて小さいリソースでしか動かない、逆に時代が下ってふんだんなリソースをフル活用できるようになったおかげで新しく作られた、という発生時の環境によってできること、やらなきゃいけないことが増えたから。

なら、古くて小さいリソースのプログラムなんていらんだろうって?

蚊を殺すのに、ツァーリーボンバーを持ち出すアホウはおらんのだよ。

 

あとは、同時代に生まれても、必要な、と言うか中心的な抽象レベルが異なるために、「理解できないエンジニアには使えない」って言語もある。

適切に抽象化ができるエンジニアは、リーナストーバルスもいうように、エレガントに問題を解決できるし、そのために都合がいい機能を持った言語を使う。そうでなければ物量(if文満載の)で一旦動くものを作ろうとして、自分の理解が及ぶ範囲でできることが用意されている言語を使う。

例えばオブジェクト指向プログラミングとか理解できない使えないエンジニアは意外と存在する、とかね。

 

ワンフィッツオール、なんてありえないくらい裾野というか、版図が広がったシステムの世界だから、プログラム言語の種類は多い。

プレゼンテーション(表示/UI/UX)や構造(ネットワーク、サーバサイド)のような対象によって、規模や(ビジネス)ロジックの複雑度の大中小で使い分けるのが普通だから。

 

Rustもいい言語だし、でも複雑でデカいビジネスロジックのシステムだったら、複数人で回すのちょっときついな、と思うし。仕様駆動開発で、ってのは、CRUD的で単純なサービス、あるいは初期段階ならいけると思うけど、成長に耐えられる気がしない。かなりのプロダクトで、作って動いてるところは変更するな、ってなりそう。

PHPは、言語自体は軽量で悪くはないんだけど、toBサービスでこれを育ててデカくする、のは限りなく不可能だと思う。デカくなる前に言語を移行するとか考えないと(やり方はある。けど、多分PHP使いはそれを思いつかないし、やり通すことができない)。

golangは……、使い方、使い手による……。

 

スマホなどのネイティブアプリは選択肢がない。

全部の端末を1ソースで対応可能! みたいなのもあるけど、当然失うものもあるし、それはデカかったりする。

おいらは嫌だ。

いままでどれほど騙されてきたか w

スタート時はね、いい感じに動くんだよ。

そう作られてるから。

でも1年、2年と経ってくると、それぞれの環境間の差が広がりまくりすぎて、辻褄合わせの時間が50%を超えてくる。

それを見越した設計実装ができる人もいるけど、むちゃくちゃ少ない。

 

どんなプログラムも、デカくしすぎないで、移行可能に作っておくしか、時代の変化についていけない。
それは工学の基本中の基本である「分割統治」の考え方そのものなんだよね。

「必要」は「大抵の場合は」ない。

 

ただ、エンジニアの足切りの要素が高い(対応できないエンジニアは排除される)ので、PHPに比べればカオス感は激減する。



ってのはあまりにも希望的観測か? w

 

 

golangは、PHPの次のお手軽な乗り換え先になっていて、ほぼPHPみたいな使われ方してて、(ー_ー;)ってなることがしばしばある。
golangに乗り換えられないPHPer様の……、はあまり考えたくない。

障害が発生したり、要件が追加されるたびに、関係する処理だけを順方向に追っかけて、「ここに if 文追加するだけで対応できます」みたいなアドホックな修正が積み上がってる上に、自動テスト無し。
なんてことない、ポツンと一軒家的な、一見周囲から孤立しているようにしか見えない if 文の有無が、致命的な障害発生を抑制していたりして、マジ怖い。

赤のコードか、青のコードか、みたいに見せておいて、黒い隠しコードみたいなのが、ぽんぽん現れるんだよな。

しかも最近は AI 乱舞とか。

 

 

君は生き延びることができるか?

 

 

マジで関係者、この大変さ全く理解できてねぇのよな。

「え〜? 今動いてるのに、なんでそんなにお金かかるの?」

 

あのね、今動いてるから大変なんだよ。


返事次第では手を引いていいっすか?

 

おいら的には、生成AIでプログラミングってのは、手で手術した方が正確なのにこのダビンチってロボットを無理ぐり声で操作して脳外科手術するようなものに思える。

コードは大量に生成できるかもしれないけど、せいぜい盲腸で使うくらいだと思う。

 

 

実際、仕様駆動開発っぽいのを見てみたんだが、この仕様で大丈夫なん? という気にはなった。

その仕様自体も、なんか生成AIに作らせたみたいな感じだし。

仕様だけ見れば落第点ではないんだが、利用者とかデータが増えたら破綻しそうだなぁ、とか。

利用者とかデータが増えたら、その仕様書を書き換えれば、移行から何から何まで、生成AIで面倒見てくれんのかなぁ? とか。

何より、その生成AIに頼り切ってるエンジニアしかいない状態で、何かあった時に対応できんのか? とか。

 

まぁ、現状で満足してるなら、エンジニア経営者とも、まぁ、いいんじゃない? とは思うけど。

やっぱりコード量が尋常じゃないから、これをなんとかしてくれと言われても、なんともしようがないよ?

経営者さん、それでも大丈夫?