您现在的位置是:网站首页 > 情感障碍

一个程序员的一生-经典文章-PHP教程-幽默笑话

本站2019-07-1278人围观
简介 文章内容一个程序员的一生修改时间:[2011/01/3007:14]阅读次数:[498]发表者:[起缘]我在程序员的时候,我一开始追逐这个API怎么用,数据库SQL怎么写更优化,Dcom技术的

一个程序员的一生-经典文章-PHP教程-幽默笑话

文章内容一个程序员的一生修改时间:[2011/01/3007:14]阅读次数:[498]发表者:[起缘]我在程序员的时候,我一开始追逐这个API怎么用,数据库SQL怎么写更优化,Dcom技术的细节,然后我发现我写出来的产品为了符合客户需求必须要大量修改,但是我的代码却粘在了一起,第一个感觉就是一个函数太长,一看就头痛,而且一个函数干了好多事。

这些事本来可以一段一段的,每段写上注释,然后有意义命名,自己管理错误和内存,然后把这些函数连在一起,然后我作了这些:1、小函数;2、写上注释;3、有意义命名;4、自己管理错误和内存;5、流程函数;最后我发现我这些函数可以组合成各种各样的流程,我的程序终于好修改了,我很高兴。

但是我又发现,我的界面和我的流程混在了一起,另一个程序也想使用我的函数,但是我的函数中有对我的特定界面关联的代码,我不能连界面一起都给他,因为他有他的界面,但作的事我已经实现了,于是我把功能函数和界面控制分开了我就作了这些,我的代码很容易理解,即使新员工,只要他看完业务手册和数据结构,他就明白我代码为什么这么写。 而且我的函数由于都是自己负责输入参数和输出参数的校验,有明确和统一的报错信息,所以很容易找到错误进行BUG修复。 由于我的程序都是小函数组成的,都有明确报错,所以错误很容易找到,经过测试组的专业测试后,我的代码很稳定,即使出错,也扩散不大,都是小bug,对系统整体没有大影响虽然我在前进的过程中也经历过困惑,一心钻在OOP和设计模式中。

但是有可能是功力不够,不得其解。

看着Delphi的源码,应用了很多的OOP和模式,并且他的类库多年发展也没有多大的改变,所以深信OO和模式的威力,而对自己的能力很灰心。 但是代码还得继续写,还想进一步提高,于是才摸索出现在的一套做法。

既实用又简单应用,每个人都能办到。 我认为我的代码方法已经可以满足现在的产品制造,并且在软件性能调整上也积累了一些珍贵的经验。 我发现性能最容易提高也效果最明显的就是用SQLprofilter,优化SQL。

优化代码,因为涉及到业务,很不好着手。

优化数据库结构,由于代码都是构建在特定数据表之上,所以这是最难改的地方,但是我高兴了没多久,我又遇到问题了。

因为我的程序即使再好改,但是客户的需求真是千奇百怪,我每天在接听用户的电话,并且修改用户千奇百怪的问题。 我很烦。 于是我作了实施员。 我想真正看看客户到底怎么回事。 于是我理解了很多。 我明白了很多的事情不是技术和软件所能解决的,而是现实环境的弊病。

但是这个弊病还不是一个工程就能解决的,这是一个复杂的网。 所以这些问题我就说服用户不要用软件来处理,因为软件是死的,而人的做法是灵活的。

而且我发现用户虽然提了很多需求,但是有的需求他一个月用不了一次,但是修改起来却不容易。 有的需求修改完,在实际应用中却发现不可行,那个需求只是客户想解决过去的问题而想的一个办法根本没有经过实际的校验。

有的需求修改来修改去都是表面问题,在实际应用中才发现重点问题没有提需求所以上线又搁下了,我作了总结:1、软件擅长大数据量计算和查询,还有数据联网共享,如果需求不能发挥软件特点,就不让软件实现。

这样我少修改了一些;2、有的需求都是表面需求,修改了也用处不大,反而耽误了重点需求的提出和修改,所以告诉用户只修改核心功能。 但是用户提了很多需求,不修改完不上线。 后来发现,由于他们没有深刻理解我们系统的整体思想,所以没有上线实际用,根本不知道新改的功能是否好用。

用户只是脱离了整体,单独思考想怎么就怎么,没上线根本他不知道后果,怎么说也不行,就得让他看见教训他才反悔,但是已经修改了。 往往出现这样的情况。

最后得出一个结论:一次只提三个需求,并且用书面提出,免的说了不算算了不说。 核心功能的需求修改可以满足80%的日常使用就上线。 这样我少修改了很多;3、并且我在实际做工程中,积累了大量的经验,写成FAQ,各种成功案例,让用户在没有提需求之前先看看自己到底有多少老软件实在不能解决而才买新软件帮助的事。

新软件就是解决你过去解决不了的事。 如果你没有解决不了的事,提什么需求;我的产品终于可以很快完成上线,所以可以大规模推广市场了,但是我们的产品制造又出问题了。

因为客户越来越多,客户的需求越来越多。 我们需要开发更多的系统,但是我们的时间有限,我们的人手有限,而且我们的人手大多是新手。

怎么办。 我们遇到了灾难。 我们的代码质量因人而异。

我们的版本管理混乱。

我们的文档没有人编写,大家都被分配到用户处去上线。 怎么准备数据字典,怎么切换系统,怎么记录客户需求,怎么管理系统,怎么修改代码,我们没有任何记录。

现场不能离开程序员一步,一离开用户出事了就不知怎么办,没有任何可查的资料。 于是我又做了项目管理,我们缺少很多规范。 事有千万,先从紧处来。

写文档费时间,就开会给大家讲做事的经验。 实施和代码修改需要什么必要规范就制定什么规范。

在这期间最容易犯的错就是中央集权,什么事都必须自己做主。

下属不管大事小事都请示你。

我被搞的什么都干不了,都成了救火队员。 我的团队陷入了混乱之中,因为我烦乱之中作了很多饮鸩止渴的决定。 我于是又犯了一个错误,我说你们能决定的事尽量自己决定,不要问我,我权利下放。

结果是:各自作各自的事,互相不通知。

有的事没人管,有的事多人修改,各有一套。

我终于明白了,我作了以下总结:1、项目经理是找到得力的人,指导他们做事的方向。

如果下属不知如何作时,及时提供给下属做事方法;2、制定规范,其实也就是做事方法;3、制定计划,分配人力去作。 检查结果;4、有紧急事务立刻做出果断解决,继续前进;我的团队终于平静了下来,但是大家都很疲惫。

大家干的很累,但是由于实施和修改消耗了大量的钱,我们没有赚钱,大家什么都没有得到。 团队很灰心,也很失望。

我下了计划,我自己都很灰心,大家认为再努力也不会再有结果,所以拖拖拉拉,进度和成本已成不可再提的事情。

人,缺少了精气神,就什么都没有了。 我们就是缺少了这些。

我就开始重新建立团队的精神。 我发现有人为了跳槽开始学习新的技术,而这种技术是公司现有产品不需要的,但是他们却在上班时间作。

我先从此下手。 我讲了技术的方向,让他们认清他们现在所学将会很快淘汰。 我又讲了现在市场的实况,让他们认清外面公司也不好过。

我还讲了我们所从事的行业多有潜力,我们公司将有新的举措。

人心又开始一点一点收回了。

但是我们仍然需要完成那些未收尾的工作,仍然需要去奔赴新的客户市场。 虽然员工很疲惫,虽然我们刚从飘摇中过来,但是我们不能止步,因为我们为盈利而存在,我们别无选择。 我能够将代码写的很好,性能很高,产品制造很有计划和成本控制,团队很有战斗力。

但是我发现了一个问题,我们的产品市场不再扩大了。 市场份额大规模开拓已很艰难,因为新产品的新鲜感已经过去了。 我们在动荡的日子作的项目给公司带来了阴影,公司一直没有大赚钱,投资方很生气。 我明白了。

公司毕竟是为利润而存在的。

公司不是为产品制造而存在,不是为了解决别人的问题而存在。 赚钱是第一位。

不赚钱即使你在媒体上作的很风光也一文不值。

有人靠手赚钱,有人靠嘴赚钱,有人靠脑子赚钱,有人靠身体赚钱,不管黑猫白猫,只要抓住老鼠就是好猫。 成在营销,败在管理。 我开始关注资本运作,联盟伙伴建设,市场营销,客户关系营运。

我知道,生活才刚刚开始。