Shell's Home

Oct 18, 2012 - 1 minute read - Comments

没想法

前两天面了一个同学,是我在交大的学弟。平时印象挺不错,用过的技术也挺多的,和老板商量一下,就面试看看吧。

结果不能算糟,但是也谈不上多好。主要是,这同学没想法。

不知道和没想法

老板最恨的一件事情,就是在问你一个问题的时候,你手一滩,说”我不知道“。其实严格来说,他并不介意你说”我不知道“(I don’t know),但是绝对不要说“我没想法”(I have no idea)。

拿面试时候的例子来说吧。那位同学讲了一个实验室里面的项目,用web来控制小车。当然,那是个没做完的项目,有什么问题也不是值得奇怪的事情。我们开始的时候问了几个问题,感觉还可以。事情是从我随口的一个问题开始的:”如果两个人同时操作,会发生什么事情?“

两个人同时操作在设计上是不允许的,完备的系统可以通过一些方法来排除这种可能。例如,见到第二个cookie就给一个空页面回去。项目没做完,没屏蔽掉第二个人,也不是什么值得奇怪的事情。但是我想知道的是,对于这么一个未定义的事情,被面试的人是如何分析的。

按照正常流程来说,分析这个问题首先需要知道基本的工作原理,然后拆分工作流程,最后分析,如果两个指令同时到达,会发生什么现象。问题是,该同学阻塞了半天,啥都没干。我和老板询问了整个系统工作的原理,发现他对基本原理都是了解的。我们按照他所说的原理,推断出了两个人同时操作会发生的结果。当然,是否正确,谁也不知道。但是我们的结论是,他在具备所有推论需要的知识的情况下,没有做出任何推论和结果。

这是一个很扣分的事。

不知道

所谓不知道,是指你的知识(knowledge)不足以解答当前的问题。例如,对于非程序员,我问你,python中用于逐次返回数据的关键字叫什么。你手一摊,告诉我,我不知道。这是因为你压根没学过python,当然不知道yield。

不知道并不是值得羞耻的事情,无论多强的程序员,总有什么东西是他不知道的。新的语法,新的框架,还有我们没听说过的技术。作为程序员,什么都知道反而是一件无比诡异的事情。

没想法

很多时候,没想法是因为不知道。例如,假定你对股票市场的工作机理一无所知,尽管你完全可以理解,作为正常人类都是希望高买低卖。但是当我问你,股票市场表现如何的时候,你也只能手一摊,我一点想法也没有。这不仅仅是你不知道,而且你都不知道该如何去分析这个问题。

因此正常程序员见到一个不知道的系统,第一个问题十有八九是,这系统干什么的。第二个问题就是,这系统怎么工作的。当你知道了系统的大致工作机理,就会想出如何分析这个系统的方法。

例如,我们有一个网络系统,老板说网页访问慢。元芳你怎么看?

这后面没什么天大的秘密。我们只要照着网页访问的流程来看就好。

  1. DNS解析
  2. tcp连接
  3. http请求
  4. http返回
  5. DOM解析
  6. js执行

网页慢,首先分析最慢的地方在哪里。这里的每一步,都是能够计量的。我们再假设,我们发现最慢的是http请求和返回,那么我们基本就把问题定位在了服务器或者网络容量达到极限。那我们又如何分析是对方服务器太慢还是我们自己网络太慢呢?

只要你没傻,都应该想的到,最简单的方法就是同时开一个比这个页面快的多的系统,一个不会慢的服务器。最合适的是google和baidu的首页。如果还是慢,那就是我们的网络问题。如果快了,就是对方服务器到极限了。

做出这个分析,并不需要什么惊人的知识,也不需要你有足够的经验。当然,经验可以帮助你快速的排查问题,当出现某些现象的时候,别人还在做诊断,你就可以直接做定性测试和结果了。

你可以不知道,不可以没想法

作为程序员,我可以接受你告诉我,你不知道。但是一般我不能接受你告诉我,你没想法,尤其是在一些情况很明白的核心问题上。如果这是一个很困难的问题,没想法也不奇怪。有些很妖怪的问题,例如为什么我们的系统在人少的时候OK,人多了就挂了,再多又没事了。通常的性能计数又没异常,问题随机出现,无法复现。像这种妖异的问题,我没想法,你没想法,我问别人也没想法。但是如果我问你,网页为什么慢,你告诉我,没想法。或者更夸张的,在不经过相关测试的情况下,随便看了看现象就告诉我——这是我们的网络带宽不够大——你丫当我村干部糊弄呐!

没想法表示你对这个系统没办法。你没办法做一些事,在可预期的成本和时间内解决问题。你能做的就是去网络上找出过这个问题的人,他们的解决方案,然后照做。coolshell管这个叫做散弹枪式编程,我管这个叫做博彩。散弹枪不是一个很坏的主意,对于一些你不关心又需要很快解决的问题,你可以散弹枪一把。但是如果你在头三个方案内都没解决问题的话,你就可以停手了——后续方案能解决问题的概率和头三个没有太大分别。

有的时候,散弹枪是一个非常糟糕的做法。例如我们上面那个——网络带宽不够大——的例子,你很容易在网络上看到这个解答,但是往往这不是正确的答案。我是说,很多人确实是因为网络带宽不够,所以出现了网页缓慢。但是网页缓慢的原因,还有一个是因为延迟和丢包率太高。而增加带宽可解决不了延迟和丢包率。甚至相反。我们可以想像这么一个可怜的例子。当技术瞎猜到——是你的带宽不足——时,老板就会对行政说,去给我换一个给力的带宽。于是行政要升级带宽——又要控制成本,十有八九,他们会找上一家小ISP。ISP的性价比非常可观,行政和老板都很满意。唯一的问题,是他们的延迟和丢包率比上一家更加糟糕。

你看,散弹枪不但没打中目标,还使得情况更加糟糕了。

类似的问题还出现在大型电商系统的架构上。如果架构师和SA的答案永远是——硬件不给力,你需要好好考虑一下,真的是硬件不给力,还是这只是一个拖延的借口。如果架构不合适,当规模达到一定量级后,无论你再堆多少的硬件,可支撑用户数都不会有太高的提升。

Tags: thinking

回到毛泽东时代 pycon2012

comments powered by Disqus