【開発哲学3_9】〜『CODE COMPLETE第２版　第９章(上巻)』の感想〜疑似コードによるプログラミング

感想

疑似コードプログラミング（以下、PPP）。

PPPは今でもよく使う。
第２部の手法を全て絡めて、自分なりにコードやタスクを管理しやすいように、応用して使っているけど。
個人的には、ここが今まででは１番実務で日頃意識して使っているなあ。
次から第３部。
いよいよ変数✨楽しみ🕺

詳細

見出しとしては、

1. クラスとルーチンの作成手順の概要

2. PPP

3. PPPを使ったルーチンの作成

4. PPP以外の方法

5. まとめ

て感じ。

PPPについては、

ここまで詳しくはないけど、VBAの資格本でもベーシックに載っていて、
コードを起こすときには余計なバグとか思い違いが発生しそうな時は、特に今でも必ずやるねえ。

よく考慮漏れを起こす人ほど、

（まあ、使った教科書とか通った学校、周りのプログラミング仲間などの影響なのかもしれないけど）
PPPを端折って、いきなりコードをベタ打ち（＝ハードコーディング）で、書いて、結果よくコードが通らなかったり、接続が重くなったり、無限ループになったり、潜在バグを見落としたりしてるなあ。
しかも、コードが読みにくく、コメントもなかったりで、その潜在的なバグに気付くのが数ヶ月後に、一番嫌なときに起きたり、、、。

でこちらが

何年経っても、PPPでどんな簡単な初期段階でも起こしたりしていると、何を勘違いしてるのか

コードを直に書かずに、人間のわかる言葉で書く　＝　素人

って即断して見なしてくる。

こちらは手戻りや考慮漏れが発生しないように、
なるべく慎重に、
コードを書く前に洗い出して、
確認しているだけなんだけど、、、。

例えば、

データベースに書き込む処理をするとしたら、

function データベースに書き込む(){
  データベースに接続する();
  もし、データベースに接続できたら{
    データベースを開く();
    もしデータベースを開けたら{
      データベースに書き込む();
      データベースを閉じる();
      データベースから切断する();
    }　開けなかったら {
      開けなかったログ残す。
      再度、データベースを開きに行く。
    }
  }　接続できなかったら {
    エラーを表示させる。
    再度、接続する。
  }　
}

て感じで処理が成功する場合と失敗する場合を思いつくままに書き出す。

こうやって、他に考慮しないといけない手順とかエラー対策はないかなあって洗い出して、つながりや漏れがないかなあって確認してからコードに起こすだけ。

「うちは、詳細設計やランチャート、フローチャートなんかでやってるから大丈夫」
って人も多いと思うんだけど、いくら設計図があっても、

設計図どおりにちゃんとコードにしているか

は別問題だからね。

• 処理を人間の言葉で書いて繋がらない

• 良いルーチン名を付けられない

👉まだ、設計が上手くいってないし、バグが発生する危険度高い

さっきの例でいえば、

データベースに何かしら処理を行うときに、書き込みとか更新の処理は書くんだけど、

データベースに接続した後で、用事が終わったら接続をきちんと切る

処理を入れず、ずーっと接続されたまま、セッションが増えて、ひとつひとつの処理が重くなっているのに、

なんで処理が重いんだろう？もっと処理を高速にするコードはないか

と、コードが原因じゃないのに、コードばかり調べるかっこいいコードを組もうとするなんて人をよく見かける。

まさに、

プログラミングの格言：
「鍵を落とした場所が暗いからと、明るい場所で落とした鍵を探し続けても、鍵は一生見つからない」
👉問題の主要因がコードではないのに、コードばかりを追い続けても、問題は解決しない。

電源の入切スイッチで例えると、

部屋の電気なら、

入れる⇄消す

ように電源入れる機能だけ付けて、消す機能を付けないなんてしたら、ずっと電気が消せないままだから大変なことになる。
言われりゃ当たり前のことなのに、とかくプログラミングになると反対の機能をつけ忘れる人多い。

開いたら閉じる
表示したら非表示にする
接続したら切断する

ACCESSでいえば、

クエリの処理が遅いだけならば、ADOとかDAOみたいな他の高速処理をする方法を探すこともあるけど、それが原因ばかりじゃないしね。

まとめ

急がば回れ
目先の時間を惜しんで、やみくもにコードを書いて、10倍の時間と信用を失ったら意味がない。
現場のプログラミングはある意味、これが全てかも。

てことで第２部終わりー！