这里绝对不是吐槽，只是记录一个非常搞笑的事情。

台企业向来以绝对的服务称道，即使客户 Naive ，Simple。作为银行的网站，在项目快上线的时候，一声惊雷传来，将所有逻辑实现类的代码拷贝至 一个logic.cs类中，将所有实体类拷贝至Model.cs类中(实体名字按照XX_001、XX002、XX003...命名)。没错,没有听错，老夫驰骋项目多年，第一次听过如此奇葩的要求！！！给出的理由绝对惊讶： 客户懂代码，逻辑类分开写看的不舒服！

这个荒唐的理由下，需要做的处理：

①原来面向各个界面的逻辑实现类的类名以序列编号重命名的形式全部拷贝至Logic.cs中

②所有实体类拷贝至Model.cs类中

③所有的控制器中调用的方法全部重新设置路径

④所有视图中引用的实体类文件路径重新设置

⑤对翻新后的文件进行测试

想象着完成之后，整个项目简洁明了（光秃秃），尤其是逻辑层就两个类文件，无任何文件夹，仅仅只有一个Logic.cs 和 Model.cs 两个文件，后期的维护怎么做？哦，不是，客户懂点代码，想着是，文件个数少，以后维护可自行动手，不用再花钱。这算盘。。。

粗略算了下，负重的Logic.cs文件 里面会有近20K行的代码。整个项目翻新一遍，加上测试，两个人差不多需要四到五天的时间，说不准，一个星期之后，客户又觉得不好，还能再改回来，毕竟这样的事情经常发生，作为一名有追求的码农，向来是凭良心做事，一步一注释，十步一备注，步步才能走的稳呐。尤其是对于修订他人的代码，必须做好注释（时间，内容，名字）。这也算是在大公司工作这么久换来的觉悟吧。

一名开发人员，尽量以最优、最简明的算法去对待项目。如果客户什么都不懂，那么我们给出各种方案，客户认可的标准就是 运行正常、（高效）、简单操作。恰恰如果客户懂点代码，但是又是那种仅仅懂点皮毛的门外汉，那真是叫痛苦，想来什么就是什么，需求没有不合理之说，如果界面管，代码结构管，实现方式管，这都是开发文档中明确的事情，无可厚非，如果客户连这种傻逼都都知道是荒谬的需求却还要一意孤行的去执行，而sa又向来弱势，那么坑爹的就是程序员；大家普遍对台企印象不好，或者说很差，其实也是有道理的。我在这家台企工作快两年，算大公司，所在的研发分部就有不下1000人，不加班，双休，5天七小时，13薪，年涨薪20% （起薪3K，实习2K）,养老是没的说，日常工作轻松自由，可以磨洋工，去楼顶吹风，去楼下花园散散步，时间自由轻松。看来还算不错。弊端就是，员工无积极性。企业的态度是唯用户至上，如客户仅仅提供几个思路，实际是无稽之谈，完全不可行，但是也要开发人员短时间内给出一定的开发测试。在客户面前，台湾的sa毫无主见（反正也不是他们开发）,照单全收，然后统统转交至开发部，当开发人员在请求确认的时候，往往一两个星期都得不到反馈，甚至更久，看看人家强哥的24小时必回邮件制度。出了问题，还被强行背锅，有一次一个简单的需求，就是改下存储过程中X表的一栏位，结果sa描述成其它的意思，最后用户发现不对，质问sa，于是陆陆续续出现了A、B、C、D、E、F 六个版本，结果sa仍然没有搞清楚用户的需求。最后小组长被强行背锅，理由也是十分荒唐，一个运行十年的项目，维护的时候开发人员不能正确理解sa的要求。这强加的理由也是醉了，作为开发人员，按照需求来维护项目，更改的需求本身就是错的，还能怪到开发身上。大公司中很多项目都能拖上个一两年才出来一个版本，项目管理有时候很混乱，部门繁杂，流程拖沓。毕竟不差钱，养的起人，交的起电费。除了台企，也真是没谁了。

长此以往，也导致了很多开发人员离职。然后长时间又招收不到合适的替补人员，用大量的实习生来做技术储备，水平又参差不齐，有的毕业了参加 0基础培训两个月就走上工作岗位，结果连断点都不知道怎么打，一个项目能重复造一年的轮子（按照做好的模板写写界面），自以为是技术大牛，估计入门都还没过，想想真是可笑。其实自己也挺可笑的，只是造不同的轮子而已，不过重要的还是学习，提升自身实力是第一目标，只有自己强大，才能有底气的强势些，做事让上级放心，得到他人的认可，毕竟只管糊墙不看图纸的泥瓦匠不是一个好的程序员。

岁月悠悠，每天两点一线的生活，公司-住处，下班闲暇之余买些专业书来啃，唯恐被淘汰，毕竟对公司来说，创造价值与成本比是第一位的。多读书，理想还是要有的，说不定那天就实现了呢，保持一份简单的心，毕竟我们每天都在做着改变世界的事情！！！