重构之十六字心法

这篇文章是我写过的所有文章里最难产的一篇,前前后后斟酌酝酿了好几个月。因为重构对于我来讲真的太重要也太深刻了,包含的内容和想说的也太多了。如果说这几年自己觉得在哪些方面的收获最大的话,非重构莫属了。

重构的威力

软件开发的难点在于不确定性,前几天邱大师刚写了一篇《软件开发为什么很难》就提到

软件的复杂性来自于大量的不确定性,而这个不确定事实上是无法避免的。

需求在变,语言在变,框架在变,工具在变,架构在变,趋势在变,甚至连组织结构都在不断的变化。

随着变化的不断产生,软件变得越来越复杂。就像《架构腐化之谜》中提到的一样,我们的软件也会像一个生命体,经历从新生到衰老腐化的过程。而重构就像是一次手术,通过优化内部结构,减慢腐化衰老,让软件“青春永驻”,可见重构的威力。

重构教会了我如何通过高效安全地改善内部设计以使之适应外部的不确定性和频繁变化。

重构威力无边,就像是武侠小说中的一件插在石头上的上古神器,但同样也不是一般人可以轻松驾驭的。如果运用不当,造成的损害也会同样巨大。

如何将重构这件神器运用自如,发挥其最大的威力,也是我一直在探寻的,即重构的手法和心法。

合格的重构

在谈手法和心法之前,可能很多人会有疑惑,觉得重构并不像你说的那么难啊,我们每天都在做,就是改改代码改改设计,哪有你说的那么邪乎。那我就先来讲讲我认为怎么样才算是一次合格的重构。

对于什么是重构,《重构》书中已经有明确的定义,分名词和动词两种形式。

重构(名词):对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本。
重构(动词):使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构。

就像“看板”不是“我们看到的那个白板”一样,“重构”也不是“重新修改代码”那么简单。

我就看到过太多打着重构的幌子,把系统改的面目全非,最后出了问题直接甩锅到重构身上的场景了。那怎样才算是一次合格的重构呢?我觉得至少需要做到以下几点:

  • 消除味道:一个重构应该是从识别一个坏味道(Bad Smell)开始,以消除一个坏味道结束,任何不以消除坏味道为目标的重构都是耍流氓。
  • 始终工作:即重构定义中的“在不改变软件可观察行为的前提下”,说白了就是重构过程不能破坏甚至改变软件外在功能。
  • 持续集成:不需要为重构单建分支,重构过程可以做到Feature开发在同一分支上持续集成持续交付。
  • 随时中止:例如一个方法重命名,需要修改100个调用点,当改到50个的时候有个紧急的Feature,我可以随时暂停重构,立即切换到Feature开发上,且不需要回滚已做的重构。
  • 断点续传:还是上边的例子,假如我已经完成了紧急Feature的开发,可以随时继续之前的重构,完成剩下50个调用点的重命名。
  • 过程可逆:对于重构,经常有人会问:你怎么保证重构就会更好而不是更坏呢?重构的伟大就在于他跳出了对错之争,将关注点放到如何快速平滑安全的变化上,当然也包括反向重构。所以我的回答是:无法保证,但是我可以一分钟就重构回来。如果仔细看,《重构》书里的所有重构手法都是双向的,比如“Extract Method”和“Inline Method”。

可以反思一下,我们平时自认为的那些重构,是否都符合了以上的这些要求?

  • 多少次我们打着重构的旗号,七零八碎,无法复原。
  • 多少次我们打着重构的旗号,分支开发,集成困难。
  • 多少次我们打着重构的旗号,半途而废,迷途难返
  • 多少次我们打着重构的旗号,孤注一掷,进退两难。

在我的眼里,这些都不是合格的重构,甚至都不能称之为重构,好的重构应该像一边开车一边换轮胎一样,保证系统随时可工作的前提下,还可以对其结构做出安全高效的调整。

可见重构并不简单,那要怎样才能达到上述的那些要求呢?

重构的心法

在过去的几年,我一直在学习和思考重构的各种手法。从刚开始的乱改一气,到学习基于IDE和插件的各种快捷键流的重构手法,以及研究如何通过组合各种基础重构手法形成“连招”,从而快速实现更复杂的重构过程。

随着对于基于IDE的快捷键重构手法越来越娴熟,在IDE和插件的帮助下,我的重构手法越来越华丽而迅捷,在沾沾自喜的同时心里也慢慢萌生了一些质疑:难道这就是重构么?如果没有IDE没有了插件,我还会做重构么?如何用编辑器(Vim,Emacs)做重构?重构只是代码级别的么?数据库如何重构呢?系统架构如何重构呢?工具框架如何重构呢?微服务架构下的服务重构呢?公司组织重构呢?

这种感觉就像是武侠小说中的某个柔弱书生,无意中掉到了一个悬崖下,找到了一本武林秘籍,照着上边的招式练了练就自以为已绝学在身,结果出去虽然能招架一时,但禁不住更大的挑战。被打的体无完肤后,重新掏出那本秘籍,收起浮躁,怀着诚敬之心努力去参悟那些招式背后更深的哲理,也就是所谓的心法。此时对于我来说,而那本武林秘籍就叫做《重构》

在带着这些疑问重读《重构》的过程中,我欣喜地发现书中那些细致入微但看似笨拙拖沓的重构手法(例如Rename,使用现代IDE一个快捷键就可以搞定,但是老马用了很多步骤才完成),其实都蕴含着重构最重要最基本的原则和思路,只要按着这些原则去做,无论什么层次的重构:代码重构、架构重构、服务重构甚至是组织重构,都可以做到上面提到的一个合格重构的基本要求,即平滑安全可停可续。

把其中的原则思路抽取出十六个字,即所谓的:重构十六字心法

解释起来也很简单,往往我们做”重构“的时候就是在旧的结构(这里的结构可以是一个方法、一个对象、一个服务、一个数据库、一个服务甚至是一个组织结构)上直接修改,导致系统长时间处于一个中间不可用状态,这个状态持续的时间越长,”重构“失败的可能性和负面影响就会越大。

而《重构》告诉我们,做内部结构调整时,先不要直接修改旧的结构,保持旧的结构不变,先按照新的设计思路创建一个新的结构,因为这个过程中对于旧的内部结构没有任何影响,所以是安全的,可持续集成的。当新的结构构件完成时,我们再把对于旧结构的依赖一个个的切换到新的结构上,即所谓的”一步切换“。最后当确认所有对于旧的结构都切换到新的结构上,而且没有问题后,再将已经没有任何引用的旧结构删除掉,完成整个重构过程。

这里的“一步切换”并不是说整个重构的切换过程必须是一步完成的,例如前面重命名的例子,100个调用点的切换可能是分多次完成的,在这个例子里一步切换指的是每一个调用点的切换过程。这个切换过程是最容易暴露出问题的,所以越简单越快速越好,一旦出现了问题,就快速的切换回旧的结构后再慢慢排查问题,从而实时保证系统的可用性。

大道至简,一旦领悟并掌握了这个心法,就发现自己一下从之前狭义的代码重构中跳脱出来,任何广义上的重构都立刻变得有章可循。

在架构重构中常用的抽象分支(BranchByAbstraction),以及在微服务架构下服务重构常用到的绞杀者模式,其实都是这种原则的一种体现。

总结

重构可以使软件更容易地被修改和被理解。通过不断地改进软件设计以达到简单设计的目标,减少由于设计与业务的不匹配带来的架构与设计腐化。

掌握了重构的手法和心法,会让重构变得更加简单安全高效可控,从而真正的发挥出其巨大的威力,让我们的软件永葆青春。


更多精彩洞见,请关注微信公众号:思特沃克

Share

为什么QA不喜欢重构?

经常听到开发人员抱怨 ,“这么烂的代码,我来重构一下!”,“这代码怎么能这么写呢?谁来重构一下?”,“这儿有个坏味道,重构吧!”

作为一名QA,每次听到“重构”两个字,既想给追求卓越代码的开发人员点个赞,同时又会感觉非常紧张,为什么又要重构?马上就要上线了,怎么还要改?是不是应该阻止开发人员做重构?

重构几乎是开发人员最喜欢的一项实践了,可QA们却充满了顾虑,那么为什么QA不喜欢重构呢?

老功能被破坏

不止一次遇到这样的场景,某一天一个老功能突然被破坏了,QA们感到奇怪,产品这块儿的功能已经很稳定了,也没有在这部分开发什么新功能,为什么突然出问题了呢?

追查下去发现是近期做了重构。再追问下去,对于老代码,已经几乎看不懂老的测试了,可是开发人员看到代码的坏味道就想重构,于是功能破坏了。

在快速迭代的开发模式下,QA们主要关注用户故事的生命周期,重点测试新的特性功能,所以对于老功能回归测试的投入是非常有限的,如果开发人员突然对老功能进行了重构又没有告知团队,这样的问题很可能就会进入生产环境,这样是非常有风险的。即便很多开发人员重构老功能时会告知QA,以提前发现和修复导致的问题,但无疑会大大增加QA做回归测试的负担。

新功能推迟/重复测试

按照用户故事的开发流程,开发人员完成功能后,多方角色会首先在开发人员的机器上进行用户故事的快速验收以及探索性测试,然后开发人员会提交代码,由QA拿到包之后部署到测试环境进行测试。

但有的时候QA在开发机器上快速验收之后,开发人员又进行重构,曾经经历过“故事验收的时候功能都是正常的,拿到包部署之后好多功能不工作了”的事情,跟开发人员确认,又是重构导致的。

有时候开发人员会在用户故事验收之后告知QA还会继续重构,QA可以等到重构完成后再拿新的版本做测试,这样就会导致用户故事的测试时间推迟。或者开发人员会先重构再做验收,而这样又会导致QA在开发机器上进行重复的验收测试。

无计划不可见

开发人员的重构时机对我们来说是无规律的。有的时候一边开发用户故事一边重构,有的时候会在故事完成后、QA在开发机器上验证结束后才做重构,有的是代码评审后大家指出问题后做重构,有的甚至得等到项目组来了有经验的开发人员才开始重构。对QA来说,重构的时机是无计划的。

另外重构也是不可见的。我们总谈可视化,日常的开发工作由用户故事和缺陷来可视化,而重构经常是幕后进行的,不被跟踪、不被记录、不可见,有经验的开发人员会在进行“大”的重构之前口头告知团队,如果没有告知,就在不知不觉中发生了,只有功能被破坏了才能意识到。

总结

以上列出了QA不喜欢重构的三个理由,归根结底其实都是重构不当导致的。代码重构(Code refactoring)指对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。而不当的重构往往只关注了前半部分却忽略了对输出结果的影响。

个人认为,如果能够注意以下几个方面,也许可以很大程度减少QA对重构的顾虑:

  • 充足的自动化测试是保障输出结果的一个有效途径。不管对于历史代码还是新代码,进行重构的前提应该是确保这部分功能已经被足够的自动化测试覆盖,有的开发人员认为这是一个不可行的建议,因为“充足”对于每个人每个角色的标准可能是不一样的,QA也许永远都不会觉得测试足够,但是其实可以借助测试覆盖率等度量工具,甚至直接针对功能特性由QA来定义需要哪些自动化测试,在补齐这些自动化测试的基础上再做重构。
  • 对于新功能的重构,应该融入到正常开发过程中,在故事验收之前已经完成相应的重构,因为自动化测试不是万能的,也不可能达到100%的覆盖率,所以还是需要QA验证的。这么做就意味着客户要为我们的重构买单,所以作为软件领域专家的我们,如何让业务领域专家的客户理解重构的价值,这就变的至关重要了。
  • 小步前进,尽量避免或者减少大的重构,这样可以减少突然增多的回归测试工作量,也会减少功能被破坏的风险。如果发生了大的重构,反思一下是哪里出了问题?是我们积攒了太多的技术债?还是业务领域模型发生了大的改变?然后采取措施避免类似的事情再度发生。
  • 对于一些核心功能或者组件,进行重构之前尽早告知团队QA,如果能够给QA讲解一下重构的目的以及本次重构可能会影响到的业务区域会对QA有很大的帮助。这样做一方面可以让QA把重心放在最容易受到影响的功能上加强回归测试,另一方面也能帮助QA更合理地安排测试计划。
  • 尽量避免在产品上线前进行重构,不仅可以减轻QA回归测试的负担,也会降低功能破坏后来不及修复的风险。

重构的目标是为了改善代码质量,长远来看应该是可以减少软件缺陷的,从这个角度来说QA和开发人员的目标是一致的,我们相信,如果重构恰当,必定对项目是有利无害的。

Share

重构的七宗罪

重构经过了十几年的发展和应用,可以说它是极限编程中程序员最爱的实践之一了,纷纷争相在项目里应用。重构工作坊、Codekata重构练习等各种提升能力的方式也屡见不鲜,帮助程序员们去追求优秀的代码和设计。然这仍然摆脱不了人们对它的各种抱怨:“搞什么,又重构”,“重构出defect来了”,“项目紧,最近不要再重构了”,“重构到什么时候停呀”。小菜也这样被项目中的人抱怨着,觉得很委屈,找到了大牛小明。

小菜:有一大段代码不合我意,写的很烂。我就想最近刚好新学了点技巧,看了下模式,赶紧大干一场。没想到做着做着组里都反对。
小明:那你有什么目标?重构想达到什么效果?
小菜:目标?啥意思?
小明:我们做事情得有目标,重构任务也是一样的。
小菜:我不太清楚,我就是想把这段代码改了,我删了好多代码,测试好多都红了。项目好像下周发布,项目经理小东也问我什么时候完工;测试小花还说我前两天做的功能有问题,问我是不是又重构了;
小明:你呀,今天来对了。这两天我也在琢磨这个戏,重构七宗罪,正好给你来讲一下。

1.不懂重构,为了重构而重构

“没有目标而生活,恰如没有罗盘而航行。”

做事情得有一个目标,拿出租车举例:“师傅,我要去机场”。出租车师傅很清楚我们的目的地。然如果我们说,“师傅,我就是来坐车的,你随便开吧”,就是再有经验的司机也没办法把你送到终点。重构也是一样,它需要能够解决一定的问题,要有一个目标的引领,否则黑咕隆咚做了半天也不知道自己做了啥,最后不得不全部回滚,白费工夫。

那么重构是什么,它解决什么问题呢?

所谓重构是对软件内部代码及其结构的调整,期望改善代码质量,促使程序设计架构更趋合理。说白了,重构解决的就是代码和代码结构的问题,它开始自坏味道,其目标就是要消除坏味道,消除那些“不合我意”的因素,让代码的意图更清晰。

Martin在《重构》一书中提到了22个常见的代码坏味道,都可以作为我们重构的目标,来指引我们的重构。如:

  • 消除同一类两个方法之间的重复代码
  • 消除某一类中的长方法
  • 重命名
  • 删除A类中的死代码
  • 简化复杂的条件语句

同时,重构的范围也应是那段坏味道的代码,在重构过程中对其,也仅对其进行修改。

小菜:我明白了。这一段代码其实我就是想先去除重复问题的,结果改着改着就改到别的地方了。

2.不知道什么时候完工

经理,我先改上50块钱的,你看行不行?

重构是整理代码保持轻装前行的重要手段,然而我们也需要能够明确知道重构要做什么,最终的产出如何验证。总不能对项目经理说,我先改上50块钱的?

上文提到了消除复杂条件语句是这次重构的目标,那么简化22行-32行复杂的条件语句就是一个更具体的重构目标。有了这样一个具体清晰的目标,“重构什么时候停”也就是一个很容易回答的问题了,不用担心项目经理天天问你啥时候完工了。

02

重构其实不仅有代码级别的重构,还包括模块级别的重构、架构级别的重构。不同级别的复杂度不同,消除的坏味道不同,需要的时间也不同。一般来讲代码级别的重构可以在小时和天以内,架构级别需要的时间会更长一些,比如几周或几月或几年。

3.没有方法,暴力重构

“非常的建设需要非常的破坏。”

很多人都认同这一观点。但对遗留的应用软件、构筑过半的项目却容不得推倒重来。以我观察,在开始重构时仅凭自己对代码的理解就进行剪切、复制、删除、添加等大刀阔斧修改的人不在少数,尤其还没有完全掌握重构手法的新人们。结果当然错误百出,导致测试“奖赏”一片红。修复这些错误代码少则几个小时,多则几天,这不是重构,这是重写。

小菜:那怎么破呢?

无他,苦练而已。
重构是一种经千锤百炼形成的有条不紊的程序整理方法。在《重构》一书中Martin明确提出了68个代码级别的重构手法,这些手法都是等价的。在重构的过程中即使错了也没关系,都可以安全回退,重新开始。其中比较常用的手法就是桥接,如当我们要删除一个方法的时候,会新添加一个方法,然后将它的引用逐一的迁移过去,直到旧方法成为孤岛,就可以将它删除了。它能保证重构前与重构后的程序代码功能完全一致,从而实现安全重构。

所以小菜啊,这是20个招式,回去加紧练习啊;三月后再来见我。

03

小菜:是不是就像拳击比赛,不能空有一身蛮力,也得有技巧。
小明:孺子可教也。

4.没有策略,追求完美主义

重构过程中,经常出现为了消除一个坏味道,改了A类的方法,又改了B类的变量,不得不改了C类;最后发现这三者之间还有依赖,导致进行不下去了,波及面越来越广,时间越来越长,项目经理在催,最后不得不放弃所有的代码。

老子说:“治大国,如烹小鲜。”

调整一个正在运行中的系统也如治国,不要期望一次性调整到漂亮的代码或架构,而是要遵循“小步前进”的方法。从问题着手,每次重构一小步。针对一个问题有目的修改,修改完后测试,测试通过后提交代码,再进入下一轮重构。如果在改动过程中发现了其他需要修改的地方,不要顺便重构,你可以把它记下来,作为下一轮重构的内容。

这种做法在代码和模块层面都是相对比较容易实践,而针对架构层次的调整就相对比较复杂。这也是很多架构师需要去思考的问题,如何渐进式重构。不搞一下子半年一年的重构,而是以周以月为单位,快速的迭代,能够很快的验证结果获得收益。

5.不知道结果对不对

对于简单的代码级别重构如果做得好是可以不用验证结果的,然对于模块级别或架构级别的重构,是需要的。在我遇到的多次重构架构失败的例子中,很多是因为越做越发现很难验证结果的正确性,越做越不知道改的对不对,最后发现很难回答老板和客户的问题不得不失败。

这个时候一个可以衡量重构的指标就体现它的价值:能时刻检验我们的成果,确认我们的重构还在解决当初的问题。目前常见的量化指标有如下四类,可供参考。

  • 数量:代码的行数
  • 质量:代码复杂度、重复读、缩进等级、架构依赖复杂度等
  • 时间:花费的天数
  • 成本:投资回报率

同时也可以借助于Sonar、Structure101这样的一些成熟工具度量和管理这些结果。

04

6.只谈招式,不谈心法

《重构》是Martin和Kent对他们多年以来整理代码的实践的总结,然这背后体现的是他们对软件技术的深层次思考和经验。很多新人执着于学习重构手法而疏于学习背后的心法,有些可惜。

Robert C Martin的《代码整洁之道》和《敏捷软件开发:原则、模式与实践》、《设计模式》、Eric的《领域驱动设计:软件核心复杂性应对之道》、《架构之美》等都是帮助大家修炼心法的不错选择,他们可以让你更深层的了解代码,更高层面看待系统,锻炼你的嗅觉,提升你的代码能力。

7.不了解上下文,不与团队沟通

我们不得不承认对代码的重构是有风险的,尤其是模块或架构级别。这段代码的业务是什么,为什么当时这么设计,测试覆盖率是多少,如果这样改会不会影响到其他模块?对其他角色有什么影响?这些问题都要逐一回答。在风险相对较大的改动更要如此,需要和团队成员,各个角色,包括项目经理和客户进行沟通,谈论这次重构的好处和风险,获得足够的评估,从而能够做出合适的重构决策,将风险降到最低。

今天就聊这些吧。不过小菜啊,你不要担心,重构和做其他事情一样,要有目标有方法有策略有结果。我们在进行的时候需要以终为始,不忘本心。最重要的是要提升技术能力,学习安全重构手法,小步前进,渐进式的重构,不断验证重构的收益,才能迎接一个一个的重构任务,真正的成为清理代码的高手。

加油吧,我看好你哦。

Share

重构是每个程序员的洗髓经

相传达摩祖师面壁九年,功成坐化,少林僧众于其面壁之处获铁函一只,内有两部不世绝学:《易筋经》和《洗髓经》,易筋功法强筋健骨,洗髓心法采纳调息,故少林冠绝武林,为江湖称颂

自软件江湖降世,功法、心法及门派层出不穷,各大公司年年招兵买马,意在争夺江湖头把交椅。然每每武林大会之季,仍有不少公司感慨人马多而不强,鱼龙混杂,江湖地位力有未逮。原因何在?究其根本乃是软件江湖快速膨胀,功法(编程语言,设计模式等)之类见效快,故而为世人推崇,而内功心法(思想,方法,习惯)非一年之功乃是经年累月之效因而鲜有问津。更有不少江湖骗子伪装得道大师,随意杜撰心法,更是造成不少初涉软件开发之人,走火入魔,饮恨江湖,从而导致世人对内功心法更加敬而远之。

世间繁杂在一定程度上掩盖了武林至尊绝学《洗髓经》的光彩,口口相传更是加深其神秘感,但这都改变不了其真正价值–洗髓是脱胎换骨,由内而外地强化自身功力,更是打通任督二脉,实现向真正的高手大师过渡。

软件开发也有一部内功绝学–《重构》,它来自一位长相酷似达摩祖师的软件大师,Martin Fowler,关于这位大师的传奇经历此处不表,本文所要说的是他创立的软件开发内功心法–重构。

正如前文所说软件开发的内功心法其实讲的是软件开发者使用的方法,习惯和思想,与武功中的内功一样,长期的修炼能够让修炼者参悟到软件开发的不同境界。说到这里,有人会说真有这么神奇吗?回答是肯定,因为这样的修炼改变的是开发者的习惯,包括思考的习惯、设计的习惯和开发的习惯。这正是江湖流传的不二箴言:习惯决定成败。

重构改变了开发者的什么习惯?首先来看下重构是什么,重构是指不改变软件功能的前提下,通过代码调整来改善代码质量,提高代码的可维护性,使代码的架构更加趋于合理。一言以概之–改代码,有人会提出疑问,改代码我们也会啊,这有什么习惯可以改变的,重构并不是改一次代码,而是在开发的过程中频繁地进行代码调整,只要在开发中发现可以重构的点,就可以记录下来,然后进行重构,不只对现在正在开发,也可以是对之前完成的代码,这不是件容易的事,需要付出恒心和毅力。

可能有人担心重构会破坏代码原先的功能,OK,那就引入TDD和版本控制,TDD保证重构不破坏原有功能,而版本控制则保证出现了破坏原有功能的错误后能迅速回到原先正确的状态。

重构+TDD+版本控制,开发者一下就拥有了三件法宝来改善代码质量。恭喜你,你现在变成XP(极限编程)了,你的开发习惯一下就从瀑布迁移到了敏捷上,再加上经年累月的磨砺,OK,你自然而然地成了高质量代码的贡献者,是不是想想有点小激动呢?

内功心法大多分为若干层次,重构也是一样,分为几重境界。第一层是通达,即阅读性重构,如同打通全身经脉,消除代码中词不达意,表意不明,做到“信、达、雅”;第二层是凝炼,即结构性重构,如同气沉丹田,消弥杂念,剔除代码中的重复,提取职责单一的功能块,实现代码重用和逻辑清晰;第三层是突破,即设计性重构,如同打通任督二脉,重铸体内气血循环,在这一层次,经过前面的两层修炼,代码结构趋于合理,逻辑趋于清晰,此时可以考虑引入模式,完成质的跨越。

完成三重修炼,经历若干次周天循环,开发者的思考习惯就发生了变化,首先思考如何实例化需求,因为开发者通过修炼了解何种需求是有价值的;接下来就是如何在实现的过程思考合理的引入模式,因为开发者明白何种模式能够更适合,区分哪些是坏味道;并自然地写下清晰通顺的代码,因为那是每次重构时的条件反射,只是简单地表达出来。

在经历了重构带来的开发习惯和思考习惯的变化之后,那么在设计过程中就会将这些习惯融入其中,化为无形,设计出功能合理的软件产品。

习惯的改变使得开发者可以站在一个全新的角度看问题,正如练就洗髓经的武林高手能够无招胜有招,花对手万般招数于无形,因为他们看到了最核心价值的东西。

最后引用豆瓣上看到的一篇奇文中的一段来说明练好重构这门内功的重要性,因为它能让你成为真正读懂软件开发,学会软件开发,运用软件开发的高手:鸠摩智上少林寺挑衅,使遍七十二绝技,方丈群僧无不骇然。这时,小和尚虚竹跑过来,只瞅了一眼,就说:“这位大师用的明明是小无相功嘛。”鸠摩智慌了。一般人看到的是招数(各种花式的语法,模式),厉害的人看到的是内功(开发的思想,设计的思想)。

笔者仍属于只见树木不见林的开发凡人,因此谨以此文激励自己向高手的路上前进。

Share