何も指導しないとプログラミングはこうなる

久しぶりにC++のコードを書いた。過去に作った Visual C++ 6.0 で作ったソフトウェアをまた、使わなければいけなくなったのだが手を入れるためには、Visual C++ 2005 に乗せ替えなければいけなかったからである。

ちなみに、なぜVisual C++ 2008 にしないのかというと、ソフトウェアの場合は流行物に飛びつくと痛い目に会うことがあるので自重しているからだ。Windows もXPで購入した数々のアプリケーションソフトウェアがそのまま動くかどうか不安なので、まだ Vista に乗り換える決心が付かない。

さて、久しぶりにプログラムのソースコードに触れることで、プログラミングのやり方について常々考えていたことがふつふつとわき上がってきた。

技術者はどのようにプログラムを書くのかということだ。次に自分が一般的だと思うパターンを書いてみるので眺めてみて欲しい。

【何も指導しない場合のプログラミングのやり方】

1. まず、何でもいいから目的に近いサンプルのソースコードを探す。目的のほとんどや一部分を実現できている実績のあるソースコードがあれば最高だ。
2. そのコードをコピーして、そのコードの変数や関数のネーミングルールやコーディングルールを読み取って、それに合わせて必要なコードを付け足す。
3. コンパイル・リンクしてエラーをなくし、目的を達成するまで試行錯誤を繰り返す。

しかし、この方法では大規模・複雑化したソフトウェアシステムにおいて品質を高めることはできない。

何が足りないかというと、分析・設計してからコーディングをしていないのだ。結果を早く出したいばかりに分析・設計を端折ってしまったり、頭の中だけで済ませてコーディングに入ってしまったりする。

そこで、自分は少しでもこれに歯止めをかけるために、ファイルヘッダ、関数ヘッダを必ず付けるようにしている。

たとえばこんな感じ。（等幅フォントが使えないので /* */ から//に変更した）

//*****************************************************************************
// 概 要 : 電子ポットメイン関数
// 関 数 : main( void )
// 引 数 : なし
// 戻り値 :
// 備 考 :
//----------------------------------------------------------------------------
// 作成日付 : 2006.06.20
// 作 成 者 : 胡麻 太郎
//*****************************************************************************

関数を作る前にヘッダ部分を他の関数ヘッダからコピーしてきて、概要、関数名、引数、戻り値、作成年月日、作成者などを書く。

この大したことがないような関数ヘッダの記述は実はその後ろにいろいろな意味がある。

【関数ヘッダ（クラスヘッダ）を書く意味】

1. 関数の概要を書くことで関数やクラスの目的や責務が明確になる。
2. 関数名を書くことで関数名のネーミングルールについて意識することになる。恥ずかしい名前の付け方をするとずっと誰がこの関数の名前を付けたのか証拠が残る。
3. 引数、戻り値を書くことはインプットとアウトプットを明確にすること。1～3までをやると関数の入出力と目的が明確になる。
4. 関数を作成した日付と作成者を書いておく、後にプログラムに手を入れたりデバッグするときに役に立つ。一回作りきりのソフトウェアではそれほど大きな効果をもたらさなくても、コードを再利用する確率が高い組込みソフトウェアでは、誰がいつ作ったのかという情報は大事だ。また、作成者を書き入れ署名することでそのプログラムに対する責任を負うという感覚が芽生える。

関数ヘッダ（クラスヘッダ）を書くのがいちいち面倒だと考えているプログラマーには上記のことを理解してもらわないといけないのだが、最初からこのようなルールは設計の規範として「その組織では当然やらなければいけないこと」としてしつけられ、意味も分からず繰り返しているうちに「ああ、ヘッダを書いておいて良かったな」と感じるようになることが多い。

Visual C++ ではウィザードを使うと、勝手に必要な関数のスケルトン（骨組み）がたくさん出来てしまい、当然そのスケルトンに関数ヘッダはない。だから、Visual C++ がはき出すスケルトンの関数にも自分はヘッダを付けるし、プロジェクトメンバーにもそう指導する。

組込み開発の世界では、ソフトウェアの品質が高いかどうかを外から判断するのが最も難しい。

機械設計の場合、設計が悪いと動かないし、生産工程で不良率が上がるし、そもそもできあがったものを先輩や上司が見れば良い設計か悪い設計か見分けがつく。

電気設計の場合は、作り上げた回路が期待通りに動かなかったり、精度が出なかったり、消費電流が大きかったり、煙が出たりして設計の善し悪しが分かる。回路設計がきれいか汚いかは回路図を見ないと分からないが、基本的には完成度の高い部品の組み合わせであるためチェックポイントの種類、組み合わせはソフトウェアほど多くない。

機械設計や電気設計に比べて、ソフトウェアの場合はできあがる完成品に対して設計の粒度が細かい。一行一行のプログラムを技術者が自由に書けてしまうので、たった数十行程度の関数であっても10人のプログラマがいれば、10通りの関数ができてしまう。

どの関数も「よい設計」であればよいのだか、変数を初期化していなかったり、出口が一つでなかったり、入力に例外があると無限にループが回ってしまうようなプログラムになっていることも少なくない。

「一応動くけれどもベテランが見ると危ない」関数は山ほどある。そんな関数が寄せ集まってシステムができあがっているのだ。機械設計や電気設計とソフトウェア開発の最大の違いは、そんな危ない関数の寄せ集めであっても、全体としてはキチンと動くことが多いし、もし、問題が発覚したらすぐに直せてしまうところが違う。

だから、商品をリリースする前なら、ソフトウェアエンジニアはどんどんプログラムを直してしまう。関数やクラスの完成度を高めるのではなく、対処療法で当面の痛みを麻痺させようとしてしまう。体質の改善ではないから、次の開発で楽になる方向につながらない。次の開発で楽になるというのは、信頼性の高い再利用資産が今回の開発で構築され、次の開発でほとんど手を加えずにその再利用資産を使えるというシチュエーションのことを指している。

製品のリリース間際に発覚した痛み（問題）にどんどん絆創膏を貼ってしまうことで、ソフトウェア資産はスパゲッティ化し再利用しがたいものに変質してしまうのだ。

近年、ソフトウェアのテスト技術に関する研究や取り組みが盛り上がっているが、絆創膏を貼るだけでは体質の改善にはつながらない。ソフトウェア品質を高めるためには、不良を取り除く取り組みと不良を作り込まない取り組みの両方が必要だ。

不良を取り除く取り組みを進める一方で、不良を作り込まない取り組みをしていかなければ、開発は決して楽にならない。

組込みソフトウェア開発のリーダー、サブリーダーの方達に「今、開発現場で問題になっていることは何か？」と聞くと90％以上が「品質問題で困っている」と言う。組込みソフトウェアの品質を高めるためには不良を取り除くだけでなく、不良を作り込まないために何をすべきか教えなければいけない。

これはいつ誰が教えるのか？　現状を考えれば、開発現場において経験を積んだリーダーがプロジェクトのメンバーに「設計の規範」として、不良を作り込まないためのルールを守らせることから始めるのは一番効果的だと感じる。

設計の規範の最初の一歩としてお勧めしたいのは、『組込みソフトウェア開発向けコーディング作法ガイド[C言語版]』と『組込み現場の「C」プログラミング 標準コーディングガイドライン』と『組込み現場の「C」プログラミング―基礎からわかる徹底入門』だ。

組込みソフトの初心者はC言語のコーディングスタイルの学習に『組込みソフトウェア開発向けコーディング作法ガイド[C言語版]』を辞書に『組込み現場の「C」プログラミング 標準コーディングガイドライン』を副読本として読むとよい。そして『組込み現場の「C」プログラミング―基礎からわかる徹底入門』で組込みソフトウェア開発のさまざまな設計の規範を学ぶ。

このようなコーディング作法やプログラミングに関する設計の規範は本当は大学のプログラミングの授業で教えて欲しいのだが、20年前の自分の経験も含めて言えばそういった授業が行われているところはほとんどないんだろうと予測する。

まあ、それは無理もないだろう。自分だって、設計の規範が大事だと感じるようになったのは、製品作りを何回も繰り返してからだし、エドガー・ダイクストラが提唱した構造化プログラミングの真意を知ったのも最近だ。

製品としてリリースするソフトウェアの内部を見る機会がほとんどない、大学の先生達にプログラミングの授業では文法を教えるだけでなく、コーディング作法やより信頼性の高いプログラムを書くための設計の規範を教える必要性を感じてもらうのは難しいのだと思う。

だから、一番大事なのは新人の技術者がプロジェクトで初めてプログラミングをするときだ。最初に組織やプロジェクトの設計の規範を教えてそれを守らせることが、その組織がアウトプットするソフトウェアの品質を下支えすることにつながる。

ここで何もしなければ、人間はその本質的な行動パターンから、プログラムを以下のようにして作ってしまうのだ。この状態を脱することができたプロジェクトでも、しばらく監視をしないでいるとすぐにもとにもどってしまう。

【何も指導しない場合のプログラミングのやり方】

1. まず、何でもいいから目的に近いサンプルのソースコードを探す。目的のほとんどや一部分を実現できている実績のあるソースコードがあれば最高だ。
2. そのコードをコピーして、そのコードの変数や関数のネーミングルールやコーディングルールを読み取って、それに合わせて必要なコードを付け足す。
3. コンパイル・リンクしてエラーをなくし、目的を達成するまで試行錯誤を繰り返す。

組込みソフトエンジニア初級者へのしつけがその組織の文化につながるようになれば、ソフトウェア品質向上の道が開かれる。

P.S.

『組込みソフトの品質を高めるには設計の規範が必要』の記事もお読みください。