精神と時の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.

設計してない証拠です。

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

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

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

 

 

っていうかさー、

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

 

 

 

 

自動運転とEVは何を意味するか

近年自動車業界では、

自動運転やEV化へ向けた動きが

急速に進んでいます。

 

自動車メーカーで力入れているところも

ありますが、技術開発の主導はGoogleなど

IT企業だったりします。

 

個人的に自動車業界、特に日本の企業が

この動きにどうアプローチしているのか、

少し不安に思っています。

 

特に以下の2つについて。

 

Q1.AIの不確定さにどう立ち向かうのか

 

日本の自動車メーカーのウリは品質です。

あらゆる部品に対して設計や評価を十分に行って、

品質のブレを最小限に抑え、

見事なまでに完成度を高めます。

 

ただ自動運転となると、

このやり方が通用しなくなります。

 

全てがケースバイケースになります。

一定の評価は出来ても、どこからか

未知の領域に辿り着きます。

 

それに対して自動車メーカーは、

今のやり方では無理だ。

 

なぜなぜ、DRBFM、FTA

今回はたまたまその原因でしたになる。

 

 

Q2. ガソリン+エンジンから電池+モーター

 

これから自動車はモノからコトになります。

 

今は自動車は移動・運搬するためのモノと

捉えられてます。

 

そしてタイヤとエンジンが付いているモノを

どのように改善をするかで、

各社それぞれの特徴を出して

差別化しています。

 

自動運転やEV化が本格的になると、

モジュール化が一層進むでしょう。

 

その先には必然的にコモディティ化

発生します。

 

要するに、自動車は、

移動・運ぶためのモノではなく、

目的地に到着・届けるためコトになり、

主役はそのための何かになる。

 

タイヤとエンジンがついているモノを

買うのではなく、

目的地にたどり着くモノの一機能として

電池とモーターが付いている。

 

ガラケーからスマホへの移行により、

電話はモノからコトに変わりました。

 

スマートフォンというモノに

電話ができるコトが入ってしまいました。

 

自動車にも近々これが起きます。

 

突然(日本的には)一気にパラダイムシフトが起こるはずです。

 

但し一点。

私が公言すると、

世の中が逆側に動きます。

 

戦う前にまず観る....そして平和は突然訪れる

んまぁガツガツとリリースに向けて

評価チームが動いているわけです。

 

そんなところに突然致命的なバグ報告。

しかも設計側からこんなの見つけちゃったと。

 

焦る焦る。

根本的な設計に関するバグ。

症状だけ見たらもう設計し直し。

論理的に成立してない訳。

外部要因とは言え、なぜあっちは

こんな仕様(暗黙)にしたのか。

 

それはさておき、まず最初に考えるのは

論理的に成り立つ設計ができないか。

 

ひたすら変更のための情報を集めながら、

頭の中では設計している。

 

ただし一方で評価チームは彼らなりの

日程もあるわけ。

この案件終わったら別の案件へと。

同じテストケースを再度こなすのは

到底無理な訳で。

 

そこで考えるのは、報告されたケースのみに

影響する修正。

いわゆる蓋をするってやつ。

 

とはいえ設計側のテスト工数も

バカにならん。

 

あーと頭を抱えていたところ、

サッと言われた一言。

 

「そもそもこれリリース版で起きるのか?」

 

ハッとしましたね。

 

「評価結果を台無しにする前に、まず自分

 達でリリース版で起こりうるかの調査が

    先決じゃね?」

 

確かにあんなゴリゴリ評価を進めている

彼らがこの問題を見逃すだろうか。

 

見つけちゃった人に、

よく聞いたら開発版でのみ発生と。

 

リリース版で再現させようにも

なかなか再現できないと。

 

こうなったらロジックでなくタイミングで

発生しえない事を証明するしかない。

 

ひたすら回数を重ねた結果、

リリース版ではタイミング的に

ほぼ再現しえないことが

分かってきた。

コード見て、タイミング的に起こるとしたら

ハード異常だ。

 

....

 

変えない努力も必要やね。

ソフトウェアは論理だけではなかった。

 

 

 

 

 

やっぱりプレイングマネージャーなんて無理

たぶんメンバーと上司は呆れていると思う。

 

システム全体に及ぶ不具合の計画進めて、

担当ブロックの不具合コード直しながら、

上司と客先用の不具合報告資料書いて、

メンバーに別案件の指示する。

 

まだ自分が作ったコードならまだしも、

他人から引き継いだコードを、

技術負債が詰まったシステムを治すなんて、

組織的に動かないと無理だったんだろう。

 

引き継ぎ時にはそんなの分からない。

やれと言われたからやるだけ。。

 

結局自分の見積が甘かっただけなのか。

ヤバめの案件だから積極的に

みんな係わってくれないのか。

 

いや自分が回せていないからでしょう。

 

たぶん始まる時に、自分の守備範囲を

限定しなかったのが悪いのだろう。

 

数年走ったシステムを突然引き継ぐのは

断りましょう。

 

というか、

設計資料云々よりも

論理的に成立してないじゃないか。

このシステムは。

人日とか見る人で変わる謎単位

この作業は何人日で終わります.

 

エンジニアには親しみのある文章です.

 

単位って絶対なんですよ.

誰から見ても同じ尺度なのが

単位と呼ばれるもの.

誰が測っても10g.

誰が払っても1980円.

 

しかしこの人日とか人月とか.

誰が測っても違う単位なんです.

 

作業の担当者によって違う.

見積立てる人によって違う.

 

人の能力·体力に差がある以上,

これは仕方がないと思ってます.

 

問題は、1人日を1日で換算する人.

 

というか....

 

だいたいこういう人はメンバー5人で

10人日だから2日で終わると思ってる.

 

メンバーが他に何を抱えているか考えずに。

そもそもそれお前が頼んで来たし。

 

 

 

雰囲気が悪い

特に組み込みなんかだと

開発・製品リリースが終われば

保守フェーズに入ります。

 

となると、上層部は

他の火事場にメンバーを

回せって話になります。

 

当然外注さんもお金かかるから

契約終了って話になります。

 

そこから第2の炎上モードに入ります。

 

止まない不具合報告と説明資料作成、

何を意図するか分からない設計思想、

元メンバーの問い合わせ拒絶。

(元メンバーは回された案件で即炎上だから仕方ない)

 

チームの雰囲気も悪くなります。

俺はやりたくないオーラ全開。

でも残ってしまった運命。

 

開発フェーズで炎上したら、

保守フェーズでも炎上します。

必ず。

 

毎年繰り返しても気づかない上層部。

そして上層部の面子もやり方も変わらない。

 

何故なら会社的には収入をあげているから。

 

んーなんだかなぁ。