「はしれ！コード学園」って？

自動車弄りネタではないです。

趣味ネタではないです。どちらかというと私の職業ネタです。

でも、仕事のことを云々というものではありません。

 

なつかしい知人からメールが来た。

要約したら、「これ見て味噌。なつかしい地獄の日々を思い出すでー」という内容です。

で、そのメールに記されていたURLがコレです。

「はしれ！コード学園」 https://codeiq.jp/magazine/2015/11/34020/

タイトルより、コンピューター業界ネタなのは直観でわかります。

でもね、「走れ」なのかい？どちらかというと、「こけるコード事故」みたいな感じで悪いタイトルをつけるのが関西人なのですが、このホームページ作者は前向きってことでしょう。

で、そのリンク先を見たら...

はは～っ。スパゲティーコードかー。と懐かしくなります。

ふむふむ。内容的にはおおむね共感。なんだけど、最後がお化けのオチなのが....

って、お化けのことを詳しく書いていないが、誰も想像できない挙動不審な動作をするロジックが生まれているという解釈でいいのでしょうか？

たしかに、そういうものを作成してサジを投げたシステムが私のところへ特急仕事で舞い込んだことがありますが....

それよりも、私的には、スパゲティーコードは、「パッチ」というブイヨンを投入することで、さらに濃厚になる。

そして、皆して、「書いちゃダメ、書いちゃダメ、書かずにパッチ」と大声で歌うのです。

これの語源は、「掻いちゃダメ、掻いちゃダメ、掻かずにパッチ」という虫刺されの懐かしいCMです。

そのCMがリアルでTVに流れていた時代に私は廃人になって人様の尻吹きシステム強制稼働の仕事についてました。

もちろん、先のリンク先にあったスパゲティーコードです。すべての要件が盛り込まれてました。

その会社の元受けは某大手系列でして、まさに「不治痛」でした。それをユーザーが日立さんなんとかなりませんか？という遠回しでめぐってきたものです。

大手は実は裏で仕事のなすりあいをしているのはいつの時代も一緒でして、スパゲティーを投げつけてきたのです。

そして、私は、まばゆい「コード銀座」に埋もれていき、「スパゲティーの悟り」を見出し麺を打ち直すのです。

あーっ。あのころが懐かしいなー。チーム全員で廃人を楽しんだなー。と、知人のメールをきっかけに黄昏てしまったではないか。

そうそう、「はしれコード学園」に出ていた「命名規則に則っていない変数名」ですが....

あからさまに変数らしければいいのですが、私が遭遇した中で一生忘れないであろうもの....

それは、変数名に女性の名前が多様されているソースに出くわしたことです。

変数名が女性の名前って？想像できます？

一応、命名規則はあったのですが....

int nAkiko;

int nKyoko;

struct strBeppin {

    char *cpKirenagaMatsuge;

    char *cpKirakiraHitomi;

    char *cpPukuriHana;

    int    nAhiruKuchi;

};

ってこんな感じです。こんなのが一杯あって...

この変数名で中身に何が入るか判断できますか？

さらに関数名も....

BOOL　IsFuroNiIssoniHiru( int *npOnna, char *szOnsenName) ;

BOOL IsSexHappy ( 引数は書くのもおぞましいので控えます );

こんなソースが出てきたらどう思います。

それを引き継いでスパゲティーを解き直せというのですよ。

それが、某大手メーカーソフト屋がサジをなげたシステムでした。

これでも、ソースの流れ的にストーリーができていれば、この設計者は達人かも？と感心するのですが、達人がこんな変数名で遊ぶことはしません。達人は必ずソースにポリシーがあり美意識が徹底しているものです。

ともかく真面目にソースを見たのですが、フローを図面に起こしても、goto GoOkasu(); とか、そんなのを書き起こしていたら、どうなん？なんなん？システム要件が浮き上がりませんでした。

全体的な顧客要求の、この部分を実装しているのだろうなというのはわかっても作りこみの理念が解読不能でした。だってGoto多発のソースって、あんたBasicか？とつっこみたくなります。いやいやVBとかなら曲がりなりにも構造化されているので、それ以前の思考で祝詞のようなロジックでした。

で、私は顧客へ出向いて、再度仕様を確認して、一からソースの書き直ししましたよ。

一からソースを書きなおすと、それだけ結合テストのやり直しが出るのですが、それでもお化けが出現するより最終完成度が高くなるというものです。

こんなソースがまかり通っているから、それを修正する人がどんどんこんがらがってダメダメなスパケティーへ....

そんなスパゲティーを作るなら、臭い箇所だけパッチ修正で逃げた方がシステム的には良かったりするんですよね。

パッチもソースを触るのではなく、ソースの上にかぶせるのですよ。まぁー、そこはある意味禁句なのですが....クラス継承して臭いところを捨ててやれとか。ヘッダーファイルに#defineでえげつないことを書いてしまうとか....

注意：

機能を殺すための多重継承、ヘッダに#defineで置換ロジックを埋め込むなんてことは、ロジック書きを生業にしている方は絶対にしたらダメですよ。それって狂気の沙汰です。でもシステムをごそって変えるスイッチングのテクニックでもあります。

ということは、バグ修正でこの手法を用いるというのは、システムをごそっと変えている。前システムの一部ソースが物理ロジックではなく仮想ロジックとして流用されるということ。

こんな修正したら、次にスパケディを味わう人が、その深みにたどり着けれるほどの繊細な舌を持っていないと大変なことになります。

もちろん次の人がメンテするときに困らないようにソースにはコメントしておくのですよ。

「スパケティー過ぎて美味しくないので食あたりしました。ついてはヘッダーにパッチを食らわして虚飾しております。まずはパッチを見て酷い前任者だとけなしてください。そして腹下ししてください。」

こういうコメントをしてとりあえず逃げるというのもありました。でも、そのつけが必ずあるもので、腐ったスパゲティーソースは必ず麺の打ち直しからしないと美味にはならないのです。

こればかりは、納期と予算でどうするかの判断になります。

腐ったスパゲティーがたらいまわしされるときは、必ず納期が緊急事態なんです。

その納期に向かって特急料金を出せる顧客は、達人SEチームに渡り一から再構築されます。でも大抵は、恥の上塗りごまかしソース書き足しにされるのよねー。そういう恥の上塗り仕事を「不毛な仕事」っていうのよねー。

って、これがこの業界の悪しきしきたりなのよねー。

と、知人のメールからくだらないことを感想してブログに書きました。