Browsed by
标签:程序员

开发时间估计

开发时间估计

项目管理中,项目任务时间估计是其中一个重要的环节。各种管理员人都觉得时间估计很重要,都希望时间估计能准确一些,但是,事实却并不如此。事实上,会下面这样的结果。

目前状态 完成进展 剩余任务估计
任务刚被分配,还没有做调查 完成0% 大约2周
完成需求分析和调查,攻克了难点 完成50% 大约2周多一点
我几乎做完了。只有出了点我事先没有想到的岔子。
不过,我已找到解决方法了。只是还需要一些时间
完成90% 大约2周多一点
我全部做完了,只是还要写文档,做Code Review,
单元测试和错误处理
完成99% 还需要2周

呵呵,这是怪我们的项目管理的方法论呢?还是怪我们太过草率的程序员呢?

好烂啊有点差凑合看看还不错很精彩 (8 人打了分,平均分: 4.25 )
Loading...
代码重构的一个示例

代码重构的一个示例

还记得以前和大家提到过的《各种流行的编程风格》吗?有一些人问我那些编程风格具体是什么样子的。下面是一个代码重构的实例,让我们看看那个流行的编程风格是实践是什么样的。下面的这个实践不是虚构,如有雷同,请对号入座。

首先,我们有一个表达式如下所示:

s = 7;

很明显,这个表达式的变量名太没意义了,很不利于程序的可读性,所以,我们需要取一个有意义的变量名:

slots = 7;

很好,不过,那个常量7是hard-code或是一个Magic number,而且,这常量没有名字也不利于代码的可读性啊。再改:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (20 人打了分,平均分: 4.80 )
Loading...
编程时间分配图

编程时间分配图

下面是一个程序员coding的时间分配图,原图在这里

编程时间分配图

思考会是一个很重要的过程,当然耽搁拖沓也有可能也是因为没有想好,抽烟/喝咖啡应该也是一种思考,吃点东西是为了让脑子转得更快一点,上网搜索一下灵感可以借鉴一下其它人的想法,抱怨写注释只是一个例子,更多的应该是抱怨加班或是公司的老板。

如果需要加上点什么的话,我觉得应该加点“重构”,“编译”,“调试”,当然,他们都可以算在coding里。不过,我觉得更应该还有:“开会”,“争吵/解释”,“打断”,这些比重也是很大的。

所以,下面是我个人认为比较实际的版本:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (14 人打了分,平均分: 5.00 )
Loading...
一些鲜为人知的编程事实

一些鲜为人知的编程事实

文章来源:http://dotmac.rationalmind.net/2010/08/some-lesser-known-truths-about-programming/

我的程序员经历让我明白了一些关于软件开发的事情。下面是一些在编程中可能会让人感到诧异的事情:

  • 一个程序员用了大约只用了10%-20%的时间来编码,而且大多数程序员,无论他的水平如何,其平均每天只有10-12行的代码最终会进入最终的软件产品中。这是因为,优秀的程序员会花费90%的时间来思考、调查、研究最佳的设计。而糟糕的程序员则会花费90%的时间来调试代码,并随意地改动代码并尝试让代码工作起来。

“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates

“一个优秀的车工其工资是一个普通车工的好几倍,但是一个优秀程序员写出来的代码比一个普通程序员要值钱一万倍。——比尔盖茨”

  • 一个好的程序员比一个普通的程序员多十倍的生产率。而一个优秀的程序员的生产率则比普通程序员多20-100倍。这并不是夸张(自从上世纪60年代的研究一直表明这是一个事实)。一个糟糕的程序员并不只是没有产出的——他们并不仅是完成不不工作,而且还会制造出大量的让别人头痛并要去解决的麻烦。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (15 人打了分,平均分: 4.47 )
Loading...
程序员版的凡客

程序员版的凡客

现在“凡客诚品”的PS风已经成为了一场运动,详见这里:http://bigfools.com/2010/08/6634.html。这两天,公司内部要出期刊,正好下班没事,于是跟着这股网风,为公司的期刊做了一个插图,那些语句着实花了我很多时间。用PPT乱做的,希望大家喜欢。呵呵。

欢迎你留下你的版本,尤其是那些语句。

好烂啊有点差凑合看看还不错很精彩 (17 人打了分,平均分: 4.41 )
Loading...
最佳编程语录

最佳编程语录

以前本站发布过《22条经典的编程引言》、《编程引言补充》、《Linus Torvalds 语录》还有《十条不错的编程观点》。今天向大家介绍“最佳编程语录”,条条都是很不错的语录,如同我们的太阳,照亮了我们的方向(所以我们选用了一个红色的图片,希望能够通过五毛们的网络审查)。其中只有一两条在以前本站发布过的文章中出现过。这篇文章的出处在这里,下面是“Neo”和“陈皓”的翻译,我们的翻译水平有限,所以,我们提供了中英文对照,有不当之处,还请各位指正。

A good programmer is someone who looks both ways before crossing a one-way street. — Doug Linder, systems administrator

好的程序员这样一类人,这类人在横穿一条单行道前都要先看一下路两边。– Doug Linder, 系统管理员

A most important, but also most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language this influence is, whether we like it or not, an influence on our thinking habits. — Edsger Dijkstra, computer scientist

关于工具,一个最重要的,也是最不易察觉的方面是,工具对使用此工具的人的习惯的潜移默化的影响。如果这个工具是一门程序语言,不管我们是否喜欢它,它都会影响我们的思维惯式。 –Edsger Dijkstra, 著名的计算机科学家。

Being abstract is something profoundly different from being vague… The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. — Edsger Dijkstra

抽象和模糊完全地不同,抽象的目的并不是把事情变模糊,而去创建一个新的语义层,在那里是绝对精确的描述。 — Edsger Dijkstra

Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer. — Edsger Dijkstra

除了数学爱好,对于一个有能力的程序员来说,出色地掌握自己的母语是最宝贵的财富。– Edsger Dijkstra

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (22 人打了分,平均分: 4.41 )
Loading...
Kent Beck 谈单元测试和持续部署

Kent Beck 谈单元测试和持续部署

文章来源

2010年7月2日,Roy Osherove 和 Kent Beck 在 blog.typemock.com 进行了一次对话,话题涉及单元测试(Unit Testing),JUnit Max(Kent 开发的一个单元测试的 Eclipse Plugin,不免费),和面向初创企业的精益方法(Lean Startups)。

单元测试和 JUnit Max
作为软件开发方法学的大师、极限编程XP的创始人、敏捷宣言的创始人之一,Kent Beck 一直在努力最大化地利用单元测试的价值,他说一些程序员仍然认为单元测试并不是他们的工作,但是单元测试确实能够提高软件的质量。目前他正在开发 JUnit Max,这是一个 Eclipse plugin,每当程序员保存一个 Java 源文件的时候,JUnit Max 就会运行测试并报告反馈信息。测试中的错误将会如同编译错误一样被报告给程序员。JUnit Max 的核心思想是测试错误应该和编译错误一样被 IDE 报告给程序员,程序员不需要额外的菜单选项或者运行其他的工具来运行测试。特别是那些经常失败的测试,对于程序员来说是非常有价值的反馈信息。在测试驱动开发(Test Driven Development – TDD)中,我们重复着这样一个循环:“编写一个‘失败’的测试(Failing Test)” – “编码实现功能以便让测试通过”,随着开发的深入,测试越来越丰富,测试能够反馈给程序员的信息也越来越多,它们可以帮助程序员找出那些需要改进的代码。JUnit Max 能够缩短这个循环的周期,因为它更为频繁地运行测试和提供反馈。Roy 问道:“当你一个人编码的时候,你是否严格地遵循 TDD,即一定要先写测试,然后写实现代码。我个人发现这并不是一件容易做到的事情,特别是当一个人编码的时候。” Kent 回答:“视情况而定,有时候并不需要死板地遵循 TDD,比如当我在做一些探索性或者说实验性的编码时,并不需要写测试,因为我只是想尝试一下某些功能和特性。”

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (7 人打了分,平均分: 4.71 )
Loading...
五个方法成为更好的程序员

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

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

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

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

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (21 人打了分,平均分: 4.57 )
Loading...
黑客的价值观

黑客的价值观

黑客,可能在大家的眼里是那些入侵别人计算机搞破坏的人,其实并不是那样的。如果你这样认为了,只能说明你对计算机文化并不了解,真正的黑客是一种自由的象征,他们挑战权威,追求自由,并和很多非人类的行为作斗争。如果你想了解黑客文化,你一定要去看看我写的《Unix传奇,上篇下篇》。你会对正宗的计算机文化以及黑客文化有所了解的。而那些只懂得入侵别人计算机搞破坏活动的“黑客”只能称为是街头的小混混,他们根本就不配称黑客。

下面有四篇关于“Hacker’s Code”文章,我觉得相当的不错,可以让你明白什么是黑客的行为规范,道德准则,以及黑客的历史使命,希望能对你有启发。但是翻译水平有限,所以我请Mailper同学帮忙翻译了一下,但还是觉得原文更为传神,尤其是原文中的押韵,双意以及朗朗上口,所以,下面提供了中英文对照。如果有翻译得不好的还请大家指正。

The Hacker’s Code

http://muq.org/~cynbe/hackers-code.html

“A hacker of the Old Code.”

  • Hackers come and go, but a great hack is forever.
    黑客们来来往往,但是只有黑客的壮举是永存的
  • Public goods belong to the public.*
    公众的东西是属于大众的
  • Software hoarding is evil.
    Software does the greatest good given to the greatest number.
    圈养软件是邪恶的,最好的软件是有最多人使用的

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (10 人打了分,平均分: 5.00 )
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...