精神と時のblog

明日が来年ならデーモン閣下と同い年になれると思っているおじさんの駄ブログ

腐っても鯛の逆

腐っても鯛。

http://kotowaza-allguide.com/ku/kusattemotai.html

 

ソフトウェアの世界では

むしろこの逆が発生します。

 

クソ設計とクソコードを

どんなに治そうとも、

クソの域は脱しません。

 

1万行超えのソースファイル、

相互参照のオンパレード、

mutexのlock,unlockの間が画面に収まらん、

関数の戻り値は基本void.

 

今回の実装は

アンチパターン縛りで

みたいな指示があったのかな?

 

むしろクソ設計のまま、

機能追加や派生モデル展開とか

なるわけです。

 

上層部はどれほど

クソ設計とクソコードで

構成されているか

わからないわけで。

 

クソコードのバグには蓋をする。

クソコードがさらにクソ化する。

なぜなら修正の影響範囲が広過ぎて

局所的な対応をせざるをえない。

 

さらにクソ化に拍車がかかり、

あらゆる箇所に蓋が増え、

設計とコードの意図が追えなくなる

 

どんなに構成管理しても

ドキュメントを用意しても、

蓋が多いと破綻します。

見きれないから。

絶対ヌケが出るから。

 

そもそもこの状況だと

ドキュメントより修正を優先しろ、

と言われるのが通例で、

しかし後からリリース時に

なんで設計書もないんだ

って怒られるパターンですね。

 

アホらしくなってきますね。

 

設計とコードの“とりあえず”は、

そのまま“永久”に変わるので。

お気をつけて。

 

...っていうかぶん殴りたいレベルです。

 

 

 

【おまけ】

せっかくなんで

今回のアンチパターン

一個ずつ。

 

1. 1万行超えのソースファイル

ちなみにC++でクラス実装です。

色々言いたいことありすぎて。

というか先に手が出そう。

オブジェクト指向って何だっけ?

って忘れそうな破壊力。

 

そして常識を超えたcase文の数。

俺がbreakした。

 

2. 相互参照のオンパレード

要するにクラスAがクラスBを参照し、

クラスBがクラスAを参照する。

 

こうなった時点で修正時の

影響範囲が無限。

そこらの影響分析ツールにかけても

影響範囲が見えない。

結局人的作業になってしまうんです。

 

コードレビューする前に

doxygen+graphisかけて

ザッと見た目で

複雑度チェックするくらい

しないと駄目だ。

クラス図書かせても分かりにくいところは、

設計書から省いてくるから現実が見えない。

 

3. mutexのlock,unlockが画面に収まらん。

もうunlock忘れが確実にでるよね。

挙げ句に

pthread_mutex_lock(...);

....

if( .... ){

    pthread_mutex_unlock(...);

    return ;

}

....

if( .... ){

    pthread_mutex_unlock(...);

    return ;

}

 

....Fxxk。

mutexの使い方云々の前に、

関数をどう実装するかからだな。。

結構いい歳のおっさんが書いてるから

泣けてくる。

 

4. 関数の戻り値が基本void.

設計してない証拠です。

こうなると、テストの自動化もきつい。

関数は入力と出力で構成されるフィルタ。

この基本概念がないとだいたいヤバい。

 

 

っていうかさー、

こんなにクソコードばかり書いてんのに