Eureka的故事,专注能让你看到别人看不到的事情

有这么一句古老的箴言:

如果你手里有一把锤子,所有东西看上去都像钉子。

其实这句话已经是老调中的老调重弹了,我们程序员有很多锤子:OO、设计模式、语言(C, C++, Java, Python, Ruby, etc.)、各种各样的架构tricks&workarounds,以及一堆软件过程方法论(Agile, XP, Scrum, etc.)、等等。

几则故事:

1. 阿朱的(《走出软件作坊》):

我过去领导过架构组。架构组的人在2002年的时候,疯狂迷上了UML和设计模式,人手一本《COM本质论》和《设计模式》。我手下有一个新手,就处处是类,处处是抽象,处处是封装,处处是分离,尽量使代码高内聚低耦合。但是这样的的代码太麻烦,他花费了大量的时间,他看自己的代码赏心悦目,别人看他的代码云里雾里,不阅读懂《设计模式》就按照常规理解业务的思路去阅读他的代码根本阅读不懂,不知道他为什么这样写代码,怪异的很。本来,这位想达到可维护性,可阅读性,却真正的失去了可维护性、可阅读性。这和我前几天看我的朋友周爱民写的《大道至简》中写到:有人希望拿UML去统一用户和软件设计者。殊不知UML有多难理解,而UML设计者却认为UML可以描述一切。就这个道理,要理解你的代码还要去读懂《设计模式》,这要求太高了吧。

所幸这位新手自己都每次写的累,慢慢的也就懒了,觉得确实需要分离的时候就分离,觉得没什么必要的就懒得做了。用他自嘲的话说就是:被磨平了。其实,依我看,他现在这个代码状态才是刚刚好,即照顾了设计扩展,又照顾了实用。真正的纯OO,纯设计模式,可能只存在于教学和科学,而不在于我们的商业软件开发。我们作为商业开发,强调的是叫座的基础上叫好,所以折中方案是必须的,客户和我们自己两相宜就OK,是否符合正宗,就不在我们的商业开发管理范畴了。

这位新手还写了大量的注释。在每个源代码文件头都写上几月几号,XX创建的,这个原代码文件主要是干什么的,还画蛇添足的写上版权所有,公司名称。好像这个代码要开源,或者可能会被其他公司窃取了好表明公司版权。甚至每个函数都写了注释,每个参数是什么意思,每个参数可能出现的值代表什么意思,都写的一清二楚。久而久之,也懒的维护了。代码改动了,参数扩展了,参数状态值有了变化,注释说明却没有跟着改动,让后来看代码的人老误解,还不如不写这些注释。

我告诉他:做事不能走极端。要么全写注释,要么不写注释,都是不对的。我只在我认为要小心的地方,或者我自己都觉得很难理解懂的地方我才写注释。否则,我自己都可能会过段时间理解错了。如果某段代码我看看就能看懂,我就不写注释了。咱们做企业管理软件,深入技术又没有,只要代码能把复杂的业务处理描述的逻辑思路清晰就OK。虽然说理解能力不同,我能快速理解了的未必有新手能够理解,但是你看看我的代码你就明白了。(摘自 《走出软件作坊:代码那些事儿》)

再来一段:

有一部分所谓的架构师,技术超深厚,框架堪比Spring之类,但自己一个人闷头写框架不断优化,力竭使用最先进的技术思想,希望把最豪华的设计模式融进去,希望把OSGi融进去,希望把AOP融进去,全无视那些想利用框架减轻自己工作量提高自己工作效率的应用功能开发同事。这是在用公司工资玩技术呢,还是在满足个人技术幻想呢,还是在实验呢?到底在干吗?价值在哪里?

还有的人不会推广自己的框架。不善言辞,就幻想着技术总监能够通过行政命令让大家必须用框架,能不自己写代码就不自己写代码,能交给框架做的就交给框架做。但技术总监号召完了,大家仍然我行我素,各自开发为政,让框架开发者很孤单。

还有的人也不会推广自己的框架,沉迷在自己的理想世界。好不容易技术总监召集大家让大家来听听框架如何应用,但自说自话,满口自己最得意的词汇,听得业务功能开发人云山雾罩。大家问些问题,如这样的业务开发难题,框架怎么解决?于是,框架开发员就和业务开发员争论了起来。框架开发员觉得这根本就不能答应客户这种变态的需求,而业务开发员说这就是现状。框架开发员说你可以这样这样,业务开发员说这样太麻烦,框架开发员立刻还口这还麻烦?于是双方各执一词,框架也没推广成功。

我手底下有个框架开发员。他的技术渴望很强烈,为了技术难题攻克,可以不吃不睡。并且技术敏感度很强,学习也快。所以当时我感觉他是个程序员的料,就把他拉到我的手下。

但是有个问题,他写出的框架代码,在平时开发业务功能的时候挺麻烦。大家可能需要的是一把铁锹,但是他却给大家N根不同长度不同粗细不同材质的木棍,N个不同形状不同用途的铁锹头。大家会有N种组合。不仅导致他写代码老超任务期,而且也让使用人感觉没多大帮助。使用起来复杂,而且还得配置这个配置哪个,需要注意的地方太多。业务开发组的同事就不愿意用,还不如把代码自己直接写死了得了。超期还会影响业务功能开发组的使用。本来人家是为了想加快自己的工作效率。你答应好这个星期给业务开发组提供一个功能,但你没有拿出来。就耽误人家进度。你多次拿不出来,人家业务开发组还不如自己开发一个呢,求人不如求己。

我最后警告他:如果你认为自己技术够牛,那么你必须证明你能很快做出来。如果你认为自己技术够牛,最好能牛到,只提供一个函数就解决了他们的问题。别这个代理类,那个聚合类,这个唯一实例类。最好连参数也没有,大家调用一下写一句代码就OK。甚至你做的好,大家都不用调用你的代码,你可以包含在基础框架中,你自己去判断什么时候什么应用需要执行这个动作。如果你认为自己技术够牛,那么在业务功能需求发生变化的时候,你能够保证接口不变的情况下还能适合变化,这才你够牛。别让业务开发组的人跟着你也得改他们自己的代码,那样的设计就很烂了。

小伙听了我的话。进度保证,代码接口简洁。(摘自《走出软件作坊:走钢索的人》)

2. 坊间流传的大家耳熟能详的小故事:

话说联合利华新换了一批自动香皂包装机以后,经常出现香皂盒子是空的没有香皂的情况,而在装配线一头用人工检查因为效率问题不太可能而且不保险。这不,一个由自动化,机械,机电一体化等专业的博士组成的Solution队伍来解决这个问题,没多久他们在装配线的头上开发了全自动的X光透射检查线,透射检查所有的装配线尽头等待装箱的香皂盒,如果有空的就用机械臂取走。

不巧,中国一乡镇企业生产香皂也遇到类似问题,老板吩咐线上小工务必想出对策决之,小工拿了一个电风扇放在装配线的头上,对着最后的成品吹之,空盒子被吹走,问题解决之。(摘自 TopLanguage 上的讨论。)

因此,

  • 心中有锤,就容易为其奴役:在遇到问题的时候不是具体问题具体分析,而是屁股决定脑袋,不管三七二十一先上黄金大锤再说,而且往往还颇有成就感,却将自己真正原本要解决的问题抛在脑后了。始终莫要忘记提醒自己,“问题是什么?”
  • 但毫无疑问,没有锤子是万万不行的,没有谁会傻到徒手钉钉。重点是选择合适你的工具。这又要求在学习工具的时候始终别忘记它的适用范围。

正确的态度应该是:

手中有锤,心中无锤。

容我具体解释一下这句话:任何工具都有其适用范畴和前提。然而,我们在学习工具的时候由于投入很多的时间,往往在情绪上面对工具产生了太强的感情,我们既投入了时间,当然内心希望能够用上这些工具,所以就容易忘掉其适用前提,欣欣然地不管三七二十一就把黄金大锤亮出来,以显示自己的厉害。但如果我们换一个态度,仅仅将它看作我们工具箱中的又一件工具,就可以客观地评估它,视具体情况而使用了——始终别忘记自己要解决的问题是什么。Why 永远在 How 之前。

与上面对应的还有另一句话(实际上这是我杜撰的:D):

如果你想钉一个钉子,所有东西看上去都像是锤子。

用大白话来说就是:如果你心中专注于你想要解决的问题,那么你所看到的东西就会呈现出以往你没有看到的一面。

例子:

1. 阿基米德洗了一辈子的澡,然而,只有那一次,当他想要解决皇冠密度问题的时候,想到可以利用排水体积来测量不规则物体体积(Eureka是希腊文,意为:我找到了,我发现了)。

2. 如果你也喜欢看 《Monk》 ,就会体会到把问题装在心中,甚至把自己变成问题,问题即自己的作用——当 Monk 的潜意识里面始终在寻思 How, Why, Who did it 这几个问题时,周遭环境中的一切信息都会显出另一番面目,一个平常情况下根本不会注意到的细节也能成为破案的关键,看似不相干的信息也能带来出乎意料的启发。

3. BentObjects

如果你也像我一样,习惯于经常把疑问装在大脑中酝酿好几天,你肯定会有 eureka 的体验。

或者,如果你喜欢在一段时间之内关注某个主题,你在阅读书籍资料的时候就会带着问题的眼镜,看到平常看不到的东西,作出与平常不一样的思考。

把自己变成钉子,这就是 eureka 的奥秘。

时间: 2024-10-10 10:58:04

Eureka的故事,专注能让你看到别人看不到的事情的相关文章

打造百亿美元独角兽必须要做三件事

4 月 16 日消息,创新工场微信公众号上日前发布了一篇创新工场 CEO 李开复日前做了一场分享,讲述春节期间在美国硅谷的见闻. 李开复谈及谷歌.特斯拉.Airbnb 这些企业为何成功.李开复还给创业者建议,称打造百亿美元独角兽,必须要做三件事. 李开复分享的主要内容如下: 我们学到了什么? 在硅谷我们见了 Google 的资深副总裁 Jonathan Rosenberg,他做了一个非常有智慧的分享.在这个分享中我捕捉到几个片段,但其中我认为最重要的是:我们都知道怎样做独角兽,但怎样做一个百亿元

五项管理 (目标管理,行动管理,心态管理,时间管理,学习管理)小册子总结

一.目标管理 有目标者自有千计万计,无目标者只感千难万难 目标不明确,努力再多也是劳而无功 方向不对,努力白费 做对的事情,比把事情做对还重要 人之所以伟大,是因为目标而伟大 世界上没有懒惰的人,只有没有目标的人,没有目标就没有动力 没有目标的航船,所有的风就是逆风 完成你该做的事情,才能做你想做的事情 利润是检验企业成功的唯一标准 有5%的目标,有要付出100%的努力 猎人眼里应该只有奔跑的兔子,而不是其他的什么东西 目标聚集原则,目标要单一,专注 万人操弓,只射一招,招无不中.——吕氏春秋

几个关于学习的故事,想学习的来看看

1.凿壁偷光 原文:匡衡勤学而无烛,邻舍有烛而不逮,衡乃穿壁引其光,以书映光而读之. 邑人大姓文不识,家富多书,衡乃与其佣作而不求偿. 主人怪,问衡,衡曰:"愿得主人书遍读之."主人感叹,资给以书,遂成大学.    --出自<西京杂记>卷二 故事: 西汉时候,有个农民的孩子,叫匡衡.他小时候很想读书,可是因为家里穷,没钱上学.后来,他跟一个亲戚学认字,才有了看书的能力. 匡衡买不起书,只好借书来读.那个时候,书是非常贵重的,有书的人不肯轻易借给别人.匡衡就在农忙的时节,给有

《用户故事与敏捷方法》阅读笔记05

第13章 用户故事的优势 从上一章我们得知,处理需求的方法多种多样,但是我们为什么要选择用户故事?因为它会带来多种好处: ①用户故事强调口头沟通:自古以来,口头表达是十分重要的.而且相比于书面书写的易产生歧义,口头表述更见简单明了,需求文档也是如此. ②人人都可以理解用户故事:相比于一些墨守成规的软件需求里的技术术语,用户故事使用的语言更容易使用户理解,简洁明了,同时更能增强用户对故事的记忆. ③用户故事的大小适合做计划:其他类型的需求分析关联性太强,并且还比较笼统,大小不能称得上是易实现的适合

【阅读】执行中的专注

[抄的]个人批注: 时间管理的最终目的是高效的把事情做成并且要做好.有目标,有计划,按照计划去执行.执行的过程就会遇到拖延,我们就需要在执行过程中专注,只要专注后执行力和效率才能提高. 对于个人管理而言: 1.要有阶段型目标,并且要制定一个执行计划 2.幼稚型计划只后,就开始强迫自己按计划执行 3.在执行的过程中,可以利用番茄实践工作法,一段时间内专注于一件事情上 4.通过一段时间的训练就会让自己养成良好的习惯,变成自己的独门功夫 [好吧,我也写几句] 一开始我本来只想抄录原文的,但是看完之后,

给设计师的品牌故事设计指南

想想那些你一如既往乐于为之付费的产品.它允诺了你什么?关于这件产品,有什么让你感到自己在某方面变得更擅长?它是不是感觉像你内心渴望的一种写照? 在每个成功的用户体验的核心,都藏着一则创造品牌价值故事.顾客使用我们的产品,因为它们为顾客潜意识中的渴望提供了解答.想想你在使用的产品,它如何满足了下面的某种渴望,甚至更多: 变得独立,并且使别人也这么看你生活少一些压力,放轻松表达自己,展示自己的独特之处在生活中开启新角色或位置改善你与他人的人际关系寻求安全与稳定优化你对时间与资源的使用出名作为一名人类

讲述测试自己的故事

发现一本很有意思的书,叫做<互联网产品测试故事汇>,看了下原来是Monkey在荔枝上开了个频道讲测试人员的故事.在研发领域有各种内容的书,有各种讲编程语言的书,讲编程大牛故事的书,有讲软件工程的书,但是很少有讲测试方面的书,其中讲的好的又与时俱进的那又是少之又少.这是我看到第二本讲测试人员故事的书(之前入行前看过赢在测试系列). 因为是讲测试人员的生活,很多话题是能够产生共鸣的. 测试到底应不应该是万金油 当作为初级测试人员时,做事还是很focus的,就像之前一篇讲腾讯职级的公众号文章说的,这

做品牌要站对位置、讲好故事

我们一直说:消费者才是我们学习的对象和崇拜的偶像,离消费者越近的经理人越优秀,离市场越近的企业越杰出.但在现实的中小企业一直对品牌的理解有误区和偏差,不明白企业的产品到底满足消费者哪种价值需求,是产品价值还是形象价值,直接表现就是一切像贵看齐,最贵的牛肉干.最贵的烧麦.最贵的有机羊肉.最贵的杂粮,一时间"贵"好像成了成就品牌快速发展的通天大道,且不知价值不同路不同,一切还是要从消费者理解和认识出发,品牌打造首先要站对位置洞察消费者价值需求,其次要讲好故事做好持续性的传播. 什么是产品价

雷军成功七字诀:专注 极致 口碑 快

导语:雷军总结了互联网成功的七字决,即“专注.极致.口碑.快”,雷军坚信只要按照这个方法去做就会战无不胜,攻无不克.自己也在用这套方法创办了小米,也帮朋友创办了20多家公司. [创业邦讯]2012年第七届互联网站长年会在国家会议中心举行,小米公司董事长雷军发表了“人生就是要折腾,解密小米手机的成功之路”的主题演讲. 雷军表示,这是他第一次参加站长大会,这其中的原因很简单,是因为自己对“站长”这两个字心存崇敬之情. 虽然在互联网行业摸爬滚打了这么多年,但是对于“互联网”这三个字的的最深刻的思考是在