デザインパターン

 プログラマーではない設計者に教えるのが難しくて苦戦しているのが、チェックなのよね。(´・ω・`)

( ﾟДﾟ)「この項目は必須チェックです」
( ﾟДﾟ)「マスタを検索して存在しているかをチェックして下さい」
( ﾟДﾟ)「半角英数字チェックもお願いします」

これね～、明確に序列があるのよ。

必須チェック⇒半角英数字チェック⇒マスタ存在チェック、の順だ。

これね～、当たり前なのよ。

MVCモデル、バリデーションチェック……、言葉は色々あるんだけど、考え方の根本は同じ。

まず外から入って来たインプット情報のみでチェック（バリデーションチェック）し、それを通過した後でＤＢとの突合などのチェック（ビジネスチェック）を行う。

これは基本中の基本であり、これはWeb画面でも、WebAPIでも、ファイル入出力バッチでも、同じ。

チェックの順番には定石がある。これをデザインパターンと言う。

ただ、これが厳しいのは、そもそも何故デザインパターンというものがあるのか？
それはデザインパターンに即さなければ設計が綺麗にならないからだ。これは保守性と効率に密接に結び付く話だ。

だか、プログラマーではない設計者はデザインパターンという概念が無い。

( ﾟДﾟ)「え？　マスタチェックした後に半角英数字チェックは出来ないんですか？」

とか、そういう出来る出来ないの話をしているんじゃないんだよ。

デザインパターンに即した設計にしなければ、必然的に生産性は低く、保守性も低いシステムに成り下がる。これは常識だ。
生産性と保守性の話だ。

だが、この設計者はプログラマーではないから、デザインパターンという概念を理解していない。
だから出してくる設計書も処理の順序が滅茶苦茶である。
無論、ここは守って貰わないと実装するわけにはいかないから、こういう設計が来たら指摘して突き返している。クソ設計を拒否するのはプログラマーの職責だからな。

でもこの、「デザインパターンという概念を持っていないが、設計者ではある」、というケースが実に厄介で困っている。

もちろん突き返す時に理由は説明はするんだけど、５分や１０分の指摘で理解するのは難しいだろう。最低でも８時間くらいは勉強会開いて僕がレクチャーしないと。

でもそんな時間あるわけ無いし。

いや、プログラマーでなければ設計は出来ないと言うつもりは無いんだけど、だからと言って基礎を勉強しないままフワッと設計をやられてもね。

う～ん。(´・ω・`)