変換コスト

ソフトウェアを作る工程などに関して、ふと考えたこと。

構造化プログラミングは、2次元的なイメージを受けるのに対し、OOPは、3次元的なイメージを受けます。

フローチャートやエクセル表の設計書は、2次元的なイメージを受けるのに対し、UMLは、3次元的なイメージを受けます。

お客さんの要件は、言ってみれば4次元です。

仕事でプログラムを作る手順は、極端に端折ると、設計者が、お客さんの要件を設計書に変換して、プログラマが、設計書をソースコードに変換してる。要するに2段階に変換してる。

構造化プログラミングの時代

お客さんの要件(4次元)を、設計者が2次元の設計書(フローチャートとか)に落し込んで、プログラマが、設計書を2次元のソースコード(構造化プログラミング言語)に変換する。

自然です。

OOPの時代

お客さんの要件(4次元)を、設計者が3次元の設計書(UMLとか)に落し込んで、プログラマが、設計書を3次元のソースコード(OOP言語)に変換する。

自然です。

でも実際には、UMLって難しすぎてチーム全体で使いこなすのは至難の技です。 UMLだけでうまく回っている、ある程度大きなプロジェクトは見たことがありません。

かわいそうな現在

お客さんの要件(4次元)を、設計者が2次元の設計書(さすがにフローチャートは無いけどエクセルベースの何か)に落し込んで、プログラマが、設計書を3次元のソースコード(OOP言語)に変換する。

4次元→2次元→3次元。激しく不自然です。

自虐的すぎる。

コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です


reCaptcha の認証期間が終了しました。ページを再読み込みしてください。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください