設計書の最終段階「プログラム設計書」
プログラムはプログラム設計書通りに作成されます。
当たり前の様に聞こえますが、この当たり前を意外と皆さん忘れてません？
コーディング作業は設計書通りに作る工程です。
プログラマーの仕事は設計書に書かれている内容が過不足なく実現する事何ですよねぇ。
だからプログラム設計書は網羅的に記載されている必要があります。
共通認識ないでの記載の省略はあっても「コーディング時に検討」なんてものは存在しません。
まさしく大工が設計しながら建築をするようなものです。ありえないでしょ？
かの赤い彗星もこうもうしております。
「プログラミングの腕の差が戦力の決定的な差ではない事を教えてやろう」
まさしくその通りでコーディング作業の生産性は設計書が握っています。
と言う訳で現場で見た。こんなプログラム設計書はダメだ！をお送りします。
こんなプログラム設計書をコーダーに渡しておいて「作業が遅い」やら「バグが多い」とか言っている人がいたら張り倒して良いレベルですね。
それでは紹介していきます。
その１：プログラム設計書が論理名で記述されている
「社員名に名前を設定する」
これ、もうプログラム設計じゃないでしょ？
プログラム設計書に論理名しか書かれていない。
プログラム設計書に論理名だけ書くんじゃない！と言いたくなります。
っていうか、その日本語ってお前が使っているのはぴゅう太か！？と言いたくなります。
物理名から論理名をいちいち調べるの面倒なんだよ！時間の無駄です。
プログラム設計書は物理名や実際のメソッド名、関数名を記載する様にしましょう。
「社員ID」とか「設定値から〇〇を取得する関数を呼ぶ」などはプログラム設計書としては不向き。論理名から物理名に変換する処理をプログラマーがする必要があります。この脳内変換が無駄です。
DIO様風に言うと
「無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄ァーーーーーーーーーーッ！！！！！」
生産性ダウンです。わかってるなら教えろ！と言いたいですね。
そして、この状況ってどういう事かと言うとプログラム設計の段階でクラス設計やら関数設計やらが完了していないって事ですからね。まぁ、ヤバいですよね。
その２：ケースに抜け漏れがある
if文の行き先の無いプログラム設計書。
無処理のまま次に行くんすか？マジっすか？って時があります。
コーダーが気が付くくらい経験のある人だったら良いんですが、大体見逃されます。
そして、単体テストをすり抜けて痛い後遺症をもたらします。
もっと厄介なのが「勝手に埋めるクン」が登場する可能性があります。
どんなタイプか？はこちらの記事に書いてありますので読んでみてくださいね。
後工程に遺恨を残すか余計なプログラムを書かれるか。どちらにしても生産性は下がるのが確定的に明らかです。
その３：GoTo思考で書かれている
現代のプログラムでは禁忌とされている「GoTo」
ラピュタ語の「バルス」に匹敵するほどの言葉なのだが、プログラム文に書かないまでも設計段階ではバリバリにGoTo思考になっているケースがある。
そんなGoToを想起させる記述がで書かれている事がままあります。
例えばこんな記述。
———————–
[入力されたメールアドレスに対してメールを送付する]
１.アカウントの存在チェック
アカウントテーブル.メールアドレス ＝ メールアドレス
→存在しない場合
エラーメッセージを表示し、処理終了
→存在する場合
「２.メール送信処理」に進む
———————–
順次処理にも関わらず、敢えて「進む」の記載。
たったこれだけ？と思うかもしれませんが、結構デカい。
これ、実際にどんなプログラムが書かれるかわかります？
アナタが思っている通りに書いてもらえますか？
ダメなんですよ。コーディングする人に選択肢を与えては。
コーディングは本当に設計書通りに組み上げていくだけ。
これを見てGoToを使われても文句を言えない状態です。
だっとそう書いてあるんだもん。常識とかそういうのじゃなくてそういうもん。
コーディングの時はただ設計書通りに作れば良い状態にする
プログラム設計書を作成する時に一番大切な事です。ある意味作業指示書です。
コーディング段階でうだうだ考える必要はある場合、間違いなく設計不足です。
コーディング時に考える事がある。それだけで生産性が大きく落ちます。
「それくらい読み取ってくれると思っていた」はエゴです。単なるエゴ。まぁ、これを言い訳として口に出した瞬間終了です。
まさに逆、勝手に漏れを埋めない作業者が正しい判断したと言えます。
疑問に思って相談するのが正しいですけどね。
まとめ
どうでしたか？
大きなプロジェクトほど設計者とコーディングを行う人が別々になる事が多いですよね。
最近はアジャイルやスクラムなどの開発が増えてきたとは言え、昔ながらの大型ウォーターフォール案件も多いですよね。
あと、「プログラム設計とコーディングを他の人にやらせる体制が悪い」言い出す人もいます。そういう事じゃないんですよねぇ。プログラム設計書に対する基本的な考え方であって、この考え方が理解できていない人は、結局設計とコーディングを自分でやっても同じような苦労をするでしょう。
という事でプログラム設計ちゃんとしましょう！
コメント