Browsed by
分类:流程方法

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

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

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

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

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

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (21 人打了分,平均分: 4.57 )
Loading...
十条不错的编程观点

十条不错的编程观点

Stack Overflow上有这样的一个贴子《What’s your most controversial programming opinion?》,翻译成中文就是“你认为最有争议的编程观点是什么?”,不过,在400多个主回贴,以及千把个子回贴中,好像并不是很有争议,而是令人相当的茅塞顿开,下面罗列一些,并通过我自己的经历和理解发挥了一些,希望对你有帮助。

1) The only “best practice” you should be using all the time is “Use Your Brain”.

唯一的“Best Practice”并不是使用各种各样被前人总结过的各种设计方法、模式,框架,那些著名的方法、模式、框架只代码赞同他们的人多,并不代表他们适合你,你应该更多的去使用你的大脑,独立地思考那些方法、模式、框架出现的原因和其背后的想法和思想,那才是“best practice”。事实上来说,那些所谓的“Best Practice”只不过是限制那些糟糕的程序员们的破坏力。

2)Programmers who don’t code in their spare time for fun will never become as good as those that do.

如果你对编程没有感到一种快乐,没有在你空闲的时候去以一种的娱乐方式去生活,无论是编程,还是运动,还是去旅游,那么你只不过是在应付你的工作,无时无刻不扎在程序堆中,这样下来,就算是你是一个非常聪明,非常有才华的人,你也不会成为一个优秀的编程员,要么只会平平凡凡,要么只会整天扎在技术中成为书呆子。当然,这个观点是有争议,热情和能力的差距也是很大的。不过我们可以从中汲取其正面的观点。

3)Most comments in code are in fact a pernicious form of code duplication.

注释应该是注释Why,而不是How和What,参看《惹恼程序员的十件事》,代码告诉你How,而注释应该告诉你Why。但大多数的程序并不知道什么是好的注释,那些注释其实和code是重复的,毫无意义。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (44 人打了分,平均分: 4.68 )
Loading...
老手是这样教新手编程的

老手是这样教新手编程的

comp.lang.c全球最大的C语言新闻组,其Google的链接是:http://groups.google.com/group/comp.lang.c/ 可惜被GFW了。在comp.lang.c新闻组,有一个日本网友发了个贴子,说他正在学习一个在线的C语言课程,要完成一个作业,用程序输出如下的结果,而他的老师在美国,因为时差问题,他无法和他联系,所以只有上这里来寻求帮助。

    *
   ***
  *****
 *******
*********
*********
 *******
  *****
   ***
    *

很明显,在comp.lang.c上发这种贴子是一定会被拍的很惨的,这样的事,以前在SUN的论坛上也发生过,详情请看这里。还有一个去软件官网上要一个盗版序列号的。果不然后,我看到了这样的一个回贴。提供这样的一段代码:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (26 人打了分,平均分: 4.85 )
Loading...
各种流行的编程风格

各种流行的编程风格

在过去的N年中,我遇到了很多使用囧然不同风格的开发者,下面是我所知道的一些,你还知道其它的吗?

散弹枪编程

这种编程风格是一种开发者使用非常随意的方式对待代码。“嗯,这个方法调用出错了……那么我会试着把传出的参数从 false 变成 true!”,当然依然出错,于是我们的程序员会这样:“好吧,那我就注释掉整个方法吧”,或是其它更为随意的处理方式,直到最后让这个调用成功。或是被旁边的某个程序员指出一个正确的方法。

如果我们把一个正规的程序员和一个撞大运的程序员放在一起做结地,那么,那个正规的程序可以马上变得发疯起来,并且,可以把正规的程序员的智商降到最低。两个撞大运的程序员不应该在一起做结对编程,这是因为他们破坏性的才能会造成的伤害会比只有一个还差。

撞大运编程

这是一种比散弹枪编程要温和一些的编程方式,我相信这种方式可能会是大多数程序员都会使用的方式。这种编程方式经常出现于程序员并不确切知道他们在干什么,也不知道所写的程序的本质和实际,但是可以让程序工作起来。他们以一种撞大运的方式在写程序,某些时候,他们根本就不知道某个错误的原因,就开始稀里糊涂地修改代码。一旦出现问题,他们会用两条路:1)停下来,理解一下程序,找到出错的原因。2)使用散弹枪编程方式开始解决问题。

测试驱动开发(Test Driven Development)是一种可以用来拯救上百万的撞大运编程的程序员。于是,他们有了一个更为NB的借口:只要我的程序通过测试了,你还有什么话好说?别骂我,测试驱动开发是一个不错的事物,其主要是用来控制撞大运开发所带来的问题。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (44 人打了分,平均分: 4.89 )
Loading...
橡皮鸭程序调试法

橡皮鸭程序调试法

Rubber Duck Debugging下面,让我来为你介绍一个程序调试大法——“橡皮鸭程序调试法”,这个方法在调试界是很出众的,实施起来相当方便和简易,几乎可以随时随地地实验,几乎不需要借助任何的软件和硬件的支持,你甚至可以把你的程序打印出来,在纸面上进行调试。

那么,为什么这个方法要叫做橡皮鸭呢?因为橡皮鸭子是西方人在泡澡时最喜欢玩的一个小玩具,所以,这个东西应该家家户户都必备的。因为,这个方法由西方人发明,所以,就被取名为“橡皮鸭”了。

好了,话不多说,下面是整个调试方法的流程。

  1. 找一个橡皮鸭子。你可以去借,去偷,去抢,去买,自己制作……反正你要搞到一个橡皮鸭子。
  2. 把这个橡皮鸭子放在你跟前。标准做法是放在你的桌子上,电脑显示器边,或是键盘边,反正是你的跟前,面朝你。
  3. 然后,打开你的源代码。不管是电脑里的还是打印出来的。
  4. 对着那只橡皮鸭子,把你写下的所有代码,一行一行地,精心地,向这只橡皮鸭子解释清楚。记住,这是解释,你需要解释出你的想法,思路,观点。不然,那只能算是表述,而不是解释。
  5. 当你在向这只始终保持沉默的橡皮鸭子解释的过程中,你会发现你的想法,观点,或思路和实际的代码相偏离了,于是你也就找到了代码中的bug。
  6. 找到了BUG,一定要记得感谢一下那个橡皮鸭子哦。

什么?你觉得这个方法太“愚蠢”,太“弱智”了?是的,看上去,会这样做的人脑子好像是有点毛病。不过,我要告诉你的是,这个方法的确有效。因为,这就是“Code Review”的雏形!下面让我来给你解释一下。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (15 人打了分,平均分: 4.87 )
Loading...
Richard Feynman, 挑战者号, 软件工程

Richard Feynman, 挑战者号, 软件工程

源文:链接  (本文主要根据挑战者号的问题,以及Richard Feynman那对NASA严厉的批评报告,批评了不适当的“自顶向下”的设计方法,并总结了一下软件工程和其它工程的相通的一些观点。翻译水平有限,欢迎指正)

Challenger Crew

佛罗里达州,美国东部时间1986年1月28日上午11时39分,挑战者号航天飞机 执行为期6天的STS-51-L 任务,在发射后,其右侧固体火箭助推器(SRB – Solid Rocket Booster)的O型环密封圈(用于连接两节助推器)失效,泄漏出来的热汽达到了5000华氏度,直接蒸发了O型密封圈,并灼烧了毗邻的外部燃料舱,在几秒钟内,外部燃料舱出现结构连接失效,空气的动力迅速分解了航天飞机。在而航天飞机上升72秒以后,助推器脱落,导致航天发飞向侧面滑出。几乎在引航员 Michael J. Smith 发出”Uh oh” 的同时,整个航天飞机完全解体,片刻,航天飞机内部发生爆炸,所有7名宇航员罹难。 那时的我还只是一个小孩,我从电视下方滚动的新闻条目知道了这一惨剧。

在那个时候,火箭助推器工程师曾经警告过这个O型环可能存在问题,但可惜的是,NASA的管理层忽略了这个问题。Challenger Explosion美国总统里根委派罗杰斯委员会对事故进行了调查,调查成员包括著名的物理学家Richard Feynman。其不羁的态度和直来直去的方法和罗杰斯委员会的风格形成了鲜明的反差。主席罗杰斯,一个政客,评论Feynman是一个“真正的痛苦”。最后,在委员会提交的报告中,Feynman反判的观点几乎被清除了出去。并且,Feynman曾被主席威胁过要把他的名字从报告中完全除掉,但最终,他们还是同意在报告中加一个附录,但只是个人观点—— Appendix F – Personal Observations on Reliability of Shuttle

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (15 人打了分,平均分: 5.00 )
Loading...
Code Review中的几个提示

Code Review中的几个提示

Code ReivewCode Review应该是软件工程最最有价值的一个活动,之前,本站发表过《简单实用的Code Review工具》,那些工具主要是用来帮助更有效地进行这个活动,这里的这篇文章,我们主要想和大家分享一下Code Review代码审查的一些心得。

首先,我们先来看看Code Reivew的用处:

  1. Code reviews 中,可以通过大家的建议增进代码的质量。
  2. Code reviews  是一个传递知识的手段,可以让其它并不熟悉代码的人知道作者的意图和想法,从而可以在以后轻松维护代码。
  3. Code reviews 也鼓励程序员们相互学习对方的长处和优点。
  4. Code reviews 也可以被用来确认自己的设计和实现是一个清楚和简单的。

你也许注意到了在上面的Code Reivew中的诸多用处中,我们没有提到可以帮助找到程序的bug和保证代码风格和编码标准。这是因为我们认为:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (11 人打了分,平均分: 4.91 )
Loading...
一些单元测试的Guideline

一些单元测试的Guideline

Jimmy Bogard 曾经写过一篇文章: 《从单元测试中获益》,这这篇文章中给出了下面三条规则:

  1. 测试名应该从用户的角度描述是什么和为什么” – 这样一来,程序员可以从名字就可以知道用户需要什么样的软件行为。
  2. 测试也是代码,同样也需要我们更多的爱” – 真实运行在生产环境下的代码不仅仅只是我们需要去关心和花心思的代码。对于单元测试中的代码同样也需要易读易维护,以及可重用的特性。“我非常痛恨那些又长又复杂的测试代码,如果一个测试需要30行的单元测试代码,请把其放在一个方法中。一个长的测试步骤只会激怒程序员。如果你在正式的代码中都没有这么长的代码,那么为什么我们需要在测试代码中容忍这样的情形呢?
  3. 不要只用一种固定的模式或组织风格有些时候,对于一些特殊的测试案例,标准的类设计模式,或一个固有的测试装置可能并不能有效的工作。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (3 人打了分,平均分: 4.00 )
Loading...
整洁代码的4个提示

整洁代码的4个提示

虽然这样的文章非常的多,并且,就算是对于编程新手来说,也是非常的简单和显而见,但是,在我们进行Code Review过程中,我们还是能够看到那些非常混乱的代码,所以,有些时候,你会在想,是不是这样的规则太多了,导致我们的程序员记不住。虽然我们在以前的文章中一遍又一遍的说过(比如:《优质代码的十诫》),千言万语总结一下,无论你用什么样的语言,最最基本的编程原则就是下面这四条。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (4 人打了分,平均分: 4.75 )
Loading...