PalmDreamsについて製品/商品情報サービス/Serviceダウンロード/Down Load購入/Order技術情報/Pico Workshopお問い合わせPalmDreamsのひとりごとリンク/Links
過去のひとりごと2006
2006年8月31日（木）共通化のジレンマ
ソフトウェア開発に携わる方なら経験すると思うのですが、ソースコードの共通化や評価テスト方法の共通化をどのように管理するのか頭の痛いところだと思います。
実は、PalmDreamsオリジナルソフト NavnBT,SC,BTiは、基本部分を共通としながらも メイン処理の構造が異なるアプリケーションなのです。
一番最初に開発を開始したのはNX70V用のNavnBTです。そして外付けシリアル通信よる有線GPS対応のNavnSC ,最後にBluetooth内蔵クリエ用としてNavnBTiを開発しリリースしました。
もともとは、GPSアンテナとの接続方式を外付けBluetoothアダプタHNT-BT1,RS232C,内蔵Bluetoothの３種類を一つのアプリケーションで対応する予定でしたが、プログラムの構造が複雑になることと、特定の通信方式のアルゴリズムを変更すると、他の通信方式への影響を確認する必要があり、その結果、評価に必要なコストが増えることを嫌い、分けて管理する事にしたのです。
しかし、最近になってこの個別の管理が重荷になってきました。
それは、 NavnBTiで好感触を得た実装をNavnBTに適用したときのことです。
UX50,TG50用のNavnBTiは内蔵Bluetoothドライバのクセの強さと、内部のリソースの効率化などの改善をVer1.15に多数加えました。一方、ベースソフトのNX70V,TH55,TG50?用のNavnBTは、処理が単純で変更を受けることもありませんでしたのでソーススコードの違いが多くなりました。
その結果、全く同一の機能を、同一のソースコード置換できないほどの差になり、ソースコードのメンテナンスが煩雑になりました。
そこで、今後の事も考え双方のソースコードを書き換えることでメンテナンス性を最大限に確保しました。
作業を終えてからこのソースコード共通化作業コスト増加分(正確にはNavnSCが未着手なのですが．．)と 最初から統一したアプリケーションによる評価コスト増加分のいったいどちらが有利なのだろうと、ふと考え始めました．．
きっと ケース・バイ・ケースなんだろうな ．．． という結論に達しましたが．．．でも今回の場合はどちらが有利? うーん どちらなんでしょう．．
そんな些細なこと．．と思われるかもしれませんね。
面倒くさがりやなんです．．根っからの。