自分の思考パターンをメモしておこうかな…と。誰かの参考になればよしって感じで（笑）。
大昔の8bitマイコンの時代とか、今ならArduinoのスケッチ程度の話なら、何も考えず一気にゴチャっと書いたりするコトもある（というか、Arduinoはそれでどうにかなる程度の範囲で使うモンやと思ってる）んやけど、真面目にソフトを書く時は少し違うアプローチになってる。
最近のマイコンのソフトを書く作業ってのは、「いかに有能な社員を育て、役割を分担させ、それらの間をいかにスムーズにつないでいくか」に近いと思ってる。
んで、社員で足りないトコは下請けに出したりもする。この場合の下請けってのは、各種のミドルウエアであったり、OSのAPIであったりやな。
環境によっては雛形がある場合もあるけど、ヲイラが作業するようなやつに関しては様々な作業を行う社員（＝モジュールとかオブジェクト）をイチから育てる必要があるし、役割分担をどうするかも考える必要がある。新規のハードウエアなんかやと、実際に動作させてその反応を見るコトで分担方法を考えていくコトもある。必要な機能を並べ、それに対応したハードウエアの動作を確認し、それに合わせて社員構成を考えるって感じやね。作業してると新しい担当が必要なコトに気づき社員を増やしたり、別にしてた仕事を一つにまとめた方が効率が良さそうなので社員を減らしたり…なんてコトを日常茶飯事的にやってる。
ま、時には失敗した部分を切り捨てて全部やり直したりもするけどな。時々あるんや。最適を求めてやっていったのにどん詰まりするコトが。
当然、どんな社員を育ててどう運営していくのかがプログラマの腕の見せ所であり、そこにそれぞれの癖や好みが反映される。また、社員を育てていく過程で、徐々に社員自体がどういう役割を望んでいるかなんてのが見えてきたりするコトもある。というか、それが見えてこない奴って、大抵どこかで間違ってるんよな。
ちなみに、ヲイラが書くソフトは基本的には少数精鋭式で、あまり冗長度は高くない。各社員はガッツリと専業の専門家になってて、できるだけ少ない社員で全体を回せるようにする。なので、小さなマイコンでもキビキビ動く代わりに、他へ移植しようとしてもほとんど全てやり直しになる。まぁ、依頼によってはワザと下請けをフル活用したソフトを書く場合もあるけどね。これは、書いたソフトをそのままお客さんに移譲する場合やな。
なので、ヲイラはあまり大規模なソフトを書くのは得意ではない。全体が見渡せる範囲でモノを考えるのが好みだから。当然、階層化もしない。アプリがあってミドルウエアがあってドライバがあって…ってコードを書くのではなく、各モジュールが同じ平面上にあって相互にやり取りしてる感じのが好みやな。
他人が書いたソフトってのは、他人が育てた社員みたいなもので、当然その仕事の指示の仕方とか報告のされ方が異なるので、どこかで合わせ込まないといけない。どう合わせこむのか自体も考える必要がある。社員を修正するのか、自分を修正するのか、間に誰かをカマすのか…みたいなね。それぞれにメリット／デメリットがあるので、仕事の内容に応じてどうするかを考える必要がある。
なので、他人が書いたソフトがあるから安易にどうにか…ってのは、大抵の場合は不成立になる。イチから書くのと同等か、下手すりゃ却って手間が掛かるコトさえある。でも、その手間を掛けてでも流用する価値がある場合もある。難しいトコロやな。
逆に、例えばオープンソースで商売が成立するってのもソコなんやろう。その手間を自分トコで作業しまっせ…ってのがウリになるんやろな。
昔、情報処理一種の資格試験に経営の話が混じってるのが不思議でならなかったんやが、最近やってるコトを考えると、なるほどなぁって思えるようになってきた。
結局、素直に運営できる構成を作り出せたら勝ちなんやろと思う。ソフト書いてる時は、常にそのコトを念頭に置いて作業してるんよ。
誰かの参考にでもなれば幸い。