今後の開発に役立てていきたいです。
１．システムが遅いというのは最大のバグ。データが正しくないより大きい。
・今のシステムはレポートが１個５分程度掛かります。（２００件程度のデータ）
そうなると正しいかどうかチェックするのに５分掛かるという事。
これだけ遅いと以下の悪影響が考えられます。
・品質も下がる（結果をチェックする頻度が減る）
・顧客の生産性も下がる。→顧客満足度も下がる。
２．DBの作りがクソだとプログラマはバグを作りこんでしまいます。
＜DBの正規化について＞
・僕はDB正規化に賛成です。ただパフォーマンスが要求される所には、 正規化をあえて崩すのも有りだと思っていますが、あくまで限定的であるべきでしょう。
プログラマにこれもこれも同時に更新と言うのは無理がありますし、レポート出力等のデータ取得の際に 正解が２つあるのも誤りを生む原因になります。
＜DBのセオリーについて＞
・他人との意見を一致させてDBは設計すべきでしょう。奇策を用いて良い結果を招くことは、この世界では絶対にありません。奇策を用いる場合は開発の人間全員の意見の一致を持ってやるべきでしょうが それも開発の人間はしばしば入れ替わるという事を考えるとオススメはできません。
例えばIDという項目があった場合、通常はIDのみでユニークになると思いますが、あるシステムは何らかの区分＋IDでユニークになる場合があります。その場合はIDではなくて、何たら番号等にすべきだと思います。
３．一貫性がない。
・命名規則であったり、DBの作りであったりするところには、一貫性をもたせる必要があります。例えばDBフィールドの命名があるところは、BARCODE、あるところがBCode あるところ、BRCODEとなっているシステムがあります。どれも同じ意味なのに… 正直こういうシステムを見るとやる気がなくなりますし、絶対に品質は低いです…
４．プロセスは少ない程良い。
・正直、無駄なプロセスが多いとやる気を失います。
この辺は正直バランスが大切だと思いますが…
＜１．単純なシステム＞
・伝票入力→締め処理
＜２．普通のシステム＞
・伝票入力→伝票承認→締め処理
＜３．複雑なシステム＞
・伝票入力→伝票承認→入力締め処理→残高更新
※僕は理想は「１．単純なシステム」だと思いますが、
承認が無いと不安な人が多いので「２．普通のシステム」だと思います。
ただし、３は無いと思います。なぜなら、入力締めも残高更新も
同じ締め作業で人間のイベントで残高更新というイベントはありません。
→そんなもん締めた時に勝手に更新しろよと思うわけです。
→基本的に人間ベースでのモデリングにすべきで、
システムの都合をモデルにすべきではありません。
そうしないと処理をミスして戻る時に、
残高更新キャンセル→入力締めキャンセル→伝票承認キャンセル→伝票修正
→伝票承認→入力締め→残高更新という作業をする必要があります。
アホらしいくらい面倒臭いですよね。人間誰しもミスくらい犯すというのにですよ…
※これが単純なシステムなら、締めキャンセル→伝票修正→締め処理
という簡単に戻れるようになります。こっちの方がどう考えても人間的ですよね。
※もし伝票承認をするのであれば、毎日承認すべきでしょう。
それであれば、毎日サインした分だけ承認をするというプロセスが出来上がります。
これを本当に人間がやっているのであれば、システムとして実装すべきでしょう。
コードを綺麗に書くことも大切ですが、上記の基本的な設計も大切だと思います。肝に命じていきたいと思います。
