okuの日記: Re: あまりに見事に酷いお話 2
日記 by
oku
あまりにアレ過ぎて、どこまでが本当でどこまでがネタなのかよく分からないのですが、あまりに見事に酷いお話 - みねこあより:
- Q. 2個同じ機器を抱えているが、コードも2つある。共通関数化しないか
- A. 2個同じものがある機器構成でもセンサ類のレジスタは別になる。だから共通の関数にできないのはあたりまえだ
- Q. 関数が尋常じゃない長さ(700行)なので可読性のため分割しませんか
- A. 関数コールであちこちに飛ぶ方がかえって読みにくい*1
- A. そもそも、コードの可読性は品質には影響しない。可読性をあげて良いことがあるのか。
- Q. 定数がコードに直に書かれているが、これを #define にしないと 置き換えが大変ではないか
- A. 定数は仕様だ。変わらないでしょ?変わらないなら変更を考慮する必要はないのでは。
- A. 可読性?可読性を挙げても(ry
- Q. とにかくコードが酷い。そもそも 構造化プログラミング は知っているのか
- A. 構造化プログラミングは知っている。しかしいつでも適用できるモノという訳ではない
- A. 見解の相違はあるかもしれないが、これが我が社の文化(伝統的スタイル)であり、他の社員でもメンテナンスする関係上、このスタイルを変えるつもりはない
- Q. コメントが殆どない。もう少し何とかならないか
- A. コメントがあるとコードはかえって読みづらくなる
- Q. 一度でもテストすれば発覚するような不具合が多すぎる。テストはしたのか?
- A. テストはしていない。これからは行うようにする。
テストしてないのは論外として、最長不倒関数が700行くらいであればまだ救いようがあるかも知れんですよ。 グローバル変数 (〜状態の書き換え) が十分に少なければ、ですが。
今まで自分が見た中で最長の C 関数は、さて何行だったかなあ... 1000行ちょいのを見たような記憶がありますが (もちろん「開かずのコード」として門外不出) あまり記憶に留めておきたくない物件なので忘却の彼方です。 ということにしたいです、できれば。
しかし、いかな REAL PROGRAMMER と言えどもテストはするはずなんですが。 まあ、真の REAL PROGRAMMER なら、コンパイラの吐いたアセンブリコードなりオブジェクトファイルなりを手で書き換えてるでしょうから「ソースコードなんて飾りです。偉い人には(ry」なのかも知れませんね。 :-)
「保守性」も品質 (スコア:2, すばらしい洞察)
ISO/IEC9126でソフトウェアの品質特性が定義されていますが、「保守性」も含まれているのですけどね。可読性は保守性に直結するものだと思うのですが、さてどういう言い訳をするか興味がありますね。
Re:「保守性」も品質 (スコア:1)
おお、確かに。 言われてみればその通りでしたね。
# そういうのすぐに忘れるなあ... < 自分
自分はこういうのに遭遇すると「どういう仮定の下でならこの屁理屈は有効になるか」というメタ屁理屈を考えるのが学生の頃から好きだったので、ここは敢えて、かのプログラマさん達の信条に寄り添ってみるとしましょう。 :-)
すみません、いきなり弁護不能です。 (^_^;
う〜ん... 「センサ類のレジスタを抽象化するレイヤを1枚書いてみたが、割込みの頻度が上がると応答が間に合わなくなった。 メモリを増やすかもっと速いプロセッサを寄越してから言え」くらいですかねえ。
実は「かえって読みにくい」が真になるケースを一つ知っています。 それは、グローバル変数を更新しまくるコードです。 このような場合、関数を分割してもやることは結局同じ (状態の更新) なので、目に見えないところで状態を勝手に変えられるくらいなら、まだしも距離の近い同じ関数内でやってもらった方が見やすい... ということになります。
が。 もちろんそれに対する正準回答は「そもそもグローバル変数作るな」です。 これも弁護が難しいですね。 今時なら、レジスタに置けるローカル変数の方が動作も速いはずです。 仮にセンサ類のレジスタがメモリマップされている (事実上のグローバル変数になっている) としても、それこそ抽象化レイヤを1枚書けばすむことですし、今時の C/C++ なら inline 関数があるので関数呼び出しのコストは限りなく 0 に近づけることができると思うのですけどねえ。
それから「可読性をあげて良いことがあるのか」については... もう完全に弁護不能です。 可読性をさげて良いことは、ジョブ・セキュリティくらいですから。
「よ〜し、お前らは 3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982 とソースのあちこちに書きたいんだな? よし、許可する。 但し、一箇所でもタイプミスしたら切腹な」とか「よ〜し、じゃあ次世代機の仕樣は現行機の一律 20% 増な。 それ以外はほぼ同じだから現行のソースが流用できるよな? 予算は現行の半分でよろしく」とか言ってあげたいですね? というのはさておき、例えば、毎回思いつきで基盤層が変えられているので、どうせメンテナンス性を良くしてもしようがないとか、ポータビリティを気にしても書き捨てになってしまうとか、そういう職場環境なら、まあ、ありかも知れません。 でも、ハードウェア関連であれば、少なくとも数年間はメンテナンスし続ける必要があるはずなんですが...
真のプログラマばかりなんだね! すごいや!
やっぱりそうだ! この会社は真のプログラマの会社なんだよ! ほら「Real programmers don't write comment. Code is obvious.」っていってたじゃないか!
すみません、さすがにこればっかりは完全に弁護不能です...