软件开发经验总结（二）别让定势思维害了你

 在一些软件公司中,总存在着一些“高人”，他们写代码从来不写文档，不做设计，代码不写注释，跟用户瞎扯几句之后就开始动手写代码了，他们的代码一般人都看不懂，经过无数次改BUG之后，他们做开发的系统居然也上线了，再经过用户无数次的蹂躏，系统也越跑越稳定。该系统成为了该公司至高无上的产品，普通人如果想看懂该系统，必须在它的代码上摸索个10年8年的，什么“设计模式、分层结构”的思想，在这些公司里都是瞎扯，只要能把用户搞定，一切就搞定了。

每次新项目开始的时候，老板总是苦口婆心地对项目组说“咱们的那套系统，那可是金宝山，花了公司那么多的资源，经过用户多层的考验，都是精华，你们项目中如果什么模块跟它相似的，就直接拿来用好了。” 程序员B不听老板的话，设计了一套很牛的算法解决了业务的问题，最后，由于系统中存在了一个小BUG，被老板骂了一顿，闹到不得不离职，辛苦工作了一年，年终奖都没有了。程序员A听从了老板的话，一切按照那套旧系统的模式做，即使用户不满意，也由老板通过一些其他的手段去解决，最后，程序员A当上了项目经理，在公司里当起了“九千岁”，每次遇人就说，那套旧系统真是好东西啊！从此之后，大家都学乖了，什么算法和机构，都按照旧系统的方法做，即使是错了，也不是自己的责任，大家都不再思考了，反正按照旧系统做准没错，年底的奖金肯定多。

经过了许多年，由一个习惯变成了一个传统，再由一个传统变成一个文化，在每个系统中总是有旧系统的影子，老板总是对人说“咱们的系统就要超印度了，所有的程序员写的代码都差不多了”，翻开每一份代码，你总是会看到这样的代码文化：

（1）       写SQL 时，SELECT 后面总是跟着*的，也没有人会思考为什么。

（2）       写SQL时，如果需要两个表连接，一定使用LEFT JOIN，也没有人会使用INNER JOIN 或RIGHT JOIN。

（3）       定义一个对象时，总是一定要实例化（比如 DataTable obj_dt = new DataTable）。

（4）       执行100句SQL 时，总是要连接100次数据库。

（5）       系统的所有方法，总是使用Public的，哪怕是类里面自己调用的。

（6）       代码总是加密过的（变量都定义的千奇百怪，即使别人拿到原代码也看不懂）。

（7）       存储过程是从来不用的，只在代码中用字符串拼SQL，然后再执行。

（8）       代码，没有摸个3-5年是看不懂的。

（9）       数据库的索引总是不用的（如果客户觉得慢，就让客户换一部好的机器去）

（10）   ………….

 

 

     当然，这只是一个普通的笑话，或许在现实中并不存在，但很多开发人员在开发的时候，或多或少会有一些定势思维，把自己已知的东西当作是全部，从来也不去思考为什么，也不去思考更好的方法去解决问题。如果整天只是吃自己的老本开发系统，不去学习新的东西，总有一天会被社会所淘汰！

罗嗦了这么多，主要的目的也是提醒自己，开发的时候应该自己多想想这种方案是否最好的方法？是否有更好的解决方案我不知道，这样的方案有没有什么缺陷？平时应该多学习别人写的优秀代码，多学习一些新的知识，让定势思维从我的字典里删去，也与园子里的兄弟共勉之！