スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

引き継いだソースコードをヤバイと思う瞬間 

「一生あなたがそのプログラムをメンテナンスするならいいけどね」

 

企業でプログラムを書いていれば一度は聞いたことがあるかと思います。 他人が書いたプログラムを引き継ぐということはごく普通にあります。RTOSなどが使われているそれなりの規模のプログラムを引き継ぐとき、 今までよくこれで問題がでないかったなぁと思うようなソースコードを渡されることがあります。 プロダクトによって見るべきポイントはいろいろあると思いますが、引継ぎ時に私が最低チェックを入れるポイントを挙げてみました。

 

まず、基本中の基本ですが組み込みソフトウェアの場合、汎用ポートを制御することが多く見られます。 システムが(起動時など特定の場合を除いて)通常稼動している際の処理で汎用ポートレジスタを特定のビットを1にしたり0にしたりするような場合に何のためらいもなく

*PORT_ADDRESS |= PORT_BIT;

のような記述をされているときです。他のビットを別のタスクや割り込みハンドラ内で制御している場合に非常に危険です。 仮に今扱っているハードウェアでは大丈夫でも、次の(試作も含めて)ハードウェアでピンの割り当てが変わらない保障はどこにもありません。 ちゃんと排他処理を行うべきです。

 

次にヤバイと思うパターンは割り込みハンドラ内でのグローバル変数へのライトアクセスです。以下はあまり現実的な例ではありませんが、 プログラムがふっとぶ可能性があります。

#define TABLE_MAX 10
int counter = 0;

void handler(void) { counter++ }

void func(int *table)
{
    if (counter < TABLE_MAX) {
        table[counter]++;
    }
    else {
        counter = 0;
    }
}

この例では排他処理やローカル変数を使うことで回避できますし、そのように記述されることも多いと思います。ただ、多くの場合、 OSなどのサービスを除くとメインループと割り込みハンドラという関係において割り込みハンドラ内でライトアクセスを行わなくてもプログラムは記述できることを意識することが重要です。 もちろんやむを得ない理由や最適化の結果としてライトアクセスを行うケースがあるのは認識していますが、 そのような場合は必ずソースコードにコメントをつけるべきです。 何のコメントもなくライトアクセスしているようなコードは危険性を疑ってみるべきです。

 

典型的なケースで一番困るのが状態管理用変数の継ぎ足しや流用でしょう。 開発が進むにしたがって当初考えていたよりも状態の定義が不十分であることが明確になってきます。 不十分であることがが発覚するたびに状態管理用変数の追加や流用が行われるわけです。 条件文のネストの中に状態管理用変数が再登場したり登場の順番が入れ替わっていたり、 3つ以上の変数を使用しているにもかかわらずなんのドキュメントも無い様な場合、やはりヤバイといえるでしょう。 高い確率でその変数はグローバル変数になっているはずです。

 

逆に安心感のあるコードのパターンとしては、 割り込みハンドラの中身を所有しているモジュールにおいてその割り込みの制御をモジュールの使用者にまかせずにモジュール内に隠蔽しているようなソースコードです。 特にそのモジュールがタスクも所有している場合、割り込み制御の隠蔽はそれなりに考えていなければできないものです。

 

油断しているとすぐにソースコードはヤバイものになります。 自分なりのべからず集を頭の中からアウトプットしておくことは自戒の意味においても大切ではないでしょうか。

 

スポンサーサイト

ソフトウェア開発における再利用物 

最近、ソフトウェア開発における再利用性について同僚と話をすることがありました。その際、 どうにも現在の私の考えが自分でもうさんくさいと思えたのでもう一度自まとめなおしたほうがいいかなと思っています

 

再利用すべき対象だと考えているのは、ソースコードそのもの、モジュール間インターフェース、モジュール間関係の3つです。

 

ソースコードそのものはコンパイルされているかどうかに関わらず、 現実に利用される場合はいわゆるライブラリという形でサービス提供者から利用者に仕様と作法が提供されます。 モジュール間インターフェースは枠組み提供者から利用者とサービス提供者に仕様と作法が提供されます。 典型的な例としてはOSが提供するデバイスドライバの利用や作成のための仕様でしょう。モジュール間関係はいわゆるデザインパターンです。

 

ライブラリはそれが動作する環境に強く依存、あるいは環境自体を規定します。 インターフェースは例えばOSが提供しているインターフェースであればOSさえ動作すればハードウェアには依存しません。 デザインパターンはOSにさえ依存しません。 適用範囲という意味においてはライブラリ<インターフェース<デザインパターンという関係が考えられます。

 


これに対して実在する再利用物の数の関係はライブラリ数>インターフェース数>デザインパターン数になるでしょう。 抽象的な表現になりますが、 ソフトウェアという世界を満たすためには適用範囲の狭いライブラリは数多く必要となり適用範囲の広いデザインパターンは数が少なくてすむということです

 

多くの部署を持つ企業で全社的な再利用プロジェクトが進められることがありますが、 その目的が表す適用範囲の広さに関わらずライブラリを作ろうとします。 何もGoFパターンのようにソフトウェア全体に影響するパターンを作る必要はないでしょうが、その企業のプロダクトで一般的に必要な機能、 ユーザーインターフェースなり、ソフトウェアアップデートなり、 メカ制御など一段具体的な範囲に対してに対して有効なパターン開発に向かうべきではないでしょうか。 そして現場でそのパターンが提供する有効性を持ったライブラリを作っていくのがよいように思えます。

 

欲ばり過ぎるニッポンの教育 

欲ばり過ぎるニッポンの教育
苅谷 剛彦 増田 ユリヤ
4061498665

苅谷剛彦さんと増田ユリヤさんの対談本です。普通の対談本と少し違うのは対談内容を書き起こしただけでなく、 合間合間に対談後に改めて両人がどう思っていたかがそれなりの量を伴って且つ、わざわざ書体を変えて掲載されていることです。 この形式はとても面白いと思いました。その中でいくつかキーワードを拾ってみました。

 

第2章の冒頭でポジティブリストというキーワードが出てきます。ポジティブリストとは良いと思われるもののリストですね。 英語が話せないよりは話せるほうが良い、コンピュータが使えないよりは使えるほうが良い、 一つのテーマに沿って教科を横断的に学べる機会としての総合学習はあったほうが良いというようなものを追加していきたがる性向が日本人にはあるということが書かれています。 成果物が個別に評価されるようないわゆるもの造りにおいてはポジティブリスト性向がプラスに働くことは実証されました。 個別の成果物から得られる利益をトータルで増やしていこうという経済的な効率面においては少なくとも現在は選択と集中という言葉で表されるようにポジティブリスト性向からの脱却へ向かっています。 さて教育は?と言われてた場合、私はどちらの偏ってもいけないとは思っていますが、偏らないための仕組みが私には思いつきませんでした。

 

第2章の終わりに魔法の呪文というキーワードが出てきます。「個性の尊重」「考える力」「豊かな心」「確かな学力」 「子供を大切にする教育」これらは魔法の呪文だと書いてあります。魔法の呪文となりうる言葉には総論賛成、 各論反対の状況を引き起こす性質を持っているとのことです。このことには私は全く同意します。現実を語る場においてこの「魔法の呪文」 の多用は非常に危険だと考えています。またそのような言葉にはうさんくささがあるともあります。 かつてマルチメディアという言葉が流行った時代に私は友人にこう言った事があります。「マルティメディア」の部分を「うさんくさい」 に変換してもほとんど意味が通じちゃうよねと。現在だとアジャイルでしょう。「アジャイルという思想」 として明確に言葉にされたことによってテストファーストやペアプログラミングなど様々な開発パターンを生み出されてきたことは計り知れないほど素晴らしいことです。 しかしアジャイルはすばらしいよね、だからうちでも導入したいよね、導入するにはどういう体系がいいんだろう、 XPってのがあるからそれをいれよう、ちょっと待ってようちの会社フレックスなのに毎日朝会やるの?。。。魔法の呪文に見えないでしょうか?

 

第4章にフィンランドというキーワードが出てきます。こちらのサイトでフィンランドメソッドについていくつか例が挙げられています。 とても良いものだと私も思います。さて問題はこれらの学習の成果をどのように評価するかです。 フィンランドではすべてかどうかはわかりませんがポートフォリオ評価というものが行われているとのことです。 生徒たちが学習の過程で作ったものを先生が評価するとのことです。これは教師が信頼されていなければ実現できません。 フィンランドでは特別に給与が高いわけでもないのに高校生の人気ナンバーワン職業が教師だそうです。 また一般企業も教育学部出身者は能力が高いと認識しているとのことです。 こういう環境のもとでフィンランドメソッドは実践されているわけです。もちろん全く同じ環境にしなければだめかというわけではないのですが、 フィンランドメソッドを日本で実践するためには日本にどのような環境を作らなければならないかは議論されるべきでしょう。


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。