前期设计的仓促与系统架构的烂摊子

程序员的饭碗和杯具
服务器君一共花费了198.356 ms进行了4次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

你有没有这样的经历?

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

经历过吗?

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

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

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

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

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

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

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

本文地址:http://www.nowamagic.net/librarys/veda/detail/1422,欢迎访问原出处。

不打个分吗? 还木有人打分噢!

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/1422

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《大话数据结构》 程杰 (作者)

《大话数据结构》主要内容包含:数据结构介绍、算法推导大O阶的方法;顺序结构与链式结构差异、栈与队列的应用;串的朴素模式匹配、KMP模式匹配算法;二叉树前中后序遍历、赫夫曼树及应用;图的深度、广度遍历;最小生成树两种算法、最短路径两种算法;拓扑排序与关键路径算法;折半查找、插值查找、斐波那契查找等静态查找;稠密索引、分块索引、倒排索引等索引技术;二叉排序树、平衡二叉树等动态查找;B树、B+树技术,散列表技术;冒泡、选择、插入等简单排序;希尔、堆、归并、快速等改进排序。

更多计算机宝库...