持つべきものはデータ構造とアルゴリズム力

適切なデータ構造とアルゴリズムを選択し簡素な実装ができる力の重要性を、
実務を通して理解することができた。

私は普段デバイスドライバを書く仕事をしている。
デバドラのレイヤでは複雑な事はせずに、軽く、賢くバイナリ列をパースしたり、
アプリが使いやすいAPIを提供する責務がある。
デバドラを書くことにおいて「いい仕事」とは、

1. 処理が軽いこと
2. 使いやすいAPIが最小限に揃っていること
3. 適切な抽象化がなされ、拡張性に富んでいること

に集約されると考えている。


1. 処理が軽いこと

当然のことであるが、冗長な処理や、不要な条件分岐等はやめる。

例えば、USBやBluetooth, WiFiなどの通信関連のデバドラでは、
えてしてパース処理が発生する。
TCP/IPに関連するデバイスではヘッダのどこぞのビットがIPアドレスでー、
これが宛先MACアドレスでー、。。。うんぬんかんぬんな処理がどこかに入るはず。
基本的なことではあるが、とにかく不要な処理はスキップしよう。
いちいちループを書いて探索処理をすることは、
場合にも依るがデバドラ実装においては負けだと思おう。

データ構造を工夫することで繰り返し処理を減らす。
ときに組込系のシステムでは使用可能なメモリ容量が限られているケースが見られるが、
無条件にループを描いて降伏するのではなく抗おう。
今まで割り当てていた使用していないビットに意味を持たせて、
どうにかしてフラグ管理するなどしてメモリの節約を考えよう。

if(  A && B && ...)　と書くときは重い処理を右に持って行こう。
短絡評価を有効活用するわけです。
とにかく重い処理からは逃げることを考えよう。

データ構造の設計はひとたび間違えると糞コードのオンパレードになる。
データ構造とアルゴリズムはほぼ同義といっていいくらい関連性が深い。
ここで最適な戦略を取れるかどうかは、
日頃の学習と、業務における経験で培うところだろう。
糞コードをたくさん産んでは捨てることでスキルをのばそう。

タイトルに記載したとおり、私は本当にアルゴリズムとデータ構造の選定スキルの重要性を感じている。
デバドラ開発において、アルゴリズム力はオペレーティングシステムで、プログラミング言語を扱う能力はアプリケーションのようなイメージ。
アプリがいっぱい揃っていてもOSが残念であれば全体の評価は糞だ。
プログラミング言語が多数扱えること以上に、
思考のOSを鍛えることこそがITエンジニアとして大成するカギになると考えている。

参考になった書籍を以下に掲載する。
いいプログラマはたいてい読んでいるという書籍だ。
目から鱗が落ちた回数分、自分が未熟であることを感じることができた良書である。





2. 使いやすいAPIが最小限に揃っていること

デバドラはなんのためにあるのか？
アプリ屋さんに使ってもらうためである。
シンプルで使いやすいAPIを用意すれば、
ミドルウェア開発者やらアプリ開発者やらから来る注文や質問を事前にシャットアウトでき、
不要な仕事を発生させずに済むのである。
また、「最小限に」と記述したことには意味がある。
APIを不要にたくさん用意すると、APIを提供するデバドラ屋のサポートコストが上がる。
更に、APIを一度公開してしまえば、後方互換性を考慮する手間が発生する。
結果、無駄な仕事を増やす結果になってしまう。
それだけではない。
後方互換性のために自分の知的創造物であるデバイスドライバの神聖な領域を汚すような後方互換性を担保するための糞コードを書かなければならないのである。
これはエンジニアからすると死んでもやりたくない行為である。


3. 適切な抽象化がなされ、拡張性に富んでいること

例えば、あるプラットフォームで使える多種多様なデバイスに対して、
別々に構造体を定義した場合はどうなるだろう。
アプリ屋さんからするといちいち構造体を使い分けなきゃいけなくなるし、
実装コードは汚くなりバグを生み出しがちになる。
加えて、彼らの学習コストも増大する。
デバドラ提供者側は、人間が解釈できるレベルの粒度でオブジェクトという抽象的なカタマリを作っていこう。

抽象的なカタマリという面でいえば、デバドラというものはアプリにstaticにリンクされるべきものではない。
ほぼ確実に動的にロードされて使われるべきだ。

静的リンクを行う戦略をとった場合、後方互換性の観点からするとガン細胞になりがちだ。
大昔に出たアプリが動かない可能性だって出てくる。
staticにリンクされたものの場合、修正することは困難になる。
多種多様なアプリが乗っかるデバドラの場合は、後方互換性や拡張性の観点から、
ほぼ確実に動的ライブラリの形で提供すべきだろう。