Browsed by
标签:Programmer

提高编程技能最有效的方法

提高编程技能最有效的方法

StackExchange.com上有两个贴子(贴子一贴子二),贴子名叫“What is the single most effective thing you did to improve your programming skills?” – 对你的编程技术提高最有效的一件事是什么?回复的人中给了很多很不错的建议,我把他们总结了一下,十条,相信一定会对你有用。(注意:顺序是我自己按我的个人经验排的)

  • 和比自己聪明的能力比自己强的人工作。学习他们的代码,他们的做事方法,看一看那些人是怎么处理错误的。
  • 总是倾听别人怎么说,无论那个的资历和职位是什么样的。
  • 实践,实践,实践,总是不满意于一开始出来的事。
  • 多问问自己,现在在写什么代码?为什么要这样写成这样?还有没有更好的方法?
  • 学习多样的技术,多多比较他们,并一定要了解各种技术的优缺点。
  • 总是问别人问好的问题。
  • 多回头看看走过的路,做过的事,写过的程序,感觉一下他们有多烂。
  • 多读读那些大师写的书。
  • 不要总坐在电脑前编程序,多做做运动,多到户外走走,和非技术人多接触,向他们学习。
  • 把你的想法说出去,看看别人怎么回应的。从别人的回应中学习。

除了这些,下面是我个人想给你的建议——

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (17 人打了分,平均分: 4.59 )
Loading...
Error handling in Egypt

Error handling in Egypt

以前发布过《C语言的错误处理》一文,不过今天想说的是Egypt的“错误处理”。埃及的事闹得挺大的,国外和中文twitter上更是炸了锅。不要以为程序员就只会写程序——看看程序员举出来的标语吧。呵呵。

Error handling in Egypt

当然,作为程序员来说,这段代码显然还需要重构:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (9 人打了分,平均分: 5.00 )
Loading...
那些炒作过度的技术和概念

那些炒作过度的技术和概念

StackExchange.com上有一个贴子在评论着最近20年来被炒作过度的技术,对于出现的结果,大多数赞同,也有一些不赞同。下面我从前15名挑了10个(Java的WORE我去掉了,TDD我也去掉了,因为我觉得他们应该没有炒作过度,而且都不错),按原贴的顺序罗列如下:(后面的一些评论是我加的,欢迎大家讨论)

Top 10 过度炒作的技术和概念

  • Unified Modeling Language (UML) – UML是一个程序员交流想法的不错的工具,但是他离程序员真正需要的设计工具还差得很远,比如:设计是否符合需求、架构设计、数据流等等。只有为数不多的程序员使用这个工具交流想法,而没有用在具体工作中。
  • Sharepoint – 现在N多的公司都在用微软的这个东西做公司内部的Intranet。不过安装和维护起来,代价相当的大。但是其市场做的很成功,不对技术上来说对技术人员来说,相当的蹩脚。Sharepoint的设计没有认真地分析过业务流程,仅仅是一个文档存储地。看上去我们似乎可以做任何的事,但是如果你要用其来管理你的项目和track你的项目问题,你会发现其是无比的难用。
  • eXtensible Mark-up Language (XML) –  XML嘛,以前说过很多了(XML1 XML2)我们用他来做和程序数据封装,用来做配置文件,用来做网络传输格式。我们的程序处理起XML来,又慢,又不经济,没有工具,几乎无法维护XML文件。XML用来做数据封包真是很不经济,Yaml和JSON那个不比它简单?用XML来做程序配置文件不知道是谁想出来的主意,相当的愚蠢,看看Unix/Linux下的配置文件,简单易读,相当容易维护。真是高科技啊。
  • SOAP, XML-RPC, WSDL 的 Web Services – 这个东西前几年炒的很凶。所有人都相信,这是程序员的未来。可惜的,其中的复杂和不一致,相当的令人恶心。SOAP的那个S居然还是Simple!看来,扯上XML的都不会是什么好的东东。不过,个人认为,CORBA比他更恶。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (25 人打了分,平均分: 4.24 )
Loading...
一些有意思的网站和贴子

一些有意思的网站和贴子

各位朋友,又到了介绍各种杂项的时候了,正如以前的这篇这篇文章一样,本篇文章也给你介绍一些最近出现的一些有趣的东西。希望你能喜欢。

  • 首先是华尔街的一篇报道,2011年最好和最不好的工作,其引用了CareerCast.com的数据,其列出了100个工作种类,并根据薪资、工作环境、工作鸭梨、体力消耗和就业前景做了一个排序。结果排第一位的是“软件工程师”,其理由是:高科技产品的需求呈爆炸式增长,以及人们对iPod、平板电脑、和其它科技产品应用软件的喜好,软件工程师被评为最佳职业。软件工程师有弹性工作时间,可以在家办公,而且每个月都有猎头找来。而最差是的则是码头工人。
[bestjobspromo]
  • 接下来是一个叫“Java pass by value”的长贴,楼主说有一天在LinkedIn.com上看到了Java Group里有人讨论Java是pass by value的,长达240+贴子。贴子里说,如果你使用Java的原始类型如int, long,就是传值,如果你用object, array,其实传的是一个引用的拷贝,所以,Java是传值的。呵呵,你觉得有道理吗?于是,成就了这个大讨论战。reddit.com上也有N多的回贴。有空可以看看。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (7 人打了分,平均分: 4.57 )
Loading...
偷了世界的程序员

偷了世界的程序员

本文译自美国时代(time.com)的《The Men Who Stole the World》,原作者:Lev Grossman。相当有传奇色彩,读起来很爽,翻译过来。译得不好,还请大家指正。本中的四个程序员可能并不是那么声名显赫,而且也很不老实,或许算不上成功,不过他们的确改变了世界。而本文有分析了互联网上P2P的那些事,相当的有参考价值

2010年12月17日更新:修改了一些错误,理顺了一些语句。
2010年12月19日更新:增加了一些插图。

————————正文————————

十年前,有四个年轻人改变了这个世界的运作方式。他们使用的并不是法律或是武器或是金钱,而是使用软件来改变世界。他们当时有着激进和极具破坏性的想法,并把这些想法付诸于代码,在Internet上以免费自由方式发布。这四个人,没有一个完成了大学学业,却奠定了今天我们习惯的数字媒体环境的基础。然后,因为各种原因,他们也迅速地消失在公众视野中。

1999年,美国东北大学的一个叫Shawn Fanning的一年级新生开发Napster,从此,成为了P2P文件共享和不需要大型机构或零售商就可以获得音乐的先锋和范例。《时代周刊》和《财富》把他放上了封面。那时,他在19岁。

就在同一年,一个挪威的只有十几岁的年轻人 Jon Lech Johansen,他和另两个今天都不为人知的程序员,写下了一个程序解密了商业的DVD,而他成为了全球盛名的“ DVD Jon.”,那年,他只有15岁。

而在1997年,Justin Frankel,一个亚利桑那州塞多纳的18岁的黑客,开发了一个免费的MP3播放器——WinAmp,其成为了Windows操作系统上装机必备的软件,并造就了主流数字音乐的革命。在他发布的第18个月内,1500万人下载了这个软件。而三年后,Frankel 开发了 Gnutella,一个P2P的文件共享协议,没有中心结点,不像 Napster,其不可能被关闭。目前有上百万人还在使用它。

2001年,Bram Cohen, 当年 26 岁,开发了一个P2P的文件传输共享协议—— BitTorrent,其以全新一流的架构全面优化了网络上大文件的共享和传输效率。 BitTorrent 也变成了整个Internet上发布大数据和文件的一个标准。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (46 人打了分,平均分: 4.91 )
Loading...
140个Google的面试题

140个Google的面试题

来源:http://blog.seattleinterviewcoach.com/2009/02/140-google-interview-questions.html(墙)

某猎头收集了140多个Google的面试题,都张到他的Blog中了,主要是下面这些职位的,因为被墙,且无任何敏感信息,所以,我原文搬过来了。
  • Product Marketing Manager
  • Product Manager
  • Software Engineer
  • Software Engineer in Test
  • Quantitative Compensation Analyst
  • Engineering Manager
  • AdWords Associate

这篇Blog例举了Google用来面试下面这几个职位的面试题。很多不是很容易回答,不过都比较经典与变态,是Google,Microsoft,Amazon之类的公司的风格。对于本文,我没有翻译,因为我相信,英文问题是最好的。不过对于有些问题,我做了一些注释,不一定对,但希望对你有帮助启发。对于一些问题,如果你百思不得其解,可以Google一下,StackOverflow或是Wikipedia上可能会给你非常全面的答案。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (19 人打了分,平均分: 4.63 )
Loading...
架构师给程序员的一封信

架构师给程序员的一封信

下面的邮件是某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...