ソフトウェア開発ってなんだっけ？
世の中には、ソフトウェア開発という業務が存在するらしい。
ソフトウェア開発という現場に就職して、様々なシステムを立ち上げてきた。
サーバークライアントソフトウェアの現場から離れて、組み込みソフトウェアの世界に来てからも、沢山のソフトウェア開発をしてきました。
既に遠い過去の記憶です。
今やっていることは一体何だろう？
過去に誰かが置き去りにしたソフトウェアが世界中にバラまかれてしまっていて、その担当者は既に不在。常に顧客からのクレーム。
クレームになんとか対応し、謎のソフトウェアを修正してリリースする。
別の不具合が発生し、再炎上。
火消しする。
また別の不具合が発生する。
火消しする。
顧客いい加減キレル。
ソースコードの再点検祭。
FTAする。
なぜなぜする。
修正してリリースする。
謎の起爆剤が爆発、再々炎上。
謝る。
修正して、リリースする。
もう不具合はありませんと報告する。
かなりのレアケースでフリーズする。
謝る。
別のレアケースでリブートする。
謝る。
顧客、再び逆上する。
（永遠続く）
大多数のエンジニアは耐えられなくなって辞めていく。
残された少人数で対応する。
なんだろうか、このミラクルな箱は。
どれだけの不具合を生み続けるのだろうか？
捨ててくれ。
どうやったら品質改善するのかと顧客から問われる。
こっちが教えてほしい。
ここまで不具合が収束しない魔法の箱は、逆にスゴイものだ。
どうやったら、こんなに不具合を生み続けるソフトウェアを作れるのかを教えて欲しい。
設計書も無い。コードを見ても何がしたくて作ったのかもわからない。
しかし、なんとなく動いてしまっている。
この箱は、人類が滅亡するまで、不具合を生み続けることだろう。
マジカルボックスの作り方
さて、このミラクルボックスの作り方が、最近だんだんわかってきた。
本日は、作り方を皆さんに伝授しましょう。
- まずは、なんとなく作りたいもののコーディングをしてみます。適量としては１００万ステップくらいのものが理想的です。
- できるだけマルチスレッドの処理にします。３０スレッドくらいを組み合わせて処理を実現しておきましょう。
- 関数はシンプルに作成してはいけません。一関数のステップ数は１０００ステップ程度が良いです。ネストの深さは１０段以上となるように心がけましょう。また、可変引数、自己参照関数などは程よく組み合わせて使いましょう。
- 大事な変数はグローバルに配置します。グローバル変数を設定・参照する共通関数をたくさん作っておきます。どこでグローバル変数を参照しているのかは、できる限りわからなくしておくことがコツです。
- ある程度つくったところで、コンパイルしてみます。
- エラーや、ワーニングが多発すると思いますが、残しておいてはいけません。
- 処理があっているかどうかは、二の次でエラー、ワーニングがでないように隠蔽しましょう。変数の型があっていなければ、キャストすることでワーニングは消えます。
これで、下ごしらえができました。
次は、顧客のよくわからない要求仕様をもらいます。
- この要求仕様を実現するために、下ごしらえの終わったものを利用して改造してみましょう。これで、元あったステップ数から１００万ステップくらい増やすようにします。足りなければどんな処理でも大丈夫です。同じ意味のIF文を別の表現で表してみましょう。同じ処理でも、違う書き方がいろいろとできるので試してみましょう。それでステップ数はある程度稼げます。
- よくわからない仕様ですから、細かいことは気にしてはいけません。なんとなく動いていれば満足する人が居ます。
- 突然うごかなくなったときは、なんとなく動いているところからコードももってくれば治ります。細かいことは気にせず、パッチ当てしましょう。
最後に、顧客から、さらに良くわからない追加仕様をもらいます。できるだけ多く小出しにもらいましょう。
- 先にもらっている要求仕様と矛盾を感じても、人間誰しも間違いはあるものです。そこは落ち着いて、決して作り直すのではなく、いままで作ってきた部品を組み合わせて、動いている風にみせましょう。
- すべての作業が終わったところで、３００万ステップくらいになっていれば完璧です。
これで、一旦リリース準備完了ですが、まだリリースはしてはいけません。
仕上げです。
- 一個目の箱を利用して、少し内容変更していくつかのバリエーションを作成します。
- 変更内容はできるだけ一つのコードに留まらない修正の方が効果的です。共通関数の処理から、できるだけ関係性の低そうな共通関数を読んでみたり、グローバル変数のサイズを変えてみたりしましょう。
- こういったバリエーショの違いを複数本用意しておきます。
さぁ、無限に不具合を生み出し続けることのできるマジカルボックスの完成です。
一斉に世界中にバラ撒きましょう。
いつでもどこでも何かが起きるワクワク感。
常に新しい発見と出会いが得られます。
もうムリぽ。
永遠このソフトウェアと付き合い続ける覚悟なんか無い。
作った奴らは、もう居ない。
居たとしても、後の祭り。そいつらに、この魔法の箱は閉じれない。
C言語は、使う人によっては凶器になるのです。
そこにマルチスレッドをわかっていない人のスキルを混ぜると、可能性は無限大に広がります。
自分の作っている処理がどのスレッドで動くかどうかを気にしたら負け。そんな職場風土作りをしましょう。
エンジニアに時間を与えてしまうと学習するので、できるだけ考える時間を与えないように納期の設定をしてあげることが重要です。
設計ってコーディングだと思っている程度くらいが丁度良い感じになります。
まとまらない
どうしたら良いと思います？
なぜ？なぜ？って考えたところで、過去に仕込んだマジカルボックスの蓋は開いてしまっている訳だし。
静的解析TOOLにかけようものなら、すべてのパターンの警告が、参考書の実例のように次から次へと表示されます。コードの行数以上に警告行がありそうです。
これだけの警告パターンの実例を同時に見れるのは貴重です。参考書いらず。
しかも、こんな状況なのに、不具合が収束しないのはプロセスが悪いんだとか、訳のわからないことを言って仕事増やす人がいます。もう意味わからない。
ソフトウェア開発の現場に行く方は、気をつけてください。
危険を感じたら、早いうちに作り直しましょう。
いま苦労して作り直しておいた方が、後の自分と会社のためになります。
