老エンジニアたちの挽歌３

Laravel開発を進めて２か月目、事業主が要望をだした。

事業主「休み判定したい」

私「休み判定とはなんですか？」

この塾は、通塾内容により、休みの種類がある。

大きく分けると、２種類だが、

細かく分けると、８種類があったかと思う。

ちなみに、後々、私が業務分析したところ、

休みの種類が２種類と、それ以外の要素が２種類で、

２×２＝４通りだった。

その休み判定をプログラムで自動化し、講師の入力間違いを防ぐといった内容である。

私「現在、学習管理の開発をしていますが、止めますか？」

事業主「なるほど、じゃあＡさんにやってもらいましょう」

この時の判定が、２年以上の負債になるとは、思っていなかっただろう。

このとき

Ａさんにやってもらう

というのがどうしてもひっかかった。

なぜなら、Ａさんが作った単語テストのプログラムを見たことがあり、

サロゲートがなかったり、ＤＢが正規化されてなかったり、

新規で作ってるのに使ってないフィールドがあったりと、

設計スキルがかなり怪しかった。

余談だが、Ｒ５０の作るシステムはなぜだか、サロゲートがありません。

複合キーだったり、idだったり、noだったり、idとno並列でもっててどっちやねんだったりします。

また、サブテーブル作らず、フィールド横持ちする傾向にあります。

（price1 , price2 , price3 , price4・・こんな感じの）

２か月後、Ａさんはカレンダーのようなテーブルを設計していた。

パワポで設計したと思わるテーブル設計書だ。

事業主「（私）さん確認してください」

私「承知しました」

ＰＤＦファイルがGoogleドライブにアップされていて、

リンクが共有されている。

そこに、コメントを入れる形で確認した。

大体、先述した通り、

キーのフィールドが壊滅的な状態だった。

あるテーブルには、user_id , student_id , teacher_idというフィールドがある。

student_id × teacher_idでマンツーマン授業のようなものを再現しようとしているのであろうことは想像できる。

user_idって何？

私「user_idってなんのidですか？」

Ａ「事務員のidです」

私「じゃあ、student_id と、 teacher_idが使われるとき、user_idは何が入りますか？」

（その時は使わいませんといってくれるだろう・・　（どきどき））

A「生徒のidが入ります」

私「は？、いや入れる意味ないでしょ」

A「じゃあ、いれないほうがいいですか？」

私「そういう問題じゃない、設計が良くないって言ってます」

私「そもそもこれだと、グループレッスンのように講師：生徒が１：Nの予定を再現できません」

A「できますよ！」

私「え、どうやって・・」

A「同日時で、同じ講師に生徒idが違うレコードがあればできます」

私「それだと、同日時のマンツーマンがN個ある状態になりませんか？

　　画面で再現するときにどう、表示を切り替えるんですか？」

A「考えてなかったです」（オイ）

私「あとuser_id , student_id , teacher_idですが、

　　従属するテーブルの推測ができません（users , students , teachersのようなテーブルがないです」

A「そうなんですよね。もともとの作りが、memberってなってて、member_noってなってるからつかいにくいんですよね」

私「そういう問題じゃないと思います。」

：

こういった感じのレビューをした。

しかし、Aさんは私のレビュー内容を理解できず、自分の設計が正しいとごり押しする。

そして、グループレッスンに関する休み判定ロジック追及があり、断罪されるのであった。

事業主「なぜグループレッスンに対応できてないんですか？」

A「考慮していませんでした」（オイ、レビューしたぞ・・）

私「２か月前にレビューしたときに、指摘しましたが、

　　（おや～直さなかったんですかぃw）」

事業主「グループレッスンに対応できるようにしてください」（無理だな）

A「わかりました！」

この休み判定というプログラムは、内容的にただの関数モジュールだと思うが、

Aさんは半年以上かけても完成できなかった。

（なぜなら、設計が破綻しているからだ・・）