  |
色々開発に携わってきたが大体2パターンある
Case month when 1 then ~って感じのコード。thenの後にif文や更にCase文がある。この辺りに28日までとか書いてある。
ソースレビューがあったら指摘する内容だが機能していない場合はこのレベルが来る。オフショアで海外に出すとマジでこんなの書いてくる。指摘するとはいはい言うけどどうすれば良いのか悩む。
アーキテクチャ次第だが単に29までに変更すれば良い場合もあるが、たまに他にも影響したりして結構絶望する。月末日取得で書いてたら説教レベル
大体Case文パターンでロジックが考えられない場合国内外が提案してくるのがマスタ化だ。発注元も何故か柔軟な対応が出来るからと賛成してくる
結果年1や月1のマスタ設定が必要になり運悪いタイミングで担当者が閏年を忘れてると大体起きる。賛成した人らは運用しないので気楽だ。
こっちはマスタ設定すれば良いのだが、閏年ですよ忘れていませんかチェックは無いくせに登録出来るのは翌日以降チェックはしっかり入ってたりする。
設計段階で考慮すれば良いのだがマスタは何故か新人の仕事となり結果糞仕様にスキル不足が重なって復旧に時間がかかったりする。もちろん新人に罪は無い。日付をキーにするマスタなんて要件で考えた奴が悪い
閏年に影響されない業務やフローにする。そもそも年月日を指定するか2/28の次は3/1だと明示しない限りはシステムは閏年でバグを起こさない。
もし日付チェックを自作の変なロジックで作って発生させてたら20代なら許すが30代以上は即引退して他の仕事探したほうが良い。変に生き残って上流に行くと出来上がるのは意味の分からない事を言うステークホルダーという老害で将来はコンサルとか名乗って中小零細で惨めなシステム論を語る粗大ゴミだ
1
