web analytics
首页 > 杂项资源, 流程方法 > 五个方法成为更好的程序员

五个方法成为更好的程序员

2010年7月15日 发表评论 阅读评论 14,364 人阅读    

对我来说,一个好的程序员应该是努力去追求尽可能无错的高质量的符合需求的代码实现。 一些人也许认为好的程序员是那些懂得多门编程语言,懂得很牛技术的程序员,是的,这在某些情况下是对的。但归根到底,无论你用什么样的技术,什么样的语言,所有的程序被写出来,其功能都要符合需求以及尽可能地健壮无错和高质量。  我们可以想像一下,如果一个能力普通的程序员有足够多的时间来做测试,那么,其也可以保证他的代码的质量。所以,有一种观点这样认为——要达到质量高的代码只需要有足够多的时间来做测试。这对于以结果为导向的商业软件开发中是可以理解的(我们可以看到那些制汽车的产商在汽车测试上花费的精力和时间就可以明白这一道理)。

但是,很明显,所有的已经开发出来项目都是在不完美的条件下开发出来的,一般来说,几乎所有的项目都是在最大化程序员软件的开发速度。而且,很多情况下,我们似乎对深度测试和压力测试并不是很关心,所以,我们总是在祈祷并期望那些赶工出来的代码可以正常工作,尤其是在上线的时候,这种唯心主义的价值观更为强烈。  其实,开发速度和软件产品质量并不矛盾。好的程序员并一定是技术强的程序员,而是那些可以在不完美的工作环境下保证软件质量和工作效率的程序员。下面是是五个程序员可以在这种不完美的情况下做得更好的观点(它们都和语言和技术没什么关系,只不过是一种你的工作行为,能够和所有的行业相通),这五个观点也许可以让你成为这样的好程序员。

  • 寻找不同观点:程序员好像并不喜欢技术上有异见的人,他们特别喜欢争论各自的技术观点。但是,他们忽略了不同观点的价值。任何事情都有好有坏,我们应该学会在不同观点中学习和平衡。这样才会更多的了解编程和技术。要经常在做事之前问自己和别人,这么做对不对?做完事后问自己,还可不可以改进?努力去寻找别的不同的观点或方法。程序员应该经常上网,经常和同事讨论不同的实现方法,不同的技术观点,这样才能取长补短。然而,在实际工作中,我发现程序员们并不喜欢互相请教,因为请教的人怕别人看不起他,而被请教的人总是先贬低对方的能力,哎……(参看《十个让你变成糟糕的程序员的行为》),如果有这样的文化氛围的话,那也没有关系。上网吧,网上的人谁也不认识谁,可以尽情地问一些愚蠢的问题。呵呵。总之,一定要明白,如果某些事情只有一个观点,那么你一定要怀疑一下了,没有观点和技术方案的比较,没有百花齐放的情况,你就无法知道是否还有更好的东西。真正的和谐不是只有一种声音,真正的和谐而是在不同的观点声音下取长补短,百家争鸣(参看《十条不错的编程观点》)。否则,你永远都不会接受到新的观点,也就无法进步和成长了。

  • 千万别信自己的代码: 在任何时候,一定要高度怀疑自己的代码。很多时候,错误总是自己造成的。所以,当出现问题的时候,要学会review代码中所有的可疑点,千万别觉得某段代码很简单,可以略过。事实证明,很多疏忽大意都是在阴沟里翻的船,都是那些很低级的错误。在查错的过程中,切忌过早下结论,切忌四处乱改(参看《各种流行的编程风格》),停下来,想一想,会是哪儿的代码有重大嫌疑,然后查看一下代码,捋一捋程序的逻辑(参看《橡皮鸭程序调试法》),调试并验证一下程序的逻辑和变量在运行时是否是正确的。很多时候,对于那些难缠的问题,最后解决了总是因为我们开始认真回头审视所有的代码。只有对自己的代码保持着高度的怀疑,这样我们才会想着如何让其运行得更好更稳定,也会让我们在单元测试中下更多的功夫,这样才能更能在那忙碌的环境中节省时间。相信我,在集成测试中fix bug的成本要比在单元测试Fix bug的成本大得多的多。一个简单的例子就是memory leak。程序员对自己的程序需要有忧患意识,这样才会越来越成熟,而自己的能力也会越来越强。

  • 思考和放松: 做事前多想一想,这样做事的时候就不会不顾此失彼,手忙脚乱,一旦事情一乱,你的心情也会更乱,于是,事情也就会更乱。最后,你只得重写,这种事情太多了。而且,在工作中要学会享受,要学会放松心情,我并不是让你工作的时候聊QQ,我只是说,有时候,心态过于紧张,压力过大,你的工作成果反而更不好,从而又反过来造成新一轮的焦虑和紧张。我个人认为,思考和放松是可以完美统一的,思考其实就是一种放松,停下来,休息一下,回头看看走过的路,喝口水,登个高,看看过去走的对不对?总体是个什么样?总结一下,然后看看前路怎么样好走,这会你才会越走越好,越走越快。好的程序员都不是那种埋头苦干的人,好的程序员总是那些善于总结成败得失,善于思考,善于调整,善于放松的人(参看《优秀程序员的十个习惯》)。不然,我能看到的情形是,你很快地把事干完,回到家刚坐下来,老板或是客户就打电话来告诉你你的程序出问题了。总之,深思熟虑,动作会很慢,但是你可以保证你工作成果的质量,反而能让你更多的节约时间。

  • 学习历史,跟上时代: 如果你是从十年前开始编程的,那么,今天的这门语言或是技术会有很多很多的改进和改善。你以前开发一个功能或函数,今天早已被集成时了语言中,而且做得比你的版本要好得多。以前你需要100行代码完成的事情,今天只需要1行代码。这样的事情在未来还会发生,所以,今天的你一定要学会如何跟上时代。但是,你也不要放弃历史,我现在看到很多程序员对一些现代的语言和技术使用的非常好,他们可以很容易地跟上时代。但不要忘了,计算机世界的技术更新和技术淘汰也是非常猛的。所以,你一定要学习历史,这些历史不是产商的历史,而是整个计算机文化的历史(参见《Unix传奇》)。只有通过历史,你才能明白历史上出现的问题,新技术出来的原因,这样才能够对今天的这些新的技术更了解,也才能明白明天的方向在哪里。学习历史和跟上时代都是相当重要的。使用新型的技术,停下来接受培训,可以让你工作得更快,更高效(参看《未来五年程序员需要掌握的10项技能》)。而学习和总结历史,才会让你在纷乱的世界中找到方向。

  • 积极推动测试活动: 只有测试才能证明软件可以正常工作,只有测试才能保证软件的质量。无论什么产品,都需要经过或多或少的测试。测试地充分的产品或模块,你会发现其质量总是那么好,测试的不充的产品,质量总是那么次。德系汽车,日系汽车质量怎么样,关键还是在于怎么去测试的,测试的是否充分。所以,在你开发软件的过程中,如果你说你的程序写地好,质量高,那么请你拿出实实在在的测试报告。在整个软件开发过程中,做为一个好的程序员,你应该积极地在各个环节推动项目组进行测试活动。不要以为技术需求阶段和设计阶段不需要测试,一样的,只要你要release什么,release的这个东西都需要进行测试。技术需求怎么做测试?用户案例就是测试案例。在软件开发的整个过程中,保证产品质量有时候比实现需求更重要,尤其是那些非常重要甚至人命关天的产品。

上面这些五个观点都是可能让你在不完美的工作环境中可以工作得更好,更快,更高效,希望能够对你有用。另外,也欢迎你留下你的观点!

(全文完)

(转载本站文章请注明作者和出处 酷壳 – CoolShell.cn ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (21 人打了分,平均分: 4.57 )
Loading ... Loading ...
  1. 2010年7月15日11:14 | #1

    这篇是翻译的吧,出处?

  2. 2010年7月15日12:59 | #2

    第2条和最后一条做的不好,可能是太懒了

  3. 2010年7月15日13:36 | #3

    @刘江
    这些观点并不新鲜,可能你在别的地方也看到过,出处来自我们的生活和互联网。但本篇文章并非翻译,我用我的经验和经历叙述了这些观点。

  4. 晓晓
    2010年7月16日11:03 | #4

    读着很别扭 就像英文翻译过来的 也像拼凑的 看不出作者的中心思想

    • 2010年7月16日14:21 | #5

      谢谢你的批评,的确如此,有时候英文资料看多了,中文都有点退步了。写博客阐述观点还是需要有一定的表达能力和语言功底的。这点以后注意。这篇文章的观点就是:“好的程序员并一定是技术强的程序员,而是那些可以在不完美的工作环境下保证软件质量和工作效率的程序员”。

  5. yz
    2010年7月16日17:51 | #6

    根据学院派理论和工作经验,在大型系统中保证质量的肯定不是测试,而是设计,优秀的代码来源于良好的设计,测试只能反映产品的质量;通过测试发现的问题越多,说明系统中未被发现的问题也越多

  6. 2010年7月17日08:32 | #7

    @yz
    “在大型系统中保证质量的肯定不是测试,而是设计” 这个观点不敢苟同。
    其一,如何证明设计是良好的?恐怕还是需要通过单元测试,功能测试,系统测试,性能测试等来证明吧?
    其二,测试更多的价值体现在回归测试中,良好的设计也不是一开始就能够达到的,而是需要经过无数次的完善和重构,而测试能够保证新的变更不会破坏现有的功能。
    其三,“通过测试发现的问题越多,说明系统中未被发现的问题也越多”,听起来是件好事,至少对QA是如此。

  7. 2010年7月17日09:16 | #8

    作者在博客园也开博了吗?我刚在那边看到这篇文章。

  8. 2010年7月17日09:39 | #9

    @12free 没有,那边的是转载。

  9. 2010年7月18日13:08 | #10

    最新的那篇讲敏捷的译文被删了?

  10. 2010年7月18日16:32 | #11

    @GlacJAY
    不好意思,本来想保存为草稿,结果误点了发布。陈皓已经将其发布了,下次一定注意尽量避免误操作。

  11. jerrycong
    2010年9月10日09:35 | #12

    jnj :
    @yz
    “在大型系统中保证质量的肯定不是测试,而是设计” 这个观点不敢苟同。
    其一,如何证明设计是良好的?恐怕还是需要通过单元测试,功能测试,系统测试,性能测试等来证明吧?
    其二,测试更多的价值体现在回归测试中,良好的设计也不是一开始就能够达到的,而是需要经过无数次的完善和重构,而测试能够保证新的变更不会破坏现有的功能。
    其三,“通过测试发现的问题越多,说明系统中未被发现的问题也越多”,听起来是件好事,至少对QA是如此。

    这里的设计应该更多的是强调详细设计,具体到模块开发,代码编写,有了测试能够完善设计,并不是说不要设计。
    架构上面的设计开始肯定就要做好的

  12. wisdom
    2011年2月22日08:54 | #13

    别理会那些不知好歹的人…又要看还要说这不好那不好…

    来之哪里 都一样 愿意分享经验就要顶~~!!

  13. 2011年5月17日17:01 | #14

    就像wisdom评论的一样,愿意分享经验就要顶!

  14. 2011年6月14日15:19 | #15

    @skyone
    要顶,同时感谢发表建设性意见的同仁。

  15. 2011年11月23日21:49 | #16

    老生常谈幸听之,是真言~~

  16. tantan
    2012年12月20日11:18 | #17

    顶一个!要做到这几点需要很大的勇气和毅力!

  1. 2010年7月16日10:25 | #1
  2. 2010年8月3日00:12 | #2
  3. 2010年8月31日17:18 | #3
  4. 2010年9月26日16:16 | #4
  5. 2010年10月11日10:21 | #5
  6. 2011年2月21日08:31 | #6
  7. 2011年2月22日00:39 | #7
  8. 2011年2月23日07:37 | #8
  9. 2011年3月1日21:21 | #9
  10. 2011年3月8日19:29 | #10
  11. 2011年4月27日13:51 | #11
  12. 2011年5月15日12:45 | #12
  13. 2011年8月14日15:32 | #13
  14. 2012年2月21日15:56 | #14
  15. 2012年10月21日13:10 | #15