あまりに見事に酷いお話
いきなりお仕事の愚痴で申し訳ないのです。
私たちが作っている機器の下位ユニットのソフトの出来が酷いです。
どういう風に酷いかというと、ちょっと通信ログみれば一発で（仕様をしらない人間でも「ああ、こりゃコピペして修正を途中し忘れたな」と解るような）バグが普通にあったり、2個同じものをもつ構成なのに片方づつ全く違う挙動をしたり（バグも両ポートで違う^^;)。もちろん(?) コッチを直せばアッチがデグレードで、いつまで経ってもまともに動くようになりやしません。
で、あまりの酷さゆえ、彼らのコードのレビューが開かれたのですが。おぉ、これは凄い。こんなに見事なコードをみたのは初めてでした。
最長不倒関数、芸術的字下げ、strcat の嵐、グローバル変数の多用(しかも同類を構造体に纏める事すらしない)、コメント無し・define 無しで使われる数多のマジックナンバー、strcat の嵐、ナンバリングされた変数名、関数名、..etc.Cプログラミング診断室の駄目な部分を抽出して見事に贅肉をそぎ落としたような、余りに美しくも完璧なダメコード。
実は残念ながらレビューには同席できなかったので（他がトラブっていたです TT)、私は後日コードをみせてもらったのですが、あまりの見事さに笑いがこみあげてきちゃって、あたしゃクック、クックと笑ってしまいました。（本人の目の前でなくてよかった）
そんなコードに、巨大なフローチャート(A3で印刷してもミニマム文字だよ）というおまけ付き。もう完璧です。
* * *
しかし、レビューへの突っ込みに対する彼らの受け答えは、コード以上に想像を絶するものだったそうです。以下伝聞ですし、けっこう誇張が入っているかもしれませんが、でもだいたいこんな感じだったそうな。
- Q. 2個同じ機器を抱えているが、コードも2つある。共通関数化しないか
- A. 2個同じものがある機器構成でもセンサ類のレジスタは別になる。だから共通の関数にできないのはあたりまえだ
- Q. 関数が尋常じゃない長さ(700行)なので可読性のため分割しませんか
- A. 関数コールであちこちに飛ぶ方がかえって読みにくい*1
- A. そもそも、コードの可読性は品質には影響しない。可読性をあげて良いことがあるのか。
- Q. 定数がコードに直に書かれているが、これを #define にしないと 置き換えが大変ではないか
- A. 定数は仕様だ。変わらないでしょ？変わらないなら変更を考慮する必要はないのでは。
- A. 可読性？可読性を挙げても(ry
- Q. とにかくコードが酷い。そもそも 構造化プログラミング は知っているのか
- A. 構造化プログラミングは知っている。しかしいつでも適用できるモノという訳ではない
- A. 見解の相違はあるかもしれないが、これが我が社の文化（伝統的スタイル）であり、他の社員でもメンテナンスする関係上、このスタイルを変えるつもりはない
- Q. コメントが殆どない。もう少し何とかならないか
- A. コメントがあるとコードはかえって読みづらくなる
- Q. 一度でもテストすれば発覚するような不具合が多すぎる。テストはしたのか？
- A. テストはしていない。これからは行うようにする。
次から次に飛び出す破壊力抜群の迷言に、誰もがあっけにとられてしまったとのことです。笑うしかないよね、トホホ。
* * *
コードを見た同僚が ぽそり名言。「ここまでコードの共通化がされてないと、ホワイトボックステストでもブラックボックステストと変わらないよな・・・。」
...あぁ、そうね。ホントにそうですね (T△T
*1:これを聞いたのは生涯2度目。まさか2度目があるとはおもってなかったですよ...
