模块化Java:声明式模块化
本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。

作者 Jurgen Appelo 译者 李剑 发布于 2009年1月20日 上午2时2分
1月13日,著名博客作者Jurgen Appelo写了一篇博文:“软件开发者面试百问”。该文甚受读者欢迎,15日便登上了delicious,Popurls.com,Reddit的首页。InfoQ中文站在得到作者许可之后,将其全文翻译为中文,希望可以对国内读者有所助益。
Flash Builder 4 Beta和FlexUnit下的测试驱动开发
革命性的软件培训年会,全场20余个热门课题全真案例精讲,每个workshop花费半天时间深度分享,讲师来自大型研发团队的一线带头人!
以下为文章全文:
想雇到搞软件开发的聪明人可不容易。万一一不小心,就会搞到一堆低能大狒狒。我去年就碰到这种事了。你肯定不想这样吧。听我的,没错。在树上开站立会议门都没有。
问点有难度的问题能帮你把聪明人跟狒狒们分开。我决定把我自己整理出来的软件开发者面试百问发出来,希望能帮到你们的忙。
这个列表涵盖了软件工程知识体系中定义的大多数知识域。当然,如果你只想找出类拔萃的程序员,便只需涉及结构、算法、数据结构、测试这几个话题。如果想雇架构师,也可以只考虑需求、功能设计、技术设计这些地方。
不过不管你怎么做,都要牢记一点:
这里大多数问题的答案都没有对错之分!
你可以把我的这些问题作为引子,展开讨论。例如下面有个问题是使用静态方法或是单例的缘由。如果那个面试的就此展开长篇大论,那他很有可能是个聪明能干的家伙!如果他一脸茫然的看着你,发出这种声音,很明显这就是只狒狒了。同样,想知道一个数是不是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青,他知道的这些知识不知道有几样他是精的,我可以给他来个面试
没有区别,都不知道。
完了,我也大部分都不知道.有答案么?
本就是没有一个标准的问题
很受启发,像楼上有人说的,关键不是答案 而是从问题上想到了什么,向哪个方向思考问题了,呵呵 以后还得继续学习啊 感谢作者
这些问题是给大家用来引出话题的,来考察知识结构完整和思维方式差异的。其中很多内容是没有标准答案,而且即便有标准答案,但是也不是需要你提供一个标准答案,而是需要你能够发表出自己的见解。
同意! 更重要的是学会怎么提问,怎么思考和怎么解答.
要学多少东西才能达到这水平?
不学习就会被人家鄙视成狒狒
本采访是在伦敦举行的QCon2009上记录的,Ian Robinson和Jim Webber探讨了如何将Web作为整合平台以及REST在理论上和实践中的好处。
项目管理对于项目成败至关重要,但实践中每个项目都有自己的独特性,没有现成的解决方案可以套用。书中从应对实际风险的角度出发,讲述了从项目启动、项目规划到项目结束的整个管理流程,展示了作者的思考过程。本迷你书从原书中精选出5个章节。
在这个演讲中,Fred将会揭示敏捷的一些外在因素,并会重点关注敏捷获得成功的内在原因。从案例研究和真实的项目经验来看,Fred认为:工具、管理体系都不能让你变得敏捷。敏捷的成功,植根于士气高涨、充分授权的工作者身上,他们能够以不同以往的方式思考问题。
Eben Hewitt的新书《Java SOA Cookbook》从Java实现的角度讨论了面向服务架构。Eben在书中讨论了SOA基础、工具、最佳实践和SOA治理等主题。
Mark Richards的新书《Java消息服务》第二版覆盖了JMS的许多主题, 包括发布和订阅模式以及点对点模式,消息过滤和事务等。InfoQ与Mark谈论了跟他的新作。
35 条回复
关注此讨论 回复