Browsed by
标签: Programmer

三个事和三个问题

三个事和三个问题

从9月份开始,是很多在校毕业生的择业时期,有很多很多朋友写邮件给我让我帮他们参考如何选择工作(对不起我无法在第一时间回信,因为实在是太多了,我那繁忙工作和生活都没办法让我能即时回复),并且还有一个已经工作了多年的技术很强的朋友因为跳槽没有跳好,也和我说了很多他 的感受。从这个过程中让我有了很多感触和想法想和大家分享,本来这篇文章1个月前就想写的,只是要写下来时不知道如何整理这么多的东西和思绪。今天也不知道,但是一定要写了,不然,我的这些感触和想法就会越来越不新鲜了。

注:这篇文章里的所有的故事都是真实的其不可避免地会加上我强烈的个人情怀和个人色彩叙述的过程可能比较乱,但我能确保这些都是我的肺腑之言

第一个事:网友的来信

第一个故事是一个杭州的学生的故事,其有两个offer,一个是北京的(雅虎研发中心),另一个是杭州的一个做商业智能软件的公司,也是美国的上市公司。他在给我的来信内心纠结地说:

雅虎其实很想去,虽然这几年雅虎走下坡,但还是大公司,牌子硬,里面牛人也多,有助于自己水平的提升。但感觉北京环境不好,生活不是那么舒坦,也搞不定户口,所以我去的话也只能干个三五年就得考虑跳槽到别的城市安家落户了。这么一跳,在北京积累的各种资源却又带不走 。

杭州,比北京更适合生活,户口不是问题,朋友多,这个公司也比较宽松,有较多的业余时间跟朋友们一起搞点东西。而且这些年这个公司上升的势头,在国内设研发中心也才4年,规模不大,公司本身规模也还不大,我觉得机会还不错。再加上离家近,对家人大概可以多些照应。

关于未来换工作,雅虎做的是搜索,广告,移动互联这几个方面的,东西在互联网企业里面都比较通用,以后跳槽的话,面相对比较宽。杭州的那个做商业智能的公司,据了解其他做的比较好的也就几个大公司如SAP,IBM有这方面的业务。

我和这个同学发了邮件,也打了长途电话,我基本上是这样回复的——

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (73 人打了分,平均分: 4.56 )
Loading...
来信, 创业 和 移动互联网

来信, 创业 和 移动互联网

上一篇博文翻译了Steve Yegge的rant,这两天有一些事让我也想rant一下(所谓rant就是一篇巨长无比的抱怨和说教),不过无论是从见解还是恶搞来说肯定没有SteveY的水平高,所以,这篇博文只是单纯的rant,看标题就知道了,就像“篱笆,女人和狗”一样,乡土味实足。所以,下述的一些观点未必正确,也未必靠谱,也就是我的个人唠叨罢了,我想到哪里说到哪里。(篇幅较长,见谅)

引子

我前两天,收到一封邮件,一位快要毕业的的大学生问我,是去百度,还是去创新工场?他在来信中说,从个人道德价值观来说,他想去创新工场,要远离流氓企业,不然会有狼狈为奸、助纣为虐的感觉,对不起自己。但是创新工场那边情况不熟悉, 不知道怎么选择,并问我现在比较热的移动互联网靠不靠谱。

正好这两天我在微博里看到大家转贴李开复的几个让毕业生创业的微博,比如,这个微博,还有 这个微博。呵呵。

李开复:有关毕业生高科技创业,我的建议:1)创业需要理解趋势、汇集精英、实践经验,因此大学毕业不要主导创业,只能参加创业公司,2)最好远在毕业前就寻找创业公司实习机会(无偿亦可),因为也许创业并不适合你或你想象那样,3)毕业时若想学习创业,最好到创业公司。到大公司学习能学技术但不够针对性。

还有前两天的“移动开发者大会”,然后,又有一个以前的同事和我谈了一下他创业的事以及他的想法,正好又在网上看到罗永浩同学的那个“一个理想者创业的故事”的演讲。还有一些做blog插件的团队希望我能在酷壳上安装一下他们的插件。等等,等等。所以,让我有了这个可以rant的写作情绪。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (102 人打了分,平均分: 4.63 )
Loading...
多些时间能少写些代码

多些时间能少写些代码

我在我的微博上说过这样一段话,我想在这里把我的这个观点阐述地更完整一些。

@左耳朵耗子:聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30% – 50%的时间是在忙碌着编码,调试和测试。聪明的老板也会让团队这样做。而傻逼的老板,苦逼的程序员会拿出来100%-150%的时间来忙着赶进度,返工,重构,fix 大量的bug… 所以, 越差的团队一般会越忙,而且还忙不完。

在现在这个浮躁的时期,再加上敏捷咨询师们念的歪经,他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的,这令那些管理者们很兴奋,就像巴甫洛夫的条件反射实验中的狗看到了肉就会流口水那样兴奋。他们使用TDD,快速迭代,不断重构,持续集成直至持续部署的方法在进行软件开发。

软件开发真是这样的吗?难道不需要花时间去思考吗?对此,有些观点在Todd的《“品质在于构建过程”吗?》以及《Bob大叔和Jim Coplien对TDD的论战》中谈到过了。我只想想表达下面的观点:

  • 软件的精髓在于设计,设计是一件很费大脑的事件。对于软件来说,设计没有完美的,它总是一件需要取舍需要权衡的事,比如:时间换空间,空间换时间,TCP或UDP,同步还是异步,数据冗余还不冗余等等。那怕是一个小小的observers模式是pull方式还是push方式 都需要仔细讨论。这些的东西需要时间和做前期尝试。
  • TDD快速原型和迭代可能会对软件和团队产生负面影响。在一开始,你需要花很大的精力来让你的软件从无到有(做过软件的人都知道,从零开始写代码是很痛苦的事),但是因为你没有想好,先做再说,所以,后期你会面临更多的质量问题而让你需要花更多的时间精力。当然,那些咨询师会让你用持续集成和持续部署这样的方法。但我想告诉你,这并不解决你软件设计的缺陷。举个例子——TDD、迭代、原型只关注功能性需求,其不会关注非功能性需求,比如性能问题,高可用性问题,系统维护问题(模块的耦合问题),等等。而这些问题往往都可以让你的软件设计重新来过。
  • 重构是恶梦,重构应该越少越好。当你维护一个复杂的系统时你会知道重构是一件多么恐怖的事情(参看《重构代码的7个阶段》)。如果一开始没有想好,你要面临的不单单是re-design, re-architect,还要面对时间和人力成本的增加,最难的是你还要面对的是团队士气因为不断的rework而逐渐低落并产生厌倦和懈怠情绪。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (28 人打了分,平均分: 3.82 )
Loading...
Stay Hungry, Stay Foolish !!

Stay Hungry, Stay Foolish !!

在整个社会都在关注乔帮主的时候,我想在这里和大家分享一个真实的就在我们程序员身边的故事。和我在《如果你看不见你还能编吗?》一文里介绍的那些盲人程序员一样,同样是Stay Hungry, Stay Foolish。但我个人更认为我今天想要给大家讲述的这个故事对于我们这些普通人更有意义一些。我真心的希望大家认真看完这个“从刷厕所到程序员”故事后,我们能从中感悟到点什么

因为朋友的原因,我和一个创业团队经常有些往来,通过这个团队,我认识了这个故事的主人翁——王平(@wpingsuper)。其实,很早前他在Google Reader和Buzz里follow了我,但我从没和他交流过。而他的经历我却是在上周末去看望这个创业团队的时候才听说。我问他们要了王平的电话,联系了王平,详细地了解了王平的经历,并征得他的同意,在这里给大家分享他的故事。

王平是一个贵州人,03年大学毕业,体育专业,没有任何家庭背景,只能在贵州的山区里的一个中学里当体育老师,月薪150元。可能和大多数心怀梦想的年轻人一样,他并不甘心,从03年到05年间,他有好多次到北京,他觉得在大城市里有他的梦想。于是,他在04年底,05年初,他正式来到了北京,因为大学专业的问题,他无法找像大学生一样找到不错的工作,那时的他只能在北京一家很小的餐馆当清洁工,他在餐馆里洗盘子,扫地,刷厕所,一个月400元钱。

因为他的学历是这个小餐馆里学历最高的,所以,餐馆里出了什么事都会让他对去搞,所以,财务使用的电脑有了故障也让他去修,当时的他根本对电脑完全不知道是怎么一回事,但是自从接触了电脑以后他就迷上了电脑。他和我说,他这个人就是好奇心强,好动,什么都想弄一弄,所以,时间长了,弄得多了,也能为餐饮解决一些没有懂的问题,维护财务电脑就是其中之一。日子一长,虽然还是刷厕所,但是薪水也涨到了800元一个月,就连餐馆的大厨也对他说,他不属于这里,他将来一定会有前途的。当时的他还觉得不可能,笑了笑就过了。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (80 人打了分,平均分: 4.73 )
Loading...
如果你看不见你还能编程吗?

如果你看不见你还能编程吗?

这是个StackOverflow上的问题 How can you program if you’re blind? 。在看到这个问题的时候,我感到应该不可能,但是我错了,这个问题的前两个答案让我深深地震憾了。

第一个答案的回复人是Jared(其在StackOverflow上的积分有将近14K),但是你能想得到他是一个盲人吗?他回复到——

我是一个完全失明的大学学生,我做过一些程序员的实习工作,所以我的回复基于我的这些经历。我使用Windows XP 和  Jaws 来为了读出屏幕上的内容。

对于Java 编程,我使用eclipse这个强大的IDE。我使用SWT开发GUI。对于.NET编程,其使用Visual Studio 2005,使用Jaws可以非常容易地操作VS2005,而且其还有一些很不错的脚本来可容易地用来做表单设计。

对于C/C++,我使用cygwin + gcc 也使用emacs 和 vim 做出编辑器(使用Emacspeak虽然有时候有点迟钝)。在实习过程中,我做了很多和Z/OS相关的编程工作。我使用rlogin通过cygwin登录大型机的USS系统,并使用C3270作为其3270仿真器来访问大型机的ISPF部分。

我依赖于合成语音系统,也需要 Braille display, 我发现使用合成语音系统很快,但是使用 Braille display有时候有些问题。比如程序有太多的嵌套括号。

关于Braille display,又叫盲文显示机,是能以盲文进行输出的电子机械式设备。一般来说,该设备通过在平坦表面上打孔来实现点阵的表现。有了该设备的帮助,无法使用一般的显示设备的失明用户也能够阅读文字。如下所示。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (62 人打了分,平均分: 4.71 )
Loading...
千万不要把 bool 设计成函数参数

千万不要把 bool 设计成函数参数

我们有很多Coding Style 或 代码规范。但这一条可能会经常被我们所遗忘,就是我们经常会在函数的参数里使用bool参数,这会大大地降低代码的可读性。不信?我们先来看看下面的代码。

当你读到下面的代码,你会觉得这个代码是什么意思?

widget->repaint(false);

是不要repaint吗?还是别的什么意思?看了文档后,我们才知道这个参数是immediate, 也就是说,false代表不立即重画,true代码立即重画。

Windows API中也有这样一个函数:InvalidateRect,当你看到下面的代码,你会觉得是什么意思?

InvalidateRect(hwnd, lpRect,  false);

我们先不说InvalidateRect这个函数名取得有多糟糕,我们先说一下那个false参数?invalidate意为“让XXX无效”,false是什么意思?双重否定?是肯定的意思?如果你看到这样的代码,你会相当的费解的。于是,你要去看一下文档,或是InvalidateRect的函数定义,你会看到那个参数是 BOOL bErase,意思是,是否要重画背景。

这样的事情有很多,再看下面的代码,想把str中的”%USER%”替换成真实的用户名:

str.replace("%USER%", user, false); // Qt 3

TNND,那个false是什么意思?不替换吗?还是别的什么意思,看了文档才知道,false代码大小写不敏感的替换。

其实,如果你使用枚举变量/常量,而不是bool变量,你会让你的代码更易读,如:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (31 人打了分,平均分: 3.87 )
Loading...
C语言中史上最愚蠢的Bug

C语言中史上最愚蠢的Bug

本文来自“The most stupid C bug ever”,很有意思,分享给大家。我相信这样的bug,就算你是高手你也会犯的。你来看看作者犯的这个Bug吧。。

首先,作者想用一段程序来创建一个文件,如果有文件名的话,就创建真正的文件,如果没有的话,就调用?tmpfile()?创建临时文件。他这段程序就是HTTP下载的C程序。code==200就是HTTP的返回码。

else if (code == 200) {     // Downloading whole file
    /* Write new file (plus allow reading once we finish) */
    g = fname ? fopen(fname, "w+") : tmpfile();
}

但是这个程序,只能在Unix/Linux下工作,因为 Microsoft 的?tmpfile()的实现?居然选择了 C:\ 作为临时文件的存放目录,这对于那些没有管理员权限的人来说就出大问题了,在Windows 7下,就算你有管理员权限也会有问题。所以,上面的程序在Windows平台下需要用不同的方式来处理,不能直接使用Windows的tmpfile()函数。

于是作者就先把这个问题记下来,在注释中写下了FIXME:

else if (code == 200) {     // Downloading whole file
    /* Write new file (plus allow reading once we finish) */

    // FIXME Win32 native version fails here because
    //   Microsoft's version of tmpfile() creates the file in C:\
    g = fname ? fopen(fname, "w+") : tmpfile();
}

然后,作者觉得需要写一个跨平台的编译:

FILE * tmpfile ( void ) {
#ifndef _WIN32
    return tmpfile();
#else
    //code for Windows;
#endif
}

然后,作者觉得这样实现很不好,会发现名字冲突,因为这样一来这个函数太难看了。于是他重构了一下他的代码——写一个自己实现的tmpfile() – w32_tmpfile,然后,在Windows 下用宏定义来重命名这个函数为tmpfile()。(陈皓注:这种用法是比较标准的跨平台代码的写法)

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (43 人打了分,平均分: 4.40 )
Loading...
弱爆程序员的特征值

弱爆程序员的特征值

感谢网友投递此文,很欢乐也有意思,与大家共勉

首先说明:

1、以下特征是真实遇到过的,同事犯过的,乃至我自己也犯过的;
2、为了剧情需要,某些例子进行了一些夸张修饰等演绎创作,如无雷同,请勿生气;
3、如果你出现过以下症状之一,并不代表你就是弱爆了,但是如果你一直出现,乃至一说到这个大家就能联想到你,那么你就得小心了;
4、如果你是集这几个的大乘者,恭喜你,你已经找到了离开这个行业的充足理由了。

好了,搞定!

“那个Bug解决了吗?”

“好了,搞定!”

“这么快?”

正当你非常欣喜的时候,就传来了噩耗:刚才还能编译成功的,就失败了。(好吧,我们的集成编译尚未成功配置上,理论上这种事情应该会被退回。)又或者能编译成功,但是呢,原来明明能起作用的一个下拉框,突然发神经的不起作用了。最隐蔽的莫过于,一切正常,但是当你看到代码的时候,你就晕厥过去了。比如我们曾经发现了一个Bug,简单说就是每次用户点击某个东西,就会执行下面的这段C#代码:

controlPropertyPanel.PropertyChanged += this.UpdatePropertyOnChanged;

这个Bug很明显会导致速度越来越慢,因为同一个更新操作会被更新N次,并且这个N会越来越大。其实这个Bug已经够弱了,但是后来居然被修改为:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (26 人打了分,平均分: 3.77 )
Loading...
重构代码的7个阶段

重构代码的7个阶段

你曾去想重构一个很老的模块,但是你只看了一眼你就恶心极了。文档,奇怪的函数和类的命名,等等,整个模块就像一个带着脚镣的衣衫褴褛的人,虽然能走,但是其已经让人感到很不舒服。面对这种情况,真正的程序员会是不会认输的,他们会接受挑战认真分析,那怕重写也在所不惜。最终那个模块会被他们重构,就像以前和大家介绍过的那些令人销魂的编程方式中的屠宰式编程一样。下面是重构代码的几个阶段,文章来自:The 7 stages of refactoring,下面的翻译只是意译。

第一阶段 – 绝望

在你开始去查看你想要重构的模块的,你会觉得好像很简单,这里需要改一个类,那里需要改两到三个函数,重写几个函数,看上去没什么大不了的,一两天就搞定了。于是你着手开始重构,然后当你调整重构了一些代码,比如改了一些命名,修理了一些逻辑,渐渐地,你会发现这个怪物原来体型这么大,你会看到与代码不符甚至含糊不清的注释,完全摸不着头脑的数据结构,还有一些看似不需要方法被调了几次,你还会发现无法搞清一个函数调用链上的逻辑。你感到这个事可能一周都搞不定,你开始绝望了。

第二阶段 – 找最简单的做

你承认你要重构的这个模块就是一个可怕的怪物,不是一两下就可以搞定的,于是你开始着干一些简单的事,比如重新命名一下几个函数,移除一些代码的阻碍,产生几个常量来消除magic number,等等,你知道这样做至少不会让代码变得更糟糕。

第三阶段 – 再次绝望

但是接下来的事会让你再次撞墙。你会发现那些代码的瑕疵是些不痛不痒的事,改正这些事完全于事无补,你应该要做的事就是重写所有的东西。但是你却没有时间这么干,而这些代码剪不乱理还乱,耦合得太多,让你再一次绝望。所以,你只能部分重写那些不会花太多时间的部分,这样至少可以让这些老的代码能被更多的重用。虽然不完美,但是至少可以试试。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (32 人打了分,平均分: 4.31 )
Loading...
你确信你了解时间吗?

你确信你了解时间吗?

你还记得“软件真的好难做”中的那个有意思的例子吗?那个例子告诉我们软件开发中假设可能会是致命的事。今天,我又在StackOverflow上看到一个关于时间的问题——为什么1927年12月31日的午夜时间这么奇怪?提问题的这个人给了下面的一段java代码(我做一些修改,保证让你可以copy过去就可以编译运行)

我在其中高亮了几行,这个程序就是想比较一下“1927-12-31 23:54:07”  和  “1927-12-31 23:54:08” 差几秒,很明显,是差一秒。但是程序的输出却不是这样的。

import java.text.SimpleDateFormat;
import java.text.ParseException;
import java.util.Date;
import java.util.TimeZone;
class time{
    public static void main(String[] args) throws ParseException {
        SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        sf.setTimeZone(TimeZone.getTimeZone("Asia/Shanghai"));
        String str3 = "1927-12-31 23:54:07";
        String str4 = "1927-12-31 23:54:08";
        Date sDt3 = sf.parse(str3);
        Date sDt4 = sf.parse(str4);
        long ld3 = sDt3.getTime() /1000;
        long ld4 = sDt4.getTime() /1000;
        System.out.println(ld3);
        System.out.println(ld4);
        System.out.println(ld4-ld3);
    }
}

 

阅读全文 Read More

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