IT技術者たるもの、これくらいは暗記しておかねば・・・

IT戦士の方々皆さま、日々業務にお疲れ様です。

本日は、IT技術者であれば、恐らく皆さま暗記していると思われる事項を記事にさせていただきます。

その暗記物とは「10進数⇔2進数」「10進数⇔16進数」になります。

もちろん、10進数の10,000を16進数に暗記なんてのは無理ですよね。

私が申し上げたいの、10進数の「0~15」を対象にした暗記の話になります。つまり、16進数であれば「0~F」、2進数であれば「0~1111」の範囲となる4ビットで表現できる16個の数字のことです。この範囲の変換は即時に行えるように暗記しておいて損はありません。

実際、我々の業務で10進数の「0~15」を2進数や16進数に変換することや、その逆変換を行う場面は少なくありません。この変換作業に時間をかけられては作業の生産性に支障をきたしてしまいます。(諸兄方々から「当たり前でしょ!」という声が聞こえてきそうですが)

ところが、これが出来ないルーキーIT技術者も少なくないようです。

10進数の「0~15」を即座に2進数や16進数に変換できないIT技術者の方は、今すぐに下述の変換表を印刷し、暗記することをお勧めします。(自分のためですよ!)

 

<変換表>

henkanhyo

 

余談:

約30年前ですが、私が学生プログラマだったころ、ゲーム作りに夢中でした。

その際、ゲーム画面で動き回るキャラクタの絵を作る時に、下図のように16進数変換を行い、当時のコンピュータにキャラクタの絵を描画させていました。かなり、懐かしい思い出ですね。(苦笑)

hexchar

[補足]
キャラクタの色を塗りたいドットを「1(2進数)」、色を塗らないドットを「0(2進数)」で表現しています。

 

VB.NET開発者にクイズです! ちゃんと正解を出せますか?

VB.NETの開発者にクイズです。

是非とも、正解を出して下さい・・・ね。

出せなかった人は、VB.NETの基本から見直すことも必要かもしれませんよ。

 

それでは、クイズです。

先ずは下記のコードをお読みください。

Private Sub BTN_HUTU_Click(sender As Object, e As EventArgs) Handles BTN_FUTU.Click

  Dim l_SideA As Integer

  Dim l_SideB As Integer


  '■A側の変数に1000を代入
  l_SideA = 1000

  '■B側の変数にA側の値を代入
  l_SideB = l_SideA

  '■B側の変数の値を2000に変更
  l_SideB = 2000

  '■A側の変数の値を画面に表示
  MessageBox.Show("l_SideA側の値:" & l_SideA)

  '■B側の変数の値を画面に表示
  MessageBox.Show("l_SideB側の値:" & l_SideB)

End Sub

 

さて、このコードの最後に表示されるメッセージボックスに表示される値は何でしょうか?

なんて問題は、聞くまでもありませんね。

結果は、以下のように表示されます。

res_h_1

res_h_2

 

では、下記のコードの最後に表示される2つのメッセージボックスに表示される値は何でしょうか?

Private Sub BTN_OBJECT_Click(sender As Object, e As EventArgs) Handles BTN_OBJECT.Click

  Dim l_SideA As DataTable

  Dim l_SideA_AddRow As DataRow

  Dim l_SideB As DataRow


  '■A側のオブジェクト変数(DataTableの1行目)に1000を代入
  l_SideA = New DataTable
  l_SideA.Columns.Add("A", GetType(Integer))
  l_SideA_AddRow = l_SideA.NewRow
  l_SideA_AddRow("A") = 1000
  l_SideA.Rows.Add(l_SideA_AddRow)

  '■B側のオブジェクト変数にA型のオブジェクト変数を代入
  l_SideB = l_SideA.Rows(0)

  '■B側のオブジェクト変数の値を2000に変更 
  l_SideB.Item("A") = 2000

  '■A側のオブジェクト変数の値を画面に表示
  MessageBox.Show("l_SideA.Row(0)側の値:" & l_SideA.Rows(0).Item("A"))

  '■B側のオブジェクト変数の値を画面に表示
  MessageBox.Show("l_SideB側の値:" & l_SideB.Item("A"))

End Sub

 

正解を出して下さいよ~~。

(-_-)/~~~ピシー!ピシー!

【正解】はこちらになります。

res_o_1

res_o_2

 

皆さん、正しい正解をだせましたか?

もしかして「最初のメッセージボックス(l_SideA側)の値は、変更されないから初期設定のまま1000だよ。」なんて解答をした人いませんでしたか?

 

 

上記のコードのコメントを書き換えると以下のようになるわけです。

Private Sub BTN_OBJECT_Click(sender As Object, e As EventArgs) Handles BTN_OBJECT.Click

  Dim l_SideA As DataTable

  Dim l_SideA_AddRow As DataRow

  Dim l_SideB As DataRow


  '■A側のオブジェクト変数(DataTableの1行目)に1000を代入
  l_SideA = New DataTable
  l_SideA.Columns.Add("A", GetType(Integer))
  l_SideA_AddRow = l_SideA.NewRow
  l_SideA_AddRow("A") = 1000
  l_SideA.Rows.Add(l_SideA_AddRow)

  '■B側のオブジェクト変数にA型のオブジェクト変数のアドレスを代入
  l_SideB = l_SideA.Rows(0)

  '■B側のオブジェクト変数の値を2000に変更 → 同時にA側のオブジェクト変数も変更されてしまう。
  l_SideB.Item("A") = 2000

  '■A側の値を画面に表示 → B側の値に変更により、A側の値も変更されることを確認
  MessageBox.Show("l_SideA.Row(0)側の値:" & l_SideA.Rows(0).Item("A"))

  '■B側の値を画面に表示
  MessageBox.Show("l_SideB側の値:" & l_SideB.Item("A"))

End Sub

 

私見ですが、これはただのクイズで終わるような問題ではないと考えます。

VB.NETのビギナーであれば、まず間違いなく「最初のメッセージボックスの値は、1000だよ。」と解答してしまうのではないでしょうか?

無理もないかもしれません。コードを見る限りオブジェクト変数のl_SideA側を変更するような命令行を見つけることができませんから・・・

つまり、先輩プログラマが開発したソースコードをビギナープログラマーが誤って読み解いて、そのプログラムに対して誤ったメンテナンス作業を行ってしまう危険性がある考えます。

開発したシステムのライフサイクルとなる数年間(長ければ10年近く)の間、メンテナンス作業を行う度に、この問題記事のような誤った解釈によるコードが書かれることがないか心配してしまいます。

この問題記事の内容は、VB.NETを使用するすべてのプログラマーが認識し、かつ後輩プログラマに対して誤った解釈をしないように教育をしていく必要がある重要な事項と考えます。

 

もし、本記事のクイズに誤った解答を出してしまった方は、今後十分に注意して下さいね。

 

※本記事記載のVB.NETのソースコード(ソリューション一式)のダウンロードはこちらからどうぞ。

ExcelのVBAのFindメソッドで困ったエラーが発生!

ExcelのVBAでの話になります。

RangeオブジェクトのFindメソッドを使用し、指定された値を所持するセルの行位置を取得する処理を組み入れた業務APを開発される際の注意喚起になります。

実際の業務APの内容をお見せすることは出来ないため、デフォルメ化したサンプルAPで説明させていただきます。

※サンプルExcelファイルのダウンロードはこちらからどうぞ。

<サンプルAP仕様>
シート「Sheet1」上の表より、指定された値を所持するセルを探索しその行位置を結果としてメッセージ表示する。

先ずは、シート「Sheet1」の内容になります。
excel_01_00_data

 

そして、当初開発時のソースコード(VBAマクロ)

Sub 一見問題のないように見える書き方()

 Dim l_Row As Long   '探し物の行位置

 With Sheets("Sheet1")

  '■探索範囲に存在する"くじら"を探索
  l_Row = .Range("A:A").Find("くじら").Row

  MsgBox "探し物の行は[" & Format(l_Row, "#,##0") & "]です。"

 End With

End Sub

 

これを実行すると正常に処理されます。
excel_01_01_ok1

 

しかし、下記のソースコードのように探索値を変更してみたところ・・・

Sub 問題が発生します()

 Dim l_Row As Long   '探し物の行位置
 
 With Sheets("Sheet1")

  '■探索範囲に存在しない"ことり"を探索
  l_Row = .Range("A:A").Find("ことり").Row

  MsgBox "探し物の行は[" & Format(l_Row, "#,##0") & "]です。"

 End With

End Sub

 

Findメソッドの実行行で、このように結果がエラーとなります。
excel_01_02_ng1

しかも、withブロック変数の設定が原因とのこと・・・・

見てのとおりwithブロックの書き方に間違いは見られない。

しかし、エラーはwithブロック変数・・・これは困りました。

 

諸々の情報収集と検証をしたところ、原因は本当につまらないことでした。

Findメソッドで条件該当するセルを探索することが出来ないにも関わらず、Rowプロパティを要求したため「Rowプロパティを返したいけど対象のセルがありませんよ!」というエラーだったようです。

つまり、下記のソースコードのようにオブジェクトとメソッドとプロパティの3連続ピリオド結合を止めて、正しく途中経過を判定すれば良いだけだったのです。

Sub 皆様このように書きましょう()

 Dim l_Range As Range   '探し物の結果セル

 With Sheets("Sheet1")

  '■探索範囲に存在しない"ことり"を探索
  Set l_Range = .Range("A:A").Find("ことり")

  '■探索結果を判定する。
  If (Not l_Range Is Nothing) Then
   MsgBox "探し物の行は[" & Format(l_Range.Row, "#,##0") & "]です。"
  Else
   MsgBox "探し物はありませんでした。"
  End If

 End With

End Sub

 

その結果は、このとおり正常に表示されました。
excel_01_03_ok2

 

ExcelのVBAコードを記述する場合、このようにオブジェクト.メソッド.プロパティのように連続したピリオドで結合し、ソースコードの記述を楽したいと思う心情は私も理解します。

しかし、お客様へ納品する業務APとしてVBAコードを記述する際は、このような楽をすべきではありません

今回の記事では、Findメソッドを例として記載しましたが、Findメソッド以外の他のメソッドの場合も考え方は同じです。

 

今回は、このFindメソッドの原因を究明するために、本来なら出さなくてもよいあぶら汗を約1時間も出しながら苦戦することになりました。

「作れば良い」「動けば良い」ではダメなのです。

「保守しやすいか?」「エラーが発生した場合、原因究明しやすいか?」を念頭に置いて、プログラマ諸君にはVBAコードを書いていただきたいものです。

 

(検索キーワード)
オブジェクト変数または With ブロック変数が設定されていません。

IF文に書く条件文の記述順序・・気にしてますか?

先日、あるソースコードをレビューする機会があり、その際に考えさせられたことを記載します。

プログラマなら、誰しもが多用するIF文のことになります。

このIF文に記述する条件文ですが、下の例ように個々のプログラマの考え方もしくは趣味趣向により「条件文の記述順序」、「条件文を肯定式から組み立てる」、「条件文を否定式から組み立てる」ということが日常的に思考され世の中のプログラムコードが生まれているものと思います。

また、このIF文の「条件文の記述順序」、「条件文を肯定式から組み立てる」、「条件文を否定式から組み立てる」といった記述思考はプログラマの自由でもあると思います。

例)肯定 太郎くんの考え方
「俺は、イコール判定(何々である判定)が好きだから、イコールを最初に記載するようにしている」

例)否定 花子さんの考え方
「私は、ノットイコール判定(何々でない判定)が好きだから、先ずはノットイコール判定を書いてしまう」

しかし、今回遭遇したソースコードにおいては、エンドユーザーの思い(心理要望)を組み入れて条件の優先順位を記述すべきと判断しました。
今回の事例を少し味付けして架空のエンドユーザーに見立てて、下記の課題で説明したいと思います。

 

【顧客から要望された課題仕様】

(仕様1)
生産ラインで稼働する製品品質評価システム(以降、評価システム)がある。

(仕様2)
この評価システムで製造された製品が検査評価され、個々の製品に対して「品質区分」という
 変数に以下の品質結果(値)が返される。
 
  0:正常品(出荷可能)
  1:要検査(再検査が必要)
  2:部品確認(部品欠落の可能性あり)
  4:不良品(確実に部品欠落あり)

(仕様3)
「品質区分」の値別にそれぞれの処理(正常品処理、要検査処理、部品確認処理、不良品処理)を実施させたい。

(仕様4)
本処理の評価判定で「品質区分」が0(正常品)に該当した製品のみ出荷対象として、次のサブシステムへ連携したい。また、間違いなく正常品のみ出荷対象となるようにして欲しい。(誤って正常品以外の状態の物が次のサブシステムへ連携することは許さない)

 

★ プログラマAさんの記述した「IF文」

If ( 品質区分 = 0 )Then
  ”正常品”の対応処理を実行する。
 
ElseIf ( 品質区分 = 1 )Then
  ”要検査”の対応処理を実行する。

ElseIf ( 品質区分 = 2 )Then
  ”部品確認”の対応処理を実行する。

Else
  ”不良品”の処理を実行する。

End If

 

★ プログラマBさんの記述した「IF文」

If ( 品質区分 = 4 )Then  
  ”不良品”の対応処理を実行する。
 
ElseIf ( 品質区分 = 2 )Then
  ”部品確認”の対応処理を実行する。

ElseIf ( 品質区分 = 1 )Then
  ”要検査”の対応処理を実行する。

Else
  ”正常品”の処理を実行する。

End If

 

私見ですが、このエンドユーザー要望の場合「プログラマAさんのIF文」がユーザー要望(ユーザー心理)を配慮している記述になっていると判断します。

エンドユーザー側の立場で考えると、以下のような思考になるはずです。

「品質区分が0(正常品)の時の製品だけ、間違いなく消費者へ出荷したい。少しでも不良品側に属するような状態の物は、後のクレーム補償のリスクを考慮し、まずは一律で不良品として判別したい」

つまり、「品質区分=0」の時は、真っ先に「品質区分=0(正常品)」の判定条件を満たし「IF文条件群」を抜け出し、その後の判定ロジックを無視し、間違いなく”正常品”の処理を実行すべきと考えます。

「プログラマBさんのIF文」だと、品質区分が4、2、1の判定条件を正しく抜ければ間違いなく0(正常品)として処理されます。しかし、本番リリース後の長期に渡るシステムライフサイクルの過程で、前段の品質区分条件が誤った状態に修正をされると、本来真っ先に判定条件を抜け出して欲しいと考える「品質区分=0(正常品)」が正常に判定されなくなるかもしれないというハラハラ感があります。例えば、下のプログラマDさんのような改修が発生すると「品質区分=2(部品確認)かつ部品区分≠3」の状態が”正常品”として判定されてしまいます。もちろん、この改修を行ったプログラマDさんが確実に試験作業を行えば、この問題に気が付き適切な改修を行うものと期待はしますが・・・

★例えば、プログラマBさんの作ったロジックを、新人のプログラマDさんが誤って改修

If ( 品質区分 = 4 )Then
  “不良品”の対応処理を実行する。
 
ElseIf ( 品質区分 = 2 )And ( 部品区分 = 3 )Then
  “部品確認”の対応処理を実行する。

ElseIf ( 品質区分 = 1 )Then
  “要検査”の対応処理を実行する。

Else
  “正常品”の処理を実行する。

End If

 

【本記事の結論】
本システムの初期リリース時点においては、「プログラマAさんのIF文」と「プログラマBさんのIF文」は同じ機能を有し、同じ品質を有しているといえます。しかし、長年に及ぶシステムライフサイクルの過程で行われる保守メンテ改修を加えていくことで両者の「IF文」のコード形態が変わってくるはずです。前段でも述べましたが、IF文の「条件式の記述順序」、「条件文を肯定式から組み立てる」、「条件文を否定式から組み立てる」ということはプログラマの自由です。これは間違いありません。

私が本記事で述べたいことは、エンドユーザーの立場からみた要望仕様もしくは心理要望が見えた場合(読めた場合)は、これを考慮してプログラムコードを記述すべきではないかということです。

例えば、もし上述の課題でエンドユーザー側の心理要望が以下の場合、今度は逆に「プログラマBさんのIF文」が適切な記述方法といえるわけです。

「品質区分が4(不良品)、2(部品確認)、1(要検査)の時の製品を、それぞれの不良度合いに応じた改善対応部署へ間違いなく連絡し、相応の改善処置を要請したい。」

 

皆さまは、本記事を見られてどのように思われましたでしょうか?

 

 

【余談】
私なら、上述の課題を以下のように記述します。 最後のElseは将来の誰かが、誤って改修しても他部位に影響が出ないようにこのように考慮記載してしまいます。よく、同僚から「石橋を叩いて壊す」なんて言われる次第でして・・・(苦笑)

If ( 品質区分 = 0 )Then
   “正常品”の対応処理を実行する。
 
ElseIf ( 品質区分 = 1 )Then
  ”要検査”の対応処理を実行する。

ElseIf ( 品質区分 = 2 )Then
  ”部品確認”の対応処理を実行する。

ElseIf ( 品質区分 = 4 )Then
  ”不良品”の対応処理を実行する。

Else
  不明状態の処理を実行する。
        ※本ケースは理論上はありえないケースになります。

End If

 

机上デバッグ(その2)・・いろいろな方々の考え

先日、公開しました「机上デバッグの記事」に関しての続きの記事になります。

Web上を検索すると、私と同じような考え方(思い)を持つ諸兄姉方々が沢山いらっしゃるようです。

一部ですが、上記の諸兄姉方々の記事を引用記載させていただきたいと思います。

 

(1)SOUM/misc殿のサイトより引用

しかし、コンピュータ上でのデバッグの際、机上デバッグによりソースコードを十分に把握していたため、コンピュータ上でのデバッグの際に、問題場所の特定が比較的楽に行なえました。

私は、ここで言う「ソースコードを十分に把握していたため」というところに強く共感します。机上デバッグを行うと、間違いなく自分の作成したプログラムコードの全容を把握できるんです。

あるときの話になりますが、若手プログラマ(以降、彼と呼称)に彼の作ったプログラムについて、「ここの処理が終わったら、次はどのようなパターンで処理が動くの?」と聞いた際に、「全ての処理を把握していないため、判りません。」と答えられたことがありました。まったく、情けなく思いました。プログラマは、自分の作成したプログラムコードの全容を把握しておくことは絶対的な義務だと思います。

そうでなければ、いったい誰がそのプログラムの全容を把握し、その処理内容に責任を持つのでしょうか?

 

(2)アイロベクス社殿のブログサイトより引用

現在は動かしながら確認できるデバッグ実行ということもできますが、これが非常に危険な要素を含んでいます。実はきちんと動いているように見えて、中ではまったく別の処理が走ってしまっているとか、たまたまAとBの値が一緒だったから動いていたものの、BがCに変わった途端動かなくなってしまったなどということもあります。

実際にはすべてのテストパターンが網羅されていれば気がつく問題かもしれません。しかし、机上デバッグさえしっかりしておけば、テストの前に発見できるバグがいくらでもあることを忘れないようにしましょう。

ということで、アイロベックスでは机上デバッグは必須です!

この方が言われている「実はきちんと動いているように見えて、中ではまったく別の処理が走ってしまっているとか・・・」が大事なんです。机上デバッグを行うことにより、トラブルの原因となりそうな箇所や、潜在バグとなりうる箇所をトラブルが起きる前に確実に修正することができるのです。これを行うか否かにより、納品後の顧客から信頼を得られるか否かが決まることも少なくありません。

 

(3) 傲慢SE日記 ~個人事業主として獅子奮迅中(TownSoft)~殿のブログサイトより引用

 

頭の中のコンパイラ

私は机上デバッグが出来ない人はプログラマとは認めません。

この方は、少し辛口の表現で記事を書かれています。しかし、記事の内容は至極真面目で正しい内容だと私は評価します。最後の赤字の文言には、少なからず私も同意見です。また、「頭の中のコンパイラ」という表現も良い表現だと思います。まさに、若手プログラマには、この「頭の中のコンパイラ」を育てて欲しいものです。

 

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

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

 

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

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

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

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

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

一例になりますが、とある会社のプロジェクトに参画した際に、あるプログラマ(以降、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

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

 

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