Browsed by
标签:程序员

架构师给程序员的一封信

架构师给程序员的一封信

下面的邮件是某Architect发给他的Engineering团队的(来源),我觉得挺不错的,翻译过来,我相信我们所有的程序员都能从中学到很多东西。下面是这封邮件——

每次当我开始做新的东西是我就会很兴奋。就算在软件圈里做了20年以后,每当开始新的旅程里,我都觉得我心中有一些东西不吐不快。这是我们大家一起的旅程。我强烈地相信我们详细规划的过程是很有乐趣的,富有挑战的和丰富多彩的。我想让这个旅程让你们难忘,并且能增添你们所有人的阅历。

这看起来有些唯心主义,不过,我想制订我的工作日程,我们的技术策略,以及你们密切合作的进度。这样一来,当你们做了什么相当不错的事,我们所有人都可以受益。我相当的尊重第一个工程师和他们的代码。

1. 代码是王。文档仅随其后 。所以,代码一定要和文档一致,并可以正确执行。

2. 测试,测试,测试。

3. 单元测试非常关键 。每一个在单元测试之后发现的bug需要开发人员双倍的开销。记住,我宁可增加你的薪水,也不愿意把这些钱发给另一个QA团队然后你再修正bug。因此,如果你的代码满是bug的话,我不得不把钱付给更多的人,而你也只能分得很小的一块饼。

4. 写下有效率的代码,不但是让人读得有效率,而且也是让CPU执行 地有效率。对于坏代码永远不会善罢甘休。

5. 多了解今天工作需要之外的事情。你不仅仅要知道今天干什么,还要知道明天需要什么。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (14 人打了分,平均分: 4.50 )
Loading...
你和你的工作

你和你的工作

源文:http://youtheuser.com/2010/10/04/you-and-your-job/,有人说下面的这个文章太过Crazy,有人说下面的这个文章是猎头的软文,你换工作换得越多,他们才能越挣钱。我的观点的,先别否定他的观点,试着去理解一下为什么他要这么说,你会发现还有一些道理的。然后,想一想,自己需要的是什么?一份工作?还是一份经历?还是不断的自我挑战?相信你会有知道该怎么去做的。当然,“离职”是最后一步棋,在此前,我更希望你能尝试地在你现在工作环境下去改变去影响。

“The role of a manager should be to ensure that those that work for him/her eventually leave and go onto bigger and better things” —  Mark Plant

如果你对你的工作不高兴——离开,如果每天早上你对你的工作没有激情——无论你在干什么你都要停下来。

因为这就是我们赖以生存的东西。

  1. 如果你的工作没有挑战性 – leave.
  2. 如果你在混你的工作 – leave.
  3. 如果你觉得现在不辛苦而又感到压力大 – leave.
  4. 如果你完全知道你现在正在做的所有一切的事 – leave.
  5. 如果你没有得到足够多的失败– leave 并到找一个地方可以让你获得成功前的失败。而当你发现你天天都在成功 – leave again.
  6. 如果你觉得你很成功 – leave 然后去找某个事或某个地方你不会那么成功,而当你又觉得你又很成功了 – leave again.
  7. 如果所有的人都喜欢你并喜欢和你一起工作 – leave 然后去某个地方,那里的人并不喜欢你(然后你让他们喜欢你)。
  8. 如果你的工作就像是赢奖品一样,并且你总是能赢 – leave 然后找个地儿,那里的人总是赢不了什么。帮他们扭转局面。
  9. 如果你认为你知道产品的所有的内在的东西 – leave 然后找一个你不知道的产品。
  10. 阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (7 人打了分,平均分: 4.71 )
Loading...
开发时间估计

开发时间估计

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

目前状态 完成进展 剩余任务估计
任务刚被分配,还没有做调查 完成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...