ソースを読んで、図を書いて、理解はできるだろうと思うのだが……。
もちろん、ソースをずるずると読み進めれば理解できる古のフローチャート風のソースではなく、リアクティブというかそれぞれのオブジェクトがお互いにメッセージを送り合う的な、近代的(といっても、この概念自体は結構古い)な物ではある。
かなりわかりやすく書き下していると思うんだけど。
20年ほど前のプログラミングスタイルで、今時のベンチャーのシステムを組んで、太刀打ちできると思っているんだろうか……？
一応、勉強したいという人には説明しているし、若い子はある程度は理解できるよう育ち始めてもいるけど、頭が古いのが幹部候補でぽろぽろ降ってきて、暇を持て余しているのか集まって会議会議会議で的外れな方針決めて盛り上がってるっぽい。
ようやくシステム自体は安定したというのに、また不安定になってき始めてる……。
まだお金を引っ張ってくる気満々らしく、数字も無理やり作るんだろうけど、その反動でますます追い詰められちゃうんだよな。
利用料金はどんどん上がるけど、それに見合ったリターンをクライアントに提供できてないのが問題なのに、利益につながりそうにない新機能ばかり実装させようとする。
もう、ダメかもしれんねぇ……。
勉強熱心な若い技術者の熱意で残ってるけど、これ以上利用されそうにないシステムに労力を割くのもなぁ……。
と思う、今日この頃。
メインの処理はビッグデータで、去年、あまりに処理が遅いっていうんでSparkを紹介したんだけど、自力でやる(というか、当時は自分が担当するシステムがヤバすぎて、データ処理にまで手を回せないし、そもそも契約範囲外でもあった)ってんで出てきたものが 自称天才 SQLer & pythonian(SQL文に関しては右に出るものはいないと自負しています、って真顔で言われたのはびっくりした) 作成の……pySpark……。
いや、やらせてるんなら言ってくれれば、いくらでも助言はできたのに、Sparkにしてはとても非効率なプログラムになっとった。
データの軸が3つ(以上)あるのだが、1キーでオートパーティション & リパーティーションでやるもんだから、時間がかかってかかってしょうがない。
データが2倍、3倍となったら処理時間はそれではきかないほど増える。
ある規模を超えた途端、10倍とか跳ね上がる(はず)。
以前よりはかなりマシにはなっているけど、次の増資、借入時に必要とされる条件を満たせるほどのデータを回そうとすると……、札束勝負になって力尽きる可能性が高いし、札束積んでも回らないかもしれない。
今から再構築、と言っても間に合わないくらいでかいシステムに育っているっぽくて、手を出せないし、どうもこの辺りの危機感をこれっぽっちも感じていないらしく、オイラの言うことがひたすら「余計なこと」に映るらしい。
去年のオイラの助言や説得でやることにした対策をしていなければ、今でも動作は安定しないで、日次バッチは1日で終わらないなんてドボン状態になってたんだが(タイミング的には本当にギリギリだった)。
まぁ、所詮その程度の会社、ってことなのかもしれない。
そろそろ潮時なんだろうな。