ありそうだから怖いｗ
日経に「スパゲティコード」というワードが出たので明日以降、意味も分からず
— よんてんごP (@yontengoP) 2023年8月3日
「オイ‼弊社にもスパゲティコードはあるのか‼」
「すぐにスパゲティをヤメろ‼2週間でやれ‼」
などの指示が飛ぶことになります
マイナンバー証明書誤交付、裏に「富士通のスパゲティコード」https://t.co/qpWGqX23ll
まあスパゲティコードは多分あるよ。
記事はこちら。無料部分だとスパゲティコードに辿り着かないので会員部分から引用。
誤交付は8つの自治体で発生した。富士通製システムには複数の利用者からの申請が重なると、印刷の順番を取り違えるという欠陥があった。
IT技術者の会合では富士通製システムの複雑さが関心を集めた。「まさにスパゲティコードだ」。立命館大学教授の上原哲太郎は、命令処理の流れが麺のように絡み合って不良が起きても把握がしにくいプログラムだと指摘する。
国の指示で富士通は123自治体のシステムを総点検した。コンビニ交付システムを手掛ける約50社も点検を指示され、業界全体に動揺が広がった。
太字化はオレ。なお、このIT技術者の会合、記事からはどのようなIT技術者の会合なのかは読み取れない。どこの誰が集まったんだよ。なんで敬称無し？氏くらい付けないか？上原先生はコード見たの？見せてくれるの富士通Japan？
記事に文句付けてる上原先生のツイート見つけた。
私がスパゲティとしたのはコードじゃなくロジック。後から現場要求に応じ機能追加→追加部分の担当者は競合が起きる場所を適切にロックしないといけない→それが徹底できずにバグる。当初の逐次設計が破綻してた。 / “マイナンバー証明書誤交付、裏に「富士通のスパゲティ…” https://t.co/pxmauxYF7Z
— 上原 哲太郎/Tetsu. Uehara (@tetsutalow) 2023年8月3日
なんだこれならニュースになってた他人の奴が出ちゃう件そのものじゃん。ロックのミス。
でもそれスパゲティって言っちゃうと、どちらが書いた記事かわかんないけど経済が苦手な日本経済新聞社や、IT苦手な人がIT系の雑誌・Webを担当し、ビジネス苦手な人が日経ビジネス担当する日経BPの人はスパゲティ＝スパゲティコードだ！になるって。
上原先生お怒りのようですけど、適切な単語を選択しなかったあなたも悪い。
昔はてなハイクのメール投稿の件で書いたけど、適切にロック掛けないとダメなんだよ。
複数の処理キューで処理するのは性能を考慮すれば当然。アプリを複数サーバにスケールアウトした構成なら当然こうなる。であれば結果はFIFOにならない可能性があるので、後続の処理もFIFOを前提としてはいけない。ハイクのメール投稿作った奴はACID特性を知らないんだろうな。ダサい。
金融機関システムでACID無視してシステム作って、結果が変になる事象が頻発したらその金融機関潰れるぞｗ
多分富士通Japanの担当者はACID特性知らんかったんだろ、公共分野だしな。特にIsolation”（独立性/隔離性）。仕事なんだから、知っててもできなかったらバカだし。いや、知らないほうがバカか？どちらかの2択。
当初の逐次設計が破綻してた。
まあ、これでしょ。ハイクのメール投稿と同じ。中間の処理がFIFOにならないのに、終端の処理をFIFO前提で組むから他人の証明書が出ちゃう。
件の誤発行、コンビニ複合機に証明書データを降ろすのに掛かる時間からすれば、他人の証明書発行ミスを無くすために確認用データを増やすとか、確認トランザクション追加するとかの数ミリSec、誤差の範囲じゃん。きちんと全体の設計し直すことができるタイミングでもないし、それで逃げるしかないだろ。
ここからようやくタイトルの話。ここまでで1エントリでも良かったｗ
Bing Image Creatorで生成
今までに何度か書いているが、新卒で就職して最初の配属部署は3月末までの期間限定で汎用機のCOBOLコンパイラ屋だった。SE部門に配属予定でプログラマ部署に実習という形態である。
最初は担当機能があったんだけど、大雑把に言えばオレが所属している間にそんなに変更が入らないって話になって(今でも真偽は分かってない)、途中から事故対策担当兼雑用担当になった。半年以上は担当したと思う。
事故対の仕事は、コンパイラの不具合なのかコンパイラは悪くないのかの切り分けを行うことだった。いろんな顧客担当SEから「このCOBOLプログラムが異常終了する／所定の動作をしない／コンパイルが通らない」とその顧客のプログラムが送られてくる。そのソースコードを読んだり、実際にコンパイルしてみたり、動作させたりして確認する。ほとんどは実行環境を作れない(ミドルウェアが無いとかデータが無いとか)ので、動作させることはほぼできないという縛りがある。
ほとんどはコンパイラ側には瑕疵はなく、でもそれならどうしてコケたり動作不良だったりするの？って話になるわけで、なぜかオレがデバッグしたりしてた。コケるケースは互換機だったけどコレの0C1か0C4か0C7。
大抵は呼び出し側と呼ばれる側で確保しているデータ領域のサイズが違う。データ長を比べていけば大体合ってない。呼んだ時あるいは呼ばれた時に変なデータを受けたり、変な動きをしたり、領域を壊したりして異常終了する。
結果不正とかはほとんどコーディングミス。たまに本当にコンパイラがミスって変なオブジェクトを生成している場合があるけど。
コンパイル通らないのは、大体ほとんどコーディングミス。見た目だけだとすごくわかりにくいコーディングミスはスペースに漢字が使われている場合。でもこれはすぐにメッセージでわかる。
結局、担当していた数か月間でコンパイラ側の不具合だったケースは5件も無かったと思う。半年以上、先輩とオレが普通に日々稼働する程度には案件が持ち込まれていたけど。
八割がたのソースコードは読むのに苦労しなかったのだが、残りの二割が凄かった。まさにスパゲティコードである。構造化が入る前の当時のBASICみたいにGOTOで飛びまくる奴が。COBOLにもGOTO文はあるんだけど基本的に使わない。サブルーチンは独立して書いておいてPERFORM文で呼べばいい。普通にロジックを考えればGOTOが必要になる局面が無い。GOTOで飛んだ先からまた別のところに飛ぶとか、さらに元に戻るように飛ぶとか、書いた奴はあたまおかしい。10年以上のビンテージもののソースコードが多かった。
![ラダチーニ ラダチーニ ヴィンテージ カベルネ・ソーヴィニヨン 瓶 [ 赤ワイン ミディアムボディ モルドバ 750ml ]](https://m.media-amazon.com/images/I/31S3zfObcBL._SL500_.jpg "ラダチーニ ラダチーニ ヴィンテージ カベルネ・ソーヴィニヨン 瓶 [ 赤ワイン ミディアムボディ モルドバ 750ml ]")
あと、ある変数を色んなことに使いまわしてたりもあった。COBOLにはローカル変数って概念無かった(COBOL2002ではあるの？)ので、1コンパイル単位で変数使いまわしたら、そりゃ予期せぬ結果になることもある。手抜きしないで変数定義すりゃいいのに。
ここまではやってた作業の概況。
思い出なのは、顧客側の細かいコードの内容は覚えてないけど漢字関係。オレが担当していた当時はCOBOLのコンパイラそのものは2バイトコードの日本語が扱えず、2バイトコード文字を1バイトコードに置き換えるプリコンパイラで変換してからコンパイルする。プリコンパイラもCOBOLの構文を読んで、データの中とコメントだけを置き換える。変数名には使えない仕様だったのでその時はエラーで返す。
持ち込まれたのは、プリコンパイラがマニュアルに載ってない変なエラーを吐いて通らないというもの。しかも、プログラム改造する前までは通っていたらしい。持ち込まれたソースコードはいわゆるスパゲティコードで、追いかけるのは大変だった。でも、どんなに見ても、プリコンパイラを通すという意味では悪いところが分からない。2バイトコードを1バイトに置き換えてコンパイルを通してもみても、コンパイラは普通に問題無くコンパイルできる。1バイトコードに置き換えるのは、プリコンパイラと同じことするのは大変なので適当に置き換えた。
じゃあ、プリコンパイラかもってことで課長に報告すると、(固定で決めていないという意味で)担当者いないから、お前がプリコンパイラ追えと。しかもそのプリコンパイラ、所属部署で作ったものではなく、親会社の担当部署から担当替えになったものだった。ということで、先輩たちも中身見たことある人がいない＼(^o^)／
そもそもいつもは先輩と一緒にやってて、直の主任もいてコンパイラに問題がありそうな時はそれぞれの担当主任に話してって感じなのに、なぜか急に課長直轄案件に。
そのプリコンパイラの開発言語はアセンブラと、PL/Iを改造して中にアセンブラを書けるように改造した社内専用の謎言語。オレ、その時初めてPL/I見た。PL/Iもどきだけど。
新しいプログラミングの基礎なのに1971年か。まあこういう言語ですよ。
大学時代は1年生から演習や自分のポケコンでBASIC、なんかFORTRANも2年生にやった気がする。多分捨てたけど大学で教科書として買った本持ってたし。でもFORTRANだけは今の今までずーっとわからん。他の言語は初見でも読めるのに。
大学4年で卒業研究のためにC。前にも書いた気がするけど、小田急線の中で書店で購入したはじめてのCを見てて、女子高生の刺すような視線を感じて「あ、このタイトルか」っていうミスをした。それ以来、本にはカバーを掛ける習慣が。
会社に入って新人の集合研修の時にアセンブラとPASCAL。COBOLのコンパイラ屋に配属されて最初の担当部分もPASCALで記述されてた。そしてCOBOL屋なのでCOBOLは当然覚えた。しかし、PL/Iは初。しかもPL/Iもどき。
製品PL/Iのマニュアルはあるんだけど、社内用の謎言語なのでちゃんとしたマニュアルさえない。まあ、アセンブラは分かるしPL/Iも難しい言語ではないので、言語仕様知らないけどなんとかプリコンパイラをデバッグしていく。あ、一応仕様書はあったよ。どこが悪いか当たり付けるのにはあまり役に立たなかったけど。
さすがにプログラミング言語屋が書いたプログラムなのでソースコードそのものはきれいで分かりやすいんだけど、急にアセンブラになったりするのでスパゲティコードっていうよりチーズインハンバーグみたいな感じ。
結局チーズ、じゃなかったアセンブラ部分に問題を発見。
前はプリコンパイラ通っていたのに、改造したら通らなくなった理由は分かった。確か支店ごとにサブルーチン分けしてて、その数が支店数増でプリコンパイラ想定値を超えたのでプリコンパイラがエラー吐いていたのだった。ここまでプリコンパイラのソース見始めて2日目の昼。
SEから送られたソースコードは、オレがプログラミングしたらそもそもそんな作りにしないんだけどな、コード量2/3で済むしって思った記憶は残っているぐらいのクソプログラム。多くの言語にあるいわゆるforループにすればこんなことになってなかった。
課長に報告して「プリコンパイラを修正しますか？」って聞いたら「やらんでいい」と。次バージョンの開発がすでに始まっていたのだが、そのバージョンはCOBOL85をサポートし、2バイトコードもプリコンパイラ無しで扱えるようになる って2バイトコードの話はその時初めて聞いた。直すのはちょっとリテラルで書かれた数字を増やすだけなので簡単だったんだけど。
結局「プリコンパイラの仕様です」だと問題解決しないので、「こんな感じに直すとプリコンパイラ通りますよ」ってクソプログラミング解消案を担当SEに投げ返した。結構工数掛かった。
プリコンパイラ修正するだけなら秒でできるんだけど、それをテストして検査部門に送って、リリースノート作って、出荷用媒体の元ネタ作ってとか、製品プログラムのバージョンアップはクソプログラミング解消案を出すより結構大変なので、課長の言う通り「やらんでいい」が正しかった。検査部門に送る以降はほとんどオレの雑用担当としての作業範囲。
この1年目のスパゲティコード経験はあとですごく生きた。大型汎用機を使う金融機関担当だとプログラム読めるSE少なかったし。異動後顧客先の証券会社でもイヤってほどスパゲティコード見たし直した。今は亡き損保会社でも見たし、某国の郵便貯金システム開発でもプログラマにデバッグ方法教えたりしてた。
ということで、スパゲティコードの思い出というより、どちらかというとチーズインハンバーグの思い出だった。
夏場はこれ。茹で時間短いから、エアコン掛けながら茹で作業で部屋を暖めてしまうことも少なくなる。
