BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

采访Sandi Metz:谈Practical Object-Oriented Design in Ruby一书

| 作者 Manuel Pais 关注 9 他的粉丝 ,译者 臧秀涛 关注 2 他的粉丝 发布于 2013年8月28日. 估计阅读时间: 8 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

InfoQ就Practical Object-Oriented Design in Ruby: An Agile Primer一书采访了其作者Sandi Metz。

这本书于去年出版。就设计实践而言,如果没有清晰的上下文和设计动机,看上去会非常复杂,而本书采用的是注重实效的方法,因此受到了Ruby社区的热烈欢迎,很多非Ruby爱好者也非常喜欢。

尽管书中的示例是以Ruby实现的,但是这本书可以看做通用的软件设计书籍,因为作者对动态语言与静态语言之争并无偏向。

老道的开发者会在书中发现他们曾经遭遇过的痛点。而新手则会发现相关设计实践的清晰解释和示例,进而更清楚地理解在特定上下文中采用特定实践的优缺点。

尤其重要的是,这本书强调设计是否足够好——即既能满足当前对应用(需求)的认知,又能将未来修改的代价降到最低——需要连续不断地评估。用Sandi的话说:

“易懂、合理、可用且堪称典范的代码不仅可以满足今日之需求,加以修改,还可以满足未来之需求。”

InfoQ采访了Sandi,谈到了她的新书是如何得到大家认可的,如何从开源代码中学到东西,如何合理使用代码分析工具及其他主题。

InfoQ:本书的目标读者是哪些人?你认为专家级开发者和新手是不是都能从本书获益?

Sandi本书最初其实是为年轻、没多少经验的自己编写的,那时我已经写过几年的面向对象代码。或许可以称本书所面向的读者为“中级人员”。在写作时,我认为经验较少的读者还不能领会本书,而经验丰富的读者可能又不感兴趣。

然而,本书出版之后,看了读者的选择,很明显我想错了。很多绝对的新手告诉我,他们认为本书非常有用,而不少有经验的程序员也说他们很是喜欢。读者的范围比我预想的要广得多。

还有一点我也颇感吃惊,很多非Ruby爱好者也在读这本书。这本书是关于面向对象设计的,特定于Ruby的内容非常少,因此有其他读者喜欢或许不算意外。但是我并没有考虑到这类读者,他们认为书有用,我非常高兴。

InfoQ:你的书中谈到了很多堪称典范的代码,也传达出这样一种理念,即近朱者赤,近墨者黑,好的代码和坏的代码都会影响周围代码。在行业招聘中,看上去大家在都在关注一个开发者有多么好,但公司内烂代码对个体能力的不良影响有多大呢?

Sandi根据我的经验,在实际业务中,真正的应用程序中也包含大量不完美的代码,现实世界就是如此。很明显,新手没有足够的经验,对于不好的例子,他们并不知道如何修改,甚至无从判断其优劣,所以不可避免地需要有经验的程序员予以指导。

有经验的程序员也是在工作之中历练出来的,实践出真知。我们既要依赖同事的指导,也要亲手实践以改进自我。老手有责任教导新手。

幸运的是有了开源世界,每个程序员都可以接触到比其公司内多得多的代码,也可以接触到比其公司所雇佣的少数员工多得多的“老手”。新手不必为不知道如何编写(甚至识别)堪称典范的代码而苦恼,但是走出去、接受方方面面的影响也是他们必须承担的责任。

InfoQ:新手如何才能做到既不破坏现有代码,又能在实践中学习设计呢?书中你提到,如果坚持使用某种模式,却对决策所伴随的折中方案没有清晰的认识,这很危险。想要掌握面向对象设计的新手是不是还有其他需要避开的障碍?

Sandi新手应该大量编写代码,并将这些代码展示给有兴趣的人看看,再就是看看别人写的代码。Github是大家的朋友,什么都替代不了自己投入时间练习。

InfoQ:代码分析工具是天堂还是地狱?

Sandi对判断力不错的人而言是天堂,对其他人而言则是地狱。对于走查代码和对某些东西进行计数这样不需要动脑子的工作,代码分析工具非常不错。但是结果如何处理还得人来决定。

有的代码分析工具,比如有些东西本来是应该避免的,但是我们还给出了技术上“还不错”的设计,工具会给出不错的分数;而对于重要的事务,“不好”的设计也永远不会把分数搞得很差。如果代码分析工具支持前者而反对后者,这种情况下听取工具的建议就是浪费金钱。

有力量抵制编写过度考虑未来的代码,有勇气留下有味道但永远不会改变的代码,这是人区别于工具的品质。

InfoQ:在定义依赖规则和违反规则的情况时,你是如何看待这类工具的作用的?它们是否有助于产生更好的设计?还是说好的设计实践对上下文太过依赖,以至于无法从这样的硬性规则中获益?

Sandi我喜欢分析工具,也喜欢这些工具提供的数据。它们能让我的设计切实可靠,能指出我忽视的问题和所犯的错误。我认为谦逊的程序员都应该利用这些信息,不过对结果应该持保留态度。

InfoQ:根据你的经验,在遗留应用中,有哪些最常见的设计味道?关于如何修复有问题的代码,你是否有什么建议,我们应该从哪里开始呢?

Sandi个人认为,对象和方法包含了太多责任,这是最大的问题。这种问题非常普遍,所以我的第一个建议是“让事务更小巧”。

InfoQ:对于对实际的面向对象设计有兴趣的读者,你有其他的推荐读物吗?

Sandi可以阅读Growing Object-Oriented Software Guided by Tests

InfoQ:你的书是如何被Ruby社区接受的?你是不是感觉面向动态语言——特别是Ruby——的软件设计著作存在空白?

SandiRuby社区的积极响应让我非常吃惊。尽管受过理论训练的Ruby爱好者看上去的确非常喜欢,但是最热情的回应却是来自自学的Ruby程序员。我每天都能听到有些人说,他们非常渴求这些信息。我得谦虚点,别老重复太多赞美之词了,但是我们还是可以看个例子,一位高兴的读者在Twitter上对我说,他有醍醐灌顶的感觉。

其实这本书包含的新东西很少。事实上,我原来还以为有些想法是我的首创,但是后来发现,可能最好还是说我“重新发现”了这些想法。

因为现有著作我不可能都读过,所以不知道这些想法已经存在。因此,这类著作的空白并不在内容上,而在可读性上。大家热情的响应说明,普通程序员群体还是非常希望这一空白被填补起来的。

InfoQ:你能否与InfoQ分享一下你的下一个项目,比如是写书、开源项目还是有其他打算?

Sandi我为这本书制作了一系列视频,而且探索了一些教学的可能性。我很享受编写这本书给我带来的机遇,唯一的缺点是我不得不专门安排时间编写代码。

关于受访人

Sandi Metz有30年的项目经验,她负责的都是好不容易存活下来并得以发展和改变的项目。作为杜克大学的软件架构师,她每天都要编写代码,她的团队负责为客户解决大规模面向对象应用中的实际问题,而这些项目都是演化发展了15年以上的。她致力于以切实可行的方式将软件开发出来。Practical Object Oriented Design in Ruby一书是她多年以来白板画图的精华,也是她关于面向对象设计诸多讲话的必然结果。Sandy曾在Gotham Ruby Conference上做过多次演讲,她生活在北卡罗来纳州的都兰姆。

 

查看英文原文:Interview with Sandi Metz on Practical Object-Oriented Design in Ruby

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

书写的很好 by lise lie

有的代码分析工具,比如有些东西本来是应该避免的,但是我们还给出了技术上“还不错”的设计,工具会给出不错的分数;而对于重要的事务,“不好”的设计也永远不会把分数搞得很差。如果代码分析工具支持前者而反对后者,这种情况下听取工具的建议就是浪费金钱

www.east-tools.com

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT