唠叨唠叨

有一套光鲜的球服和一个稳固的后防对于一支球队来说是远远不够的。
    程序也是如此，把业务的设计和实现统统交给最底层的程序员去处理，又不加以规范，那么就像一支球队把中场组织的重任交给了一个我这样的草包，输球是必然的。
    不知道其他公司的其他系统是不是也这样：做好一个framework或者弄上一个基础类库，再草草的弄回来一个需求，ok！开发把你！！
到了现场，先开上上个把月的会，你和客户吵啊吵啊，终于你被客户整挺了，客户说鹿就是鹿，说马就是马。针对程序客户给你提出了3013各问题，个个问题都打到你的软肋上，你整理出来2847个------客户说：你态度有问题！于是问题的个数变成了：3012个。
    这些问题颠覆了你对需求的理解，也颠覆了你的设计，还有一些明显很不合理，这时候你还要留一手：作出一个合理的，等着客户醒悟过来。
    说到开会，你怒了，你知道除你之外，来到桌上的都是领导，是领导就有激情，是领导大脑就会充血。领导a说：这个功能我们要这样做！

b说：这样不行我们要那样。最后大领导拍板了：原功能保留，但是这样行，哪样也得行。ok，今天周五，星期一我们看，散会！
    你无语了！周末你拼了，那还将什么设计呀，那还顾得上程序的优雅？！终于你应付上了，交给他们，你认为这下应该满满足了吧？！谁知道一阵指指点点后，大领导一拍板：恢复到原来把！你再次无语。
    客户向来都是这样喜欢做“激 情需求”的，你必须对业务烂熟于胸，你必须对业务比做过的还做过。
    由于问题多多，程序上线推迟了一个月，项目经理很不满，你胆战心惊的做你负责的模块，你发现给你一年差不多。你丝毫不敢松懈。这时候你想起来了：程序需要优良的设计。你对经理说：我们的模块间应该解除耦合，经理一脚把你从29楼踢出去。你对小弟说：我们应该面向接口编程，小弟很委婉：你怎么不去死？。。。。。。。
    -------牢骚先发个半截。
    于是赶工赶期，投入战斗，你心里明白，大家都在写代码，都在创造垃圾，唯一不同是将来维护的重任可能离不开你，也就是说：大家一块拉 大 便，但是你负责擦屁 股。（原谅我这么粗俗，我现在无法平静）。
    。。。。。。。。。
    。。。。。。。。。
   综上所述，才有了我那“在form里完成业务逻辑有何不妥？”这样愚蠢又严肃的问题。