架构之路——穿行在产品和业务之间
篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011。
该内容已经被标记书签!
标记书签错误,请重试!

作者 Jurgen Appelo 译者 李剑 发布于 2009年1月20日
1月13日,著名博客作者Jurgen Appelo写了一篇博文:“软件开发者面试百问”。该文甚受读者欢迎,15日便登上了delicious,Popurls.com,Reddit的首页。InfoQ中文站在得到作者许可之后,将其全文翻译为中文,希望可以对国内读者有所助益。
以下为文章全文:
想雇到搞软件开发的聪明人可不容易。万一一不小心,就会搞到一堆低能大狒狒。我去年就碰到这种事了。你肯定不想这样吧。听我的,没错。在树上开站立会议门都没有。
问点有难度的问题能帮你把聪明人跟狒狒们分开。我决定把我自己整理出来的软件开发者面试百问发出来,希望能帮到你们的忙。
这个列表涵盖了软件工程知识体系中定义的大多数知识域。当然,如果你只想找出类拔萃的程序员,便只需涉及结构、算法、数据结构、测试这几个话题。如果想雇架构师,也可以只考虑需求、功能设计、技术设计这些地方。
不过不管你怎么做,都要牢记一点:
这里大多数问题的答案都没有对错之分!
你可以把我的这些问题作为引子,展开讨论。例如下面有个问题是使用静态方法或是单例的缘由。如果那个面试的就此展开长篇大论,那他很有可能是个聪明能干的家伙!如果他一脸茫然的看着你,发出这种声音,很明显这就是只狒狒了。同样,想知道一个数是不是2的乘方也有很多方法,不过要是面试的人想用mod运算符,嗯……你知道我的意思吧。(你不知道也没关系,来根香蕉?)
需求
功能设计
技术设计
程序设计
算法
数据结构
测试
维护
配置管理
项目管理
阅读英文原文:100 Interview Questions for Software Developers。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
如题
好像挺难,关键没有参考答案,有N种想法,不知道对不对啊
me too!
当然,software engineering本身译为软件开发也不错。但是SWEBOK作为一个文献,大家已经习惯那么叫了。这又引出一个问题:软件工程和软件开发在中文里有区别么?大家可能更习惯软件开发的狭义,也就是写代码那些事情吧,与测试、需求、设计之类相对?
同样,哈希的标准译法是散列。哈希是误译,估计是错误认为人名了。
还有测试栈是啥意思?stack在表示数据结构之外,最好译为组、组合之类,比如TCP/IP协议组,LAMP技术组合等等。你译为栈,中国人怎么也想不通的。
噢,看了原文,是test suite,那就应该译为测试套件之类的嘛。
re-engineering和reverse engineering可以分别译为再工程和逆向工程,加英文标注即可。
小标题“结构”,也就是“1. 你怎样保证你的代码可以处理各种错误事件?”之前的那个,原文是construction,译为构造或者代码编写、程序设计应该都可以。
在大学学《数据结构》结构的时候,都是叫“哈希表”的吧;另外“栈”好像也是通用语,什么软件栈(software stack),工具栈(tool stack)。这两个词语都好像已经成约定俗成的用法了。
在大学学《数据结构》结构的时候,都是叫“哈希表”的吧;另外“栈”好像也是通用语,什么软件栈(software stack),工具栈(tool stack)。这两个词语都好像已经成约定俗成的用法了。
这些我都知道,但是不能将错就错,墨守成规啊。约定俗成也是在变化的。哈希其实已经逐渐被散列替代了。
软件栈、工具栈都是不通的翻译,其实可以避免的。而且你在Google里搜一下工具栈,哪里能看出约定俗成?软件栈虽然多,也能看出大家用起来很别扭,有些地方是打引号的。更通行的是协议栈,可以说是约定俗成了,大致可以接受。但是Google的第二个结果就是“协议与协议栈到底不什么不同啊?”
已经都按照刘江老师的建议改过来了。
软件工程知识体系那个完全是误译,没走大脑,engineering怎么也不会译成开发的。
哈希那个是因为从学算法的那时就一直说哈希,所以就改不过来了。。以后会注意的。
test suite那个也是没走大脑的误译。
作者说过了:这里大多数问题的答案都没有对错之分!
配置管理的第六条中,“用什么侗剧管理”应该是“用什么工具管理”。
我想這幾個問題
台灣所有的資深PG都答不出來吧
大狒狒搞IT
真令我大笑一場
大多数是狒狒,我喜欢吃香蕉
确实有不少的东西平时没有用到,自己就没有深入了解!...惨愧啊, 还是要每天都看书才行
"哈希"是hash的音译,"散列"是意译。现在一般文章中"散列"用得多,"哈希"在教科书中用得多。
啊哈,是拼音输入法,没检查到,多谢多谢
当然,全部是我个人的答案,不代表别人。地址
www.laozizhu.com/program.jsp?typeId=104
或者到Google搜索“软件开发者面试百问答案” 也可以。
--------------------------------------------------
老紫竹研究室,分享软件开发的快乐与收获
这些问题是给大家用来引出话题的,来考察知识结构完整和思维方式差异的。其中很多内容是没有标准答案,而且即便有标准答案,但是也不是需要你提供一个标准答案,而是需要你能够发表出自己的见解。同时也要注意,这些问题中有的是有地域性或者时间性等环境差异的,比如“DSDM、Prince2、Scrum,这三者之间有哪些区别”,问在英国的人就比较合适;而在国内,可以问RUP、XP、TSP之间的差别;而如果你是想去问一个敏捷者,则可以问DSDM,SCRUM,XP之间的关系之类的。同时这些话题都是一个起点,用来进行深入讨论的起点。比如说举一个非功能性需求的例子,然后你可以继续问非功能性需求是不是可以转化为功能性需求,举一个例子。
一定要注意,这些题目都是开放的,有着不同的学术背景和开发背景的人会给出各种不同的回答,很多时候其中并不对错(当然如果确实有错误,那么说明这个人显然有缺陷)。而使用的时候,关键是要能跟着对方的思路,进一步的追问,比如追问到第三步话题。再举一个例子吧。
问:如果客户想要的东西太多,你在范围和时间上怎样跟他达成一致呢?
答:那我们就把这些东西都做细化,分项,然后逐项讨论,最后进行综合,叫客户自己看到我们的范围和时间是如何确定的。
问:那么该如何细化呢?
答:我们会采取功能分配法,也就是将一个大需求分开,按照各个操作点,逐步进行分配。
问:您能深入介绍一下功能分配法吗,我对这个很有兴趣。特别是操作点又是如何划分的呢?
答:。。。。。。。。
如此如此,就可以了。
而实际上,除非是这些问题过于具有地域等客观约束,否则大家都应该能够说点东西出来。当然可能谈不上完美,但是你没有自己的看法,就不是太应该了。而且回答的时候,未必需要严格按照原有的格式回答。比如问你喜欢用哪种图跟踪项目进度,你就可以说我用的是FDD方面,是一种利用feature跟踪进度的方法,可以用彩色的图版,但是不能说是一种图,而是一系列的图和数字。
最后再给大家打点预防针,这些问题是提供给大家思考和讨论的,不是给大家判分的。凡是去找标准答案的,可以免了。而凡是提供标准答案的,大家可以直接无视好了。而去看别人如何答的,基本上都得不到太多。因为我前面说过,这些问题都是一个起点,深入下去才能看到价值和结果。
快点给多点香蕉过来,我在你们眼中都是一只大狒狒
拿这些题去面试别人
而不是接受这场面试
照你这样面试方法,我估计得去微软总部去招人. 适合的就是对的. 一个十几人小公司有钱请这样的牛人么?人家也不来.
珍藏了,以后用来问别人
好多的香蕉~~~
应该还没有进化好。
按这个要求,北京上海等大城市拿7000以上的,10个有9个是猩猩。
基本都忘光了, 对我这种不注重积累的人
我见意把这篇文章删了,这个作者就是个狒狒,fei青,他知道的这些知识不知道有几样他是精的,我可以给他来个面试
没有区别,都不知道。
完了,我也大部分都不知道.有答案么?
本就是没有一个标准的问题
很受启发,像楼上有人说的,关键不是答案 而是从问题上想到了什么,向哪个方向思考问题了,呵呵 以后还得继续学习啊 感谢作者
这些问题是给大家用来引出话题的,来考察知识结构完整和思维方式差异的。其中很多内容是没有标准答案,而且即便有标准答案,但是也不是需要你提供一个标准答案,而是需要你能够发表出自己的见解。
同意! 更重要的是学会怎么提问,怎么思考和怎么解答.
要学多少东西才能达到这水平?
不学习就会被人家鄙视成狒狒
这些问题是给大家用来引出话题的,来考察知识结构完整和思维方式差异的。其中很多内容是没有标准答案,而且即便有标准答案,但是也不是需要你提供一个标准答案,而是需要你能够发表出自己的见解。同时也要注意,这些问题中有的是有地域性或者时间性等环境差异的,比如“DSDM、Prince2、Scrum,这三者之间有哪些区别”,问在英国的人就比较合适;而在国内,可以问RUP、XP、TSP之间的差别;而如果你是想去问一个敏捷者,则可以问DSDM,SCRUM,XP之间的关系之类的。同时这些话题都是一个起点,用来进行深入讨论的起点。比如说举一个非功能性需求的例子,然后你可以继续问非功能性需求是不是可以转化为功能性需求,举一个例子。
一定要注意,这些题目都是开放的,有着不同的学术背景和开发背景的人会给出各种不同的回答,很多时候其中并不对错(当然如果确实有错误,那么说明这个人显然有缺陷)。而使用的时候,关键是要能跟着对方的思路,进一步的追问,比如追问到第三步话题。再举一个例子吧。
问:如果客户想要的东西太多,你在范围和时间上怎样跟他达成一致呢?
答:那我们就把这些东西都做细化,分项,然后逐项讨论,最后进行综合,叫客户自己看到我们的范围和时间是如何确定的。
问:那么该如何细化呢?
答:我们会采取功能分配法,也就是将一个大需求分开,按照各个操作点,逐步进行分配。
问:您能深入介绍一下功能分配法吗,我对这个很有兴趣。特别是操作点又是如何划分的呢?
答:。。。。。。。。
如此如此,就可以了。
而实际上,除非是这些问题过于具有地域等客观约束,否则大家都应该能够说点东西出来。当然可能谈不上完美,但是你没有自己的看法,就不是太应该了。而且回答的时候,未必需要严格按照原有的格式回答。比如问你喜欢用哪种图跟踪项目进度,你就可以说我用的是FDD方面,是一种利用feature跟踪进度的方法,可以用彩色的图版,但是不能说是一种图,而是一系列的图和数字。
最后再给大家打点预防针,这些问题是提供给大家思考和讨论的,不是给大家判分的。凡是去找标准答案的,可以免了。而凡是提供标准答案的,大家可以直接无视好了。而去看别人如何答的,基本上都得不到太多。因为我前面说过,这些问题都是一个起点,深入下去才能看到价值和结果。
今天再看的时候,这样回答很不错:注重过程而不是结果
请问为什么不能用mod运算符啊?
篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011。
本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。
随着JDK 7的发布,字节码指令集终于迎来了第一位新成员——invokedynamic指令。这条新增加的指令是JDK 7实现“动态类型语言(Dynamically Typed Language)”支持而进行的改进之一,也是为JDK 8可以顺利实现Lambda表达式做技术准备。在这篇文章中,我们将去了解JDK 7这项新特性的出现前因后果和它的意义。
随着互联网应用的发展,Java分布式远程服务技术受到越来越多的关注,本文将对各种相关实现以示例的形式逐一介绍,并总结其中的优缺点,使读者能够在技术选型时有所准备。这是文章的下篇。
《精通HTML5和CSS3设计模式》一书记录了目前HTML5应用程序的许多常见设计模式。InfoQ对该书作者之一Dionysios Synodinos进行了采访,谈到了该书以及HTML5应用的相关内容。
本次将与大家分享B2B在构建生态化分布式数据库架构体系的摸索和实践,介绍B2B为解决海量数据实时访问,数据按需流转等业务场景开发的一系列技术产品,以及各个技术产品之间如何进行协调一致。这些产品将在不久的将来会出现在B2B的开源站点,希望给大家带来一些帮助。
本次演讲视频录制于QCon杭州2011。
淘宝无线Android客户端架构设计思路汲取了移动平台上大型跨平台应用开发的经验,同时借鉴于大型网站的web开发框架思路。且看淘宝客户端如何通过 Component Model, Web Plus来面对挑战。
37 条回复
关注此讨论 回复