程序员的饭碗和杯具

你有没有这样的经历？

在需求阶段搞得很复杂，需要各种各样的功能，然后系统设计的时候，想用这个设计模式，那个架构，等等，总是想把自己的系统搞得功能强大，灵活性好，可扩展性好等等，有时候为了照顾用户体验加了一堆乱七八糟的东西，总认为自己能建一座鸟巢。然后等到编码的时候，忽然发现，数据库设计不合理，缺这少那，更悲催的是，需求错了，用户真的需要这些东西吗？一遍，两遍，N遍改。结果，就一直改啊改的，把系统改成了一个鸡窝，这个过程中，客户还一直催啊催啊的，你只能着急上火，什么架构，什么设计模式，什么用户体验，什么效率啊，什么根据UML啊，什么后期维护啊，都是扯淡，系统能跑起来就已经是万幸了。

经历过吗？

面对着看似简单的任务，构思得如何美好，然后因为前期需求和设计的问题，后期不停得改啊改啊的，然后改得面目全非。然后看着系统，在心里恨恨地骂一句：狗屎。图一时之快带来后期的无尽痛苦。只要是合格的程序员，都理解需求和前期设计的重要性。

常常用“需求永远都是变化的，如果不变化，那程序员还干屁啊”这句话来安慰自己。需求变化是程序员的饭碗，貌似也是程序员的一大杯具。

不得不摆低姿态，用于承认，自己的团队在项目经验和技术水平上都有很大欠缺，在项目控制上很有问题。也曾想过，用敏捷开发的思想去应对上面提到的问题（敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。）也想过，使用快速原型，自顶向下开发，用户意见，快速迭代.....但是这些也就停留在想想的阶段，我的团队是一个草根团队，本人也缺少项目经验和技术水平对整个系统进行合理控制，而且有的时候，工期很短滴，不可能一搞搞个年八月的。

大家都知道OFFICE好，可是人家投入了多少吗？今天的OFFICE经过多少个版本、经过多少年头才熬出来的，绝不是一蹴而就的。国内企业愿意在这方面花那么多成本吗？一个差不多的项目几个月时间而已，需求占一个月（半个月写需求文档，半个月评审需求，修改需求），原型占一个月（半个月画原型，半个月评审和修改原型），一个月开发（2个星期打架构，画UML，2个星期写代码），一个月测试，然后改。是人们太着急吗？人们不得不急，大家都是要吃饭的，我们没有那么多资源去搞用户体验，去不停地调查需求，去考虑后期扩展等等。公司没那实力，自己也没必要给自己找罪受，只知道到期交项目拿钱，维护事，别人看着办。系统用个一两年，然后维护的人换了一批又一批，直到人们不耐烦了，骂了句：鸡窝。然后推倒重构，重新来，然后几个月时间，一个新系统赶出来，继续迎接着下一批人的批判，步了上一批人的后尘，然后循环下去。当我们一遍遍地叫嚣“别人做的什么玩意儿啊，垃圾”，当我们一遍遍数落“前辈”的不是的时候，当我们一遍遍地叫喧“用户体验”的时候，我们真的吸取他们教训了吗？（不要拍我啊）我们在批评别人的时候，自己真的做得足够好吗？当我们真正做的时候，是不是又走了别人的老路？你懂得。

程序员这条路，依然是条学习的路啊，在项目中，总是能看到别人喝自己的不足，发现那么多问题。我们可以抱怨做不出优秀的项目是因为环境不好，团队不好，公司资源不好，但抱怨的同时，一定要看看，你自己是不是足够好，写得代码是不是狗屎一样，如果是项目经理，你的技术和经验，对整个团队和项目的把控，是否在一个高水平上，和某些国际水准有多大差距。不要盲目地抱怨，抱怨地同时，请记住一步步提高自己。想要发出自己的声音，必须要到达那个层次。

还要知道，程序员这条路，绝不是单打独斗，逞个人英雄的路。你个人技术再怎么强，项目经验再怎么丰富，你也很难做好一个产品，管理好一个产品。必须要一个团队，一个技术强，项目经验丰富的学习型团队。不然，很难顺利地在做需求，写需求文档，画原型，需求评审，搞设计，打架构，写代码，和测试这条路上走下来，或者快速迭代，不恶心，按部就班地下来。

呼应一下开头，最近刚刚合作开发完毕业设计管理系统，属于教务系统的一个小的子系统，麻雀虽小，五脏俱全啊，就很彻底地遭遇了文章开头描述的情形。仅仅20来天，很容易想象我们需求和设计搞得怎么样，后期已经吐了又吐了，不幸中的万幸，让它跑起来了，跑得怎么样还得继续看。不到一个月就已经吐成这样了，可想而知，如果一个项目战线拉到以年为单位了，那岂不是成吐仙了，水平不够啊，接着学习吧。有同感的人，为了我们的饭碗和杯具，也努力提高自己吧。