做同一件事,目标不同,结果就不一样

如何成为优秀的开发人员
服务器君一共花费了575.630 ms进行了4次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

开发人员的事情就是coding,没日没夜的coding,而且大家都是这样在coding,但是效果和结局就不一样:有人coding了N多年,技术还是原地踏步,编写出来的代码还是bug连连;有人coding就变成了技术骨干,甚至有人成为了CTO,架构师等。

为什么?

首先从一个小的故事说起:一个项目,分配给了项目组的人开发。于是大家就热火朝天的干了起来。当时,就发现了一个现象:任务已分配完成之后,有人就开始coding了,噼里啪啦的开始敲代码,不久之后又开始噼里啪啦的改代码,然后又开始不断的调试,找出bug,然后修改bug。很快,这个迭代的期限就到了,原计划要完成的功能很多没有实现,有的人也确实做完了,问题也一大堆,有人也确实完成了,没有bug,但是在审查他的代码的时候,就是看不懂。

这里想起了自己刚刚步入IT开发行业时候的情景。总是希望尽快的把事情搞完,因为只要没有做完,就拖了项目的后腿,很可能被leader训导,甚至可能被认为没有能力而被开除。在写代码的过程中,发现一点:尽管写代码的速度是快了,但是在写完了之后,每次编译,都发现错误,编译通过了吧,逻辑又有错误,然后就这样不断的缝缝补补,功能是完成了,但是心里有一种想法:以后千万不要让我来看和来改这段代码。因为代码写的很烂,烂的连自己都不想看,而且很多实现的方式也是很诡异。反正结果是:功能完成了。其实自己心里也很清楚,在写代码的时候,脑子有点糊,而且写着写着就不知道写什么了。

后来慢慢的发现:如果再这样下去,对自己的发展是没有好处的,而且原本认为很有技术含量的编程活动也变成了一种没有技术含量体力活,有时候甚至不用脑子。

就如软件开发中的需求一样:变化。

人也要:改变。

所以在之后的项目开发过程中,就给自己定了一个目标:写完一个小功能的代码,确保一次就编译通过(当然,在写代码的时候肯定得注意逻辑,但是偏重在使得编译通过),于是,在开发的时候,就开始"用心"了,或者说是更加的细心了。

一段时间的磨练之后,这个目标达到了,而且还超出了期望的值:写完一个大的功能代码之后,编译也没有错误。

所以这里悟出了一点:同样是做事情,做的也是同一件事,目标不同,结果就不一样。

这样之后,写的代码质量确实是提高了,但是另外的问题又出来了:写出来的代码总是在缝缝补补,总是这里差一点,那里差一点。很多地方很欠考虑。

怎么办?

发现了怎么一个问题:每次在任务分配了之后,就开始coding。这没有错。大家都这么做的。但是有一点:每次在实现一个功能的时候,总是一边写代码,一边思考,就这样,一步步的把功能实现。其实这就是问题所在。

就好比下棋,你总是走一步算一步,但是你的对手在走一步的时候,已经想到了后面的3步,4步,甚至更多步怎么走。如果你和这样的对手下棋,输家常常是你。

写代码也是一样的,不要走一步算一步。在写代码之前,首先从业务上,要把这个功能的流程搞清楚,然后再考虑:如果实现这个流程,要怎么写代码。然后在开始写代码,于是带着这个思想,发现自己写出的代码逻辑错误就少了,起码在总体的流程上是对的,可能在有些地方缺少一些考虑,如验证等。这样bug也少了,开发的速度自然快了。

说白了,就是在实现一个功能之前,先要设计,或者专业一点,画画流程图,其实流程图也不一定非得用UML画的那么标准,很多时候,就是拿一支笔和一个练习本开始画了,只要自己认识就行了。

采用这种方式之后,发现不仅自己的设计能力提高了,而且对开发出来的功能也是很有信心的。

一个功能,在草纸上设计,一个模块,也这样设计,甚至一个小的体统也这样设计,慢慢的,就可以上机coding之前,整个功能就已经在头脑中实现了,剩下的就是转为代码的事情了。

在项目中,总是想控制项目的进度,但是每次在开会的估算一个功能什么时候可以做完的时候,往往听到的却是这样的话"应该可以在一周之类完成","估计应该可以吧",等等,诸如此类的没有把握的话,最后的结果是:什么时间规划都是白搭,延期,再延期。

其实很大的程度上就反映了设计的问题。

当我们在估算项目的时候,很多的时候我们没有一个准确的估算,或者说只有一个大概的估算。其实这就是设计做的不够。

当一个任务分配下来之后,我们确实一直在考虑业务流程和怎么实现,但是终究只是停在"考虑"上,没有进一步的细化,细化的颗粒度不够,没有细化到用到几个类,几个方法,很多的时候只是大概的想想怎么实现。就因为这样,项目的风险很大,甚至不能控制项目,而且也不知道项目是否按照计划在在进行。

如果设计做的充分的好,最后的结果就是:整个类,流程都基本敲定,只是填充方法的实现而已,这样项目是否按照计划进行就一目了然。

其实,编程终究是需要动脑的,多多的思考。

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

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

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

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

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

大家都在看

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

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

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

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

《软件随想录:程序员部落酋长Joel谈软件》 Joel Spolsky (作者), 阮一峰 (译者)

《软件随想录:程序员部落酋长Joel谈软件》是一部关于软件技术、人才、创业和企业管理的随想文集,作者以诙谐幽默的笔触将自己在软件行业的亲身感悟娓娓道来,观点新颖独特,内容简洁实用。全书分为 36讲,每一讲都是一个独立的专题。《软件随想录:程序员部落酋长Joel谈软件》从不同侧面满足了软件开发人员、设计人员、管理人员及从事软件相关工作的人员的学习与工作需要。

更多计算机宝库...