今日は上司は一日出張で不在。普段は遠隔地にいて月曜だけ本社に顔をだすメンバーも、作業スケジュールが詰まっているとのことで今日は朝礼に来ていなかった。
私の方は装置の出荷と外注への資料送付が先週で終わり、「待ち」の状態に入ったので、後回しになっている案件の用意を始めた。
案件は、別のグループが開発中の装置の制御プログラムを測定プログラムから呼び出して利用できるようにするというもの。この装置についてはほとんど関わっていないので現状はよく分からないのだが、噂ではあまり完成度が高くないまま泥沼状態になっていると聞く。
まあそれもそのはずで、傍目にもこのプロジェクトの運営はあまりにデタラメに見える。そもそも開発のリーダーがあいまいだし、リーダーらしき人達は装置を(使うことは出来ても)設計をマネジメントする気も能力も無い。いわゆる丸投げである。一方で、ソフトの開発者は中国語ができるため、頻繁に海外に出張させられたり打ち合わせに借り出されたりでプログラミングに集中できる状態ではない。さらに、回路担当者はそういう状況に翻弄され続けてすっかり嫌気がさしている。
傍から状況を見た限り、今のやり方を続けていてはいつまでたっても市場に投入できるレベルに到達できるとは思えない。(未完成のまま売るというなら別だが)しかし、リーダー(一応)の一人は「もう少しで完成」と1年以上前から言い続けている。私の測定ソフトとの連携も、この装置の完成を見越してのものだ。こちらも優先度の高い別の案件があることを理由に、「そちらが完成したら連携を考えますよ」と逃げてきた。できるなら最後まで高みの見物を決め込んでいたかったのだが、あまりにもひどい有様なのでいい加減見てられなくなった。傍観者でいる方がストレスになりそうだ。介入して、可能ならサクッと片付けてしまった方がすっきりするだろう。
というわけで、問題のプログラムのソースを読み始めた。装置内蔵のARMのプログラム(ファームウェア)とホストPC上で走る制御プログラムがあるが、ファームウェアのコードから取り掛かった。動作の内容には深入りせず、コードが整理されているか、変数や関数の名前は妥当か、などの外面をざっと眺めてみた。
あるわあるわ、問題点が。そのいくつかは、前にチラッと見たときに指摘しておいたのだが、改善されていなかった。指摘の意図がちゃんと伝わっていなかったのか、出張などの間に忘れてしまったのか、それとも修正の必要は無いと思われたのかは分からない。ともかく英単語のスペルミスや名前の対応の不整合*1などから、コードの重複やグローバル変数の多用*2など、突っ込みどころが相当ある。「これはひどい」とまではいかなくても、100点満点で50点てところだろう。
一通り読んで、明らかに無駄な部分からリファクタリングしていくつもりだったのだが、困ったことに開発機が異音を出し始めた。そのままマシンがお亡くなりになってしまうとインストールされている開発ツールのライセンスがややこしいことになりそうなので、作業を打ち切ってライセンスを抹消しておいた。続きは修理または新しいマシンを購入してからにする。
ちなみにこの開発ツールには評価版があって、ファイルサイズが小さい場合はこれを利用することも出来る。ためしに評価版を自分のマシンにインストールしてファームウェアをビルドできないかやってみたが、リンクの時にエラーが出る。エラーに関係がありそうなメモリマップのオプションに適当な値を入力してみたらビルドはできるようになった。でも多分実機では正常に動作しないだろう。やはり開発機を復旧させるまでファームウェアをいじるのは延期する。

*1:decXXX()の反対がincXXX()ではなくaddXXX()になっているとか

*2:関数の大半が引数と戻り値がvoidなのもこのせい