机上デバッグ・・このスキルを持ってますか?

このエントリーをはてなブックマークに追加

【はじめに】
本記事掲載の写真は、それぞれ著作権所有者様より承諾を得た上で掲載させていただいております。

 

数年前のことになります。システム関連文書の作成表現に関するセミナーを受講した際の話から始まります。

そのセミナーの先生は、いくつも著書をもつ有名なプロジェクト・マネージャの方でした。

その方が、セミナーの途中でこのようなことをおっしゃておりました。

「文書作成とプログラミングは似ている点があります。最近のプログラマが書いたソースコードを見ると、机上デバッグ(机上プログラミング)をしていないがために、読みにくく汚い状態のプログラムが多い状況にあります。現在のように、誰でも簡単に、画面上でプログラムが書け、画面上で簡単に修正でき、画面上で実行できる環境は便利ですが、その分だけプログラマの品質が落ちているといえます。」

私も、最近この状況を痛感する機会が増えてきたと感じています。

一例になりますが、とある会社のプロジェクトに参画した際に、あるプログラマ(以降、A氏と仮定)の作成したプログラムで不具合が多発している状況がありました。それを見たプロジェクト管理者が「Aさん、このプログラムで問題が多いから、机上デバッグをして俯瞰的にプログラムコードの全体像をトレースしてみてよ。」と言ったところ、Aさんから「私は机上デバッグ出来ないんですよ。プログラム開発ツールのデバッグ/トレース機能なしではプログラムを作ることは出来ません。」という発言が平気でされていたのです。

これを、傍で聞いていた私は正直にゾッとしました。とても、このようなスキルのプログラマとチームを組みたいと思えないからです。おそらく、このAさんは自分の書いたプログラムコードの全体像を把握できていないはずです。そのため、プログラムコードがスパゲティ状態になっていることが必至と考えます。

ちなみに、昔話と言われるかもしれませんが、私が初めてコンピュータに触れた30年前のプログラミング手順は以下のような要領でした。

  1. フローチャートを作成する。
  2. フローチャートを基にプログラムコードをコーディングシートと呼ばれる紙に手書きで書く
    【実際の手書きコーディングシート①】※Twitter 菅野氏より公開承諾を受けて使用
    codesheet
    【実際の手書きコーディングシート②】 ※mittake.comの夢酔独言(むすいどくげん)殿より公開承諾を受けて使用
    mittake-code
  3. コーディングシート(プログラムコード)の内容を、パンチャーと呼ばれる機械でタイピングする。 (タイピングした内容が、紙カードもしくは紙テープに出力される)
    【紙カード(パンチカード)】※こちらのサイト運用者様より公開承諾を受けて使用
    punchcard1
    【紙テープ】※他にも懐かしいものが湘南工科大学 工学部 情報工学科 様のサイトに公開されています。
    pjx_papertape_credit
  4. パンチャーで作成したプログラムコード(紙カードもしくは紙テープ)をコンピュータに読み込ませる。
  5. コンピュータで読み込んだプログラムコードを実行する。
  6. コンピュータよりプログラムコードをリスト印刷する。
  7. リスト印刷されたプログラムコードを机上で確認する。
  8. 処理結果と、プログラムコードの適正状態が確認できたら終了。

つまり、簡単にプログラムの修正と実行が行えない環境だったのです。

それだけ、当時のプログラマはコンピュータでの実行直前のギリギリまで、自分のプログラムコードが高品質な状態になっているか否かを机上で何度も確認し、万全と思えるプログラムコードを用意して、実行に臨んだものでした。(まさに、真剣勝負だったのです)

それに引き換え...(年寄りくさい言い方ですみません)

現在では、IDEと呼ばれる統合開発環境(プログラム開発環境)が充実しているため、誰でも思うがままに、思い付きのままに、プログラムコードを書くことができます。そのため、要求仕様の全体を把握することもせず、判るところからちょこちょことプログラミングを始め、最後はスパゲティ状態のプログラムコードになる。という若手プログラマによる粗悪なプログラムコードが多発していると思います。

このような便利なIDEが世の中に沢山存在しているわけです。
idescreen2

 

私は、このIDEによるプログラム開発環境の存在は非常に便利であることは理解しますが、若手プログラマにとってはとてもよろしくない状況と常々思っています。若手プログラマ諸君には、是非に机上プログラミングのスキルを有して欲しいと強く思います。

 

少し話を変わりますが、最近ですがSONY社がロボット犬「AIBO」の製品サポートを打ち切りました。  多くの「AIBO」ファン、「AIBO」オーナーにとって非常に残念なニュースとなりました。

この「AIBO」ですが、商品化する際に本物の犬のように歩かせることができないという大問題に直面したそうです。その際、「AIBO」に搭載するプログラムを担当していたプログラマが、原因を究明するために大量のプログラムコードをリスト印刷し、そのプログラムコードの印刷リスト(テレビ放送で見た限りではC言語でした)を社内の長い廊下にずら~っと並べ机上デバッグをしたというエピソードがあったようです。(NHKの「プロジェクトX」という番組で拝見しました)

この机上デバッグ根性が、今の若手プログラマに必要なスキルだと私は考えます。

 

20インチごときの小さい画面で、顧客へ納品する大量ステップのプログラムコードの全容を把握することはできるはずがありません。できたとしても、そのプログラムコードの品質が高いと胸を張って言えるでしょうか?

もしかしてですが、「プログラムは動けばいいんだよ。中身が少々汚くても・・」なんて思ってたりしていませんか?

顧客へ納品されたプログラムコードは、そのシステムライフサイクルが終了するまで何度もメンテナンス作業を繰り返し本番運用され続けます。最初の納品時に品質が低いプログラムコードでは、メンテナンス作業が行いにくくなるためシステムライフサイクルが短期間で終了し、早々に廃棄されてしまう可能性もあります。顧客に永く愛され使い続けていただくシステムとなるためにも、高品質なプログラムコードを提供し続けることがプログラマの使命だと私は思います。

例えば、こんなイメージです。画面では、大きな迷路の一部分しか見ていないようなものです。
smallscr2

これを、空を飛ぶ鳥の目線で、俯瞰的(空から地上を見下ろすが如く)にプログラムコードを見て「冗長部分をそぎ落とし」「不足部分を適正な位置に追加し」「トラブルとなりそうなインシデント箇所を見つけ修正し」そしてお客様に自信をもって納品できる高品質なプログラムコードを作るべきです。

こんな感じです。これなら、無駄なく効率的に迷路を抜け出せそうですね。

mazeall2

【補足】
誤解のないように補足しますが、全てのプログラムコードをリスト印刷し俯瞰視すべきということではありません。最低限、そのプログラムの主要部くらいはリスト印刷して、机上チェックすべきと私は考えます。なんせ、お客様へ納品する大事なシステムになるのですから・・(全てのプログラムコードを机上チェックできれば、これに勝るものは無いといえますが)

 

重ねますが、机上プログラミングと机上デバッグは、この現在でも大事なスキルなはずです。