青空を目指して2

どこまでも続く日々日常。ゲーム・音楽好きのおっさんの半生。日々日常とちょっとだけ思ったことの日記。

コードのデザイン

工業プログラマとして思う。コードの書き方、いわばコードのデザインが上級言語になるほど思想が表現されているものだ。上級言語になるほど、パズルチックでテクニカルなコードからはかけ離れて行き、実現したいものをそのままデザインするのが個人的にはいいと思っている。コード自体が機能や性能を体現する。コードがそのままシステムの設計図になっている。そういうものが結局わかりやすく、メンテがしやすいコードになると信じている。
ただ低級言語の時代って言うのは制御系コードは回路の体現が多く、とてもパズルチック。機能仕様を複雑に分解し、それをコード上でばらばらに再現、組み合わせて作る、って言うのが主流だった。そのためにコードを読んでもシステム全体のイメージは掴みづらい。何か問題が発生してもその問題箇所を特定するのは困難だし、特定できてもどう直すかがわかり難い。要するに難易度が高いのだ。昔は言語の仕様の都合もあったし、物理的な制限も多かったためパズルをせざるを得なかったし、上流言語で産まれてきたいろいろなデザインの思想も未熟だったため仕方が無かったと思う。
ただ、今の世の中やはり工業デザインとしてこういうコードを書くのは勉強不足だしいかがな物かと思わざるを得ない。
勉強が明後日の方向に行っていることも多い。上級言語の拡張された言語仕様を駆使して超テクニカルなパズルコードを書くやからもおおい。殆ど暗号化である。日本の工業プログラマで昔ながらの書ける人ほど、こういう傾向にある気がしてならない。で、スクラッチビルドをする場合はこういう人が書くもんだからベースコードは複雑怪奇なものになりがちだ。別にテクニック自慢のアマチュアプログラマたちがパズルを駆使するのは勝手にやってくれ、と思う。だが商業、工業プログラムにおいてこういう思想はもうNGとしか言いようが無い。
上流デザインをパズル化、暗号化する手間。それをデバッグする手間。問題発生時に問題を解決できない。他者が読めない、書けない。移植が困難。商業的に何一ついいことは無いのだ。
それでも今だにこういうプログラムは多く、またこういうプログラムを書けることを自慢げにやっているふしさえ感じる。そういうのの一環が単なるテクニック自慢の意識高い系の人たちのWEB記事。こういうの、ためになったためしがない。こうしたらすっきりしたコードが書けるでしょ!?って単にこれコード圧縮しているだけだよね?コードを圧縮する手間は?コードを解凍する手間は?コードに変化が求められた時どーするのよ?何もそこに配慮が無い。もうコレは趣味のコードとしか言いようが無い。てもそういうコードが実に多い。
うちら工業プログラマの世界では全然上流設計をそのままコード化する技術が語られないような気がしてならない。多くの人がそういうことを考えすらしていないように見える。考えすらしていないから、結局テクニック自慢のコードか、勢いでだらだら書くコードしか存在せず、それらのコードの持つ問題点にもまるで無頓着。そしてなぜこのシステムは不具合が多いのだ?となぜなぜを繰り返している。もうね。あほとしか言いようが無い。コーディングの技術、思想というものが一向に語られない。デザインって言うものが理解されない。
そんな世界では自分のような思想を持つ人間はむしろ異端視される。技術が無い世界で技術を駆使しようとすることに敵意を持たれる。理解されない。そして拒否される。自分はコードを書くときに流用元コードをあまり使わない。低レベルのものはコピペすることはあるが、アルゴリズムだけ借り、コード全体は上流設計に従ったものにリデザインすることが多い。ほんとにコレは嫌がられる。理屈がわからん人からしたら、コードをそのまま持って来て必要なところだけ手を入れるのが速いし、楽だよ!って言うのだが、そういう人たちがスマートに仕事を終らせているところを見たことが無い。後工程になるほど手間は加速度的に増大してゆき、残業地獄に陥りそれを自虐的に自慢しあう。
自分のやっているリデザインをした仕事はたいていコードを書くところが一番手間と時間がかかるがそのあとは速やかに確実に沈静化していく。だから自分はコードを書くときだけは忙しいがその後はいつも定時ペースに戻る。もうこれは実体験として理解している。ただそれを理解できるマネージメント担当はほぼいない。
過去に一人だけそのことを明確に理解できた人がいた。自分の書くコードをツールで機械的に評価し、コードの複雑度が複雑→安易に変わっていき、それと同時に後工程の時間が短縮することをデータを持って見ていた人がいた。不具合もリデザインをしている間は一時的に増大するが、その後一気に収束することをちゃんとデータで証明してくれていた。
ただ、短絡的な思考しかない人たちが圧倒的に多く、単に瞬間的な数の大小しか見れない人たちにとっては俺のような作業は理解不能の怖さしかないようなのだ。もうそれを説明する気も無いが。
今でも淡々とそういう設計をやっている。いつもデザインプランを見せるとみんな怪訝そうな顔をする。でもいい。結局自分はこの方が楽が出来るし。最近は少しずつデザイン論ってものが出てきている気がするのでそれに期待するしかない。残業減の傾向もその一つだろう。プロセスのリデザインって言うことに速く気づいて欲しい。

ってまた取り留めの無い文章を書いた。こんな文章を書きたくなるのはたいてい恐ろしく個性的なコードを読んだからである。LEDドライバって提供されているもの。俺の感覚ではドライバって物はハードコントロールに被せるラップ、橋渡し的なものでスマートなものではない。そういうものはドライバを使ってアプリケーションで組む、と言う階層的思想である。読んだドライバは違和感バリバリだった。外部に公開されたIFに何一つインプットが無い。こいつどうやって機器を制御するの?って思ってコードをよく読んでいくと、内部でシステム全体ののあっちこっちの状態を監視して、自立的に制御を変更しているのだ。うわぁ・・・。これドライバって言うか・・・。
理解してしまえばまぁなにがやりたかった、ってのはわかるが明らかにコレは失敗している。その証拠に作成後に大幅に内部が書き換えられており、外部の人からそもそも正しく動作しているか謎、組みなおした方がいいかも、と言われる始末。まぁそうだろうな。普通の人のドライバ感覚ではこのコードはうごかねぇし、制御することは出来ない。
さてどうしようかな。この思想は完全に把握したのでその思想にのっとった改造は可能だ。でもクライアントは全面改訂を求めている。正直後のことを考えると素直なドライバにしちゃうほうがわかりやすいと思う。そういえばこのコードを前に読んで直そうとした爺がすっげー悪戦苦闘して他の思い出したわ。そりゃそうだ。普通に読んだらコレは理解できん。
機能ががらりと変わるので結局自立判断しているところは全く流用の余地なし。すばらしいドライバだな。結局ほぼ全面書き直し(直しじゃないよな)の判断。