CompilerTech

导航

R型思维模式对软件开发的影响(草稿)

The pragmatic programmers

  一直在工作之余读些书,之前主要是纯英文版的计算机相关的算法,编译器,数学等,想通过读这些书来提高自己每日工作效能,结果收效甚微。一是,因为纯英文的书,阅读的慢,第二,也是最重要的一点,发现掌握的很慢,思前想后感觉可能是和工作的内容距离较远,两者不能互相辅助,第三,不能直接的回馈工作本身。

         索性就换一换类型,最先入手的,是《agile software development-principles, patterns, and practices》,接着回顾了《code complete》。依然觉得使用时(写代码,或者就某个设计与别人讨论时,等),无法得心应手的应用。

         再换类型,这次是the pragmatic programmers系列。Eureka!我需要加强这些方面的学习。先开始读的是《程序员的思维修炼--开发认知潜能的九堂课》,它主要讨论了如何pragmatic thinking and learning, refactor you Wetware。我们都听过software, hardware, 什么是wetware?你的大脑!

德雷福斯模型

         在稍微靠前的章节,这本书提到了德雷福斯模型,这个模型是用来研究人类如何获取和掌握一项技能的。它分为5个阶段:

阶段

特征

 

新手

l  没有或者很少的经验(包括,一年的经验又重复了九年,也就是号称十年的经验。);

l  很在乎是否成功,很容易因为不成功而慌乱;

l  不是很想学习,只是想要一个立竿见影的目标;

l  如果提供给他们与情境无关的规则去参照,他们会变得非常能干。请记住,情境相关的情况下,他们会无法做出正确的选择。

需要指令清单,清单只能让你启程,不会让你走很远。

比如:呼叫中心工作人员,给他们规则,按部就班,照决策树执行就一切Ok。

高级新手

l  高级新手,多多少少开始摆脱固定规则,它们可以独自尝试解决问题,但仍难以成功。

l  他们想快速获取信息,浏览到某个API时,不想在一些细节处寻根究底,或者重新温习一边基础知识。

l  根据过去经验,逐步在正确的情境中采纳建议,但比较吃力。

l  他们没有全面的理解,同时也不想要全面的理解。

你是否关心CEO展示的全年销售数据?

胜任者

l  能够建立问题域的概念模型,并有效的使用他们;

l  可以独立解决遇到的问题,并开始考虑如何解决新的问题;

l  他们开始寻求和运用专家的意见,并有效利用;

l  胜任者会探寻和解决问题;

l  如果没有更多的经验,他们将难以确定将关注哪些细节。

l  有主动性,足智多谋,缺乏足够的能力反思和自我纠正

 

精通者

l  观察,并从中学习

l  有全局思维,寻找并了解更大的概念框架;

l  能够反思、纠正过往不好的工作表现,自我改进;

l  能够预料下一步将要发生什么;

 

专家

l  专家是各个领域知识和信息的主要来源;

l  他们不断寻找更好的方法和方式去做事;

l  他们能根据情境不同,选择不同的应对方法;

l  他们著书,立说,演讲;

l  根据直觉工作,“觉得这样是正确的”,不需要理由;

l  综合过往经验,知道从哪些方面去忽略细节,抓住主要矛盾;

 

         后面的内容,我会使用这个模型来给自己定位。同时也想其他人能够找到自己合理的定位,进而知道应该如何努力改变现状。

Wetware refactor

         这里说到的wetware就是人的大脑。

Refactor,我觉得是一个被IT从业者新发明的单词(到目前为止,在牛津高阶字典第八版里,查不到这个词),意思是代码写的不好,在保证功能不变的前提下重新组织一下代码,让他们更加易读,易于理解,维护。简单一点理解,它就像把家里收拾一下:你感觉她脏了,乱了,布局不合理,那么就重新布局,打扫一回,甚至装修一下,然后她就焕然一新了一样。

          Wetware refactor与code refactor一样,都需要先弄懂要refactor的对象:大脑的工作机制,才能很好的refactor。

左脑和右脑

         从一个非常成功的试验入手,这个试验使其开创者心理生物学家Roger W. Sperry获得了1981年的诺贝尔奖。

         首先,先自己做个小实验吧。坐下,抬起右脚顺时针旋转,与此同时,用右手在空中写数字6。在我做这个实验时,当我开始写6的时候,我的脚开始和手写6的方向变得一直。你也可以试验一下。这是大脑关联的结果,剪断这种关联会发生会让你表现出一些怪异的行为。

   剪掉这种关联?怎么剪掉?开颅,拿剪刀,找到胼胝体,剪,就可以了。太血腥了吧,事实上这个实验的机会是由60年代的癫痫病患者给予的。这些癫痫病患者由于大脑病变导致经常性痉挛,脑科医生们一怒之下切断了他们的胼胝体,使得他们的左右大脑分离开来,脑部的病变也就被控制住了,而且,令人惊异的是,这些患者手术之后竟然没有什么异常,反而十分开心。于是,我们英明的Sperry发现良机,他立即邀请这些脑子被人一分为二的“裂脑人”加入了自己的实验,而年轻的心理学家Michael Gazzaniga也加入Sperry的实验,于是史上久负盛名的裂脑人实验拉开了帷幕。

 

         研究人员在同一时刻为这些脑裂患者的两只眼睛展示不同的图片,如果要求他们说出看到的图像,他们会报告右眼看到的画面,他们会用语言描述右眼看到的画面(右眼是由左脑控制的,有负责语言功能的中枢)。但是要求他们触摸图片以确定图像,他们会触摸左眼看到的画面(左眼由右脑控制,这里有非语言中枢,行动中枢?)。

         这里有一个潜在的知识点:右眼由左脑控制,左眼由右脑控制,这个知识点的第一印象是基于中学生物知识的。先是回顾中学知识,后是怀疑正确性,碍于时间限制没有去搜索相关的论文只是百度了一下。百度搜索“左眼 右脑”证实了它。百度会返回很多左眼有毛病,右脑不舒服的例子:

        

        

         更多脑裂人的实验请参考附录。

         左脑和右脑,处理的内容形式上差很多,比如左脑是语言的,文字的,右脑是图像的,声音的;工作方式上也不是不一样的,左脑串行,右脑并发;工作特征也不一样,左脑抽象,右脑形象。

 

 

双CPU模式的大脑

 

Sperry最早指出了脑半球各自不同的功能,在现代词汇中首次引入了此条左半球和右半球,但事实上这种说法并不完全正确。不论是古老的爬虫类脑部,还是新近发现的大脑新皮质,他们之间都有协作。他们的不同是物理的,是认知风格的不同:

  1. 1号CPU负责线性,逻辑思维和语言处理,它就像传统的冯诺依曼式的CPU,按部就班的处理指令。我们把这种线性处理方式命名为L模式。
  2. 2号CPU则有很大的不同,它就是大脑中的GOOGLE搜索引擎,它使用正则表达式来从大脑中所有的信息中去匹配,搜索。它的搜索结果是异步返回的,也就是当你有了某个疑问后,触发这个搜索你就可以去思考别的事情去了,数天后,只要你依然对这个问题感兴趣并且你的大脑里有这个答案,那么你就可能就会得到这个答案。我们把这种模式异步、综合处理模式命名为R模式,又叫富模式。

请注意这两个CPU共享通往内存核心的总线,这意味着1号CPU占用总线,2号CPU无法获取内存执行操作。同样,如果2号CPU进行一个高优先级搜索,1号CPU也无法访问内存,它们互相干扰。

L型,线性模式

         上学时,以及日常工作中用到的分析、总结能力,都源于此模式。主要有:

  1. 语言能力,使用词语来命名、描述、定义;
  2. 分析能力,有理有节分析事情;
  3. 符号能力,用符号表示事物;
  4. 抽象能力,抽取小部分信息(本质),并用其表示事物整体;
  5. 时间能力,遵时循序;
  6. 推理能力,基于理智和事实得到结论;
  7. 数字能力,使用数字计数;
  8. 逻辑能力,基于逻辑(定理,明确地论点)得出结论;
  9. 线性思维能力,按照关联、依序推演问题和思考,经常会得出收敛性结论。

L型思维方式区分了人类和普通动物,它带领人类走出了森林和热带雨林,组织起来了村庄和城镇,从田间地头走入工厂车间,最终做到办公室里用Microsoft Word写下了这篇文章。

但,毕加索曾说过“计算机一无是处,他们只能给出你答案。”如果答案不重要,那么就是“问题”重要。而这一点违反L型思维,因为基于L型思维的逻辑推理、思考,问题才是我们花费各种努力要寻找的,怎么可能最重要的是“问题”呢?

R型,富模式

R型是非语言的,它可以获得语言但是无法创建语言。它喜欢综合学习,集合事物形成整体。它具有空间性,喜欢弄清楚事物之间的空间关系,部分如何形容整体。它是直觉性的,跳跃性的思维。它可以给予不完整模式、直觉、感觉、视觉影像来做推断。具体列表:

  1. 非语言,
  2. 非理性,
  3. 综合,
  4. 空间性,
  5. 具体,
  6. 直觉,
  7. 分析,
  8. 全面,

R型模式,非常擅长类比,或者说模式搜索;它天马行空,不愿意为守时费心。它不受理性的约束,不需要基于原因或者已知事实来处理输入,它完全愿意暂时不做判断,来者不拒统统接受,因而它能不必先理解再学习进而吸收。

R型模式,更像是从远古时期遗传下来的一种思维方式。就拿直觉来说,从看到危险到反应,无须逻辑、推理、判断,直接跑开就对了。空间感也一样,在低级动物时期,可以没有语言就能存活,但是没有空间感,如果是只老虎,不能判断从山崖到地面的高低,它已经摔死了,不会参与进化过程了。

在与R型模式对应的L型模式下,成人很难不理解一样东西,但能记得很牢靠。L型模式是典型的:你要进入我的世界,你得先让我认识你,理解你,觉得你放心,你不会捣乱,你对我有意义等,我才让你进来。

R模式还有一些其它独特的特点:

  1. 正如上面提到的它是异步的,也就是你想回忆一个东西当时不一定能想到,某天在想另外一个东西时,想到了,或者晚上睡觉梦到了。与这点相关的另外一点就是:
  2. 不可预测性,答案和灵感会独立于你的意识活动出现,而且不总是在恰当的时候,你需要时刻准备着纸和笔;
  3. R模式不受主观意识直接控制,就像心跳速度不受你控制一样;
  4. R型提供直觉,提供隐性知识;
R型模式的应用

         就像前面说到的L和R型模式是共享内存总线的,他们互相排斥。而现实中的我们又大部分在使用L型思维在说话,生活,思考,工作,如何快捷进入R型模式呢?

         很多常见休闲活动都能够激活R型模式的思维:听音乐,绘画,静思,慢跑,针线活,攀岩等,各种手、脑、眼需要协调一些活动都可以瞬时启动R型模式。有一本非常出名的书,叫《用右脑绘画》。它教人们如何停止L型模式的思维,全面开始R型模式,每个人都可以很快学会画画,并且还画的不错。我已经开始尝试了,期待不久的将来能展示给大家看。

软件开发中的R型模式

  R型的类比和整体思考方式对软件架构和设计非常有价值;在开发中使用原型和独立的单元测试,编码和构建并且从中学习应用了R型综合。随着Agile,Scrum的流行,结对编程已经不再陌生。结对编程中的Navigator表现出来的R型模式就明天多于Driver。Navigator更多从架构,层次,易读,美观等方面综合思考。而这其中的“层次”,多与隐喻相关。隐喻的思维过程基本上是:搜索,模式匹配,建立联系,抽象,变形的过程。最后通过语言表达出来。也有一种说法:隐喻是连接L型与R型模式的桥梁。

隐喻

  隐喻(metaphor)源自希腊语metaphora,“转移”的意思,表示你正在以一种事实上不可能的方式把一个事物的属性转移到另外一个事物上。事物的属性,是对事物的抽象,找到他们共同存在的抽象,把这个抽象从用来描述A,发展到描述B,这就是隐喻。

  从小学语文开始的类比,比喻,都属于这一范畴吧。在软件开发领域,“瀑布式”开发过程,瀑布式就是隐喻。这种开发过程都有一个特点就是,"从上而下" —这是对瀑布的抽象,也是对这种开发过程的抽象。

  诗歌中有很多隐喻,“疑是银河落九天”,“爱情是叹息吹起的一阵烟”,“哲学史逆境中的蜜乳”等。

         《代码大全》。。。。(待补充)

离开键盘去解决难题

  著名数学家庞加莱有一套特殊的解题技巧。每当遇到一道困难、复杂的问题时,他就把已知的、与此相关的从西都写在纸上,这么做可以揭露许多问题,先解决掉那些简单问题,然后挑出剩下问题中的最简单的问题,离开办公室除去走一走。只思考这一个问题,一旦有了灵感,马上中断散步,回去解答之。重复此步骤,直道所有问题都有了答案。庞加莱,如此形如此过程“想法会成堆的出现,我感觉它们一直在碰撞,最后发生结合,也就是说,产生稳定的结合”。

  把问题相关的关键点写在纸上,然后记住它们。除去散个步,听听音乐,让写在纸上的那些东西,尽情在R模式思维中去自由的搅和、浸泡,直到找到灵感后返回来去解决问题。

  类似的经历,我也有过,那就是,当我感觉一个问题太大,思考不过来时,我就把它们已知的东西,都写出来。然后从这些已知的概念,方法论出发,激活大脑,尽量让你感觉大脑被打了鸡血一样兴奋起来了,然后开始发散思考。我的激活方法是深呼吸,然后想象一些非常美好的,让你感觉非常安全的东西,这是一股暖流从心底升起,遍布全身。这个时候,我觉得,大脑里那些列在纸上的那些知识点闪闪发光,试图从他们为中心,向各个方向散射,找到合适的解决方案。

我们不再需要Coach

  我觉得目前我们请到的一些Coach几乎没有什么或者也没有比我们多很多的编程经历,为什么他们那么能说,并且确实能够给我们一些指导呢?我觉得主要是它们就是看的书多了些,并且他们也一直是在充当结对编程中的Navigator而已。这一点从我们几乎所有的Coach给我们带来的影响在两到三个月后就开始看到边际效应可以猜测到:

  一方面,他们不能深入项目的代码,而深入代码恰恰是考验Coach功力的时候。因为我觉得一旦深入开始作为Driver,脑的限制,7+/-2 原则,也就开始出现了。再看他们掌握的那些经典案例,也就是书上最简单的sample code 情况下,应该如何处理。他们已然烂熟于胸了,这些知识在我们讨论代码设计时不需要再占用7+/-2空间,所以他们可以有多于的buffer用来讨论那些设计,原则。一旦让他们开始深入我们的代码:前面有三个if后面有四个else和一个经常出Regression的函数,它们也会歇菜。

  第二方面,我们,缺少读书,缺少那些看起来很酷的工具,而这些恰恰是书里学到的。所以我们要做的就是,读书,多读书,把我们可能用到的书,大家都好好读一下,慢慢研究,多投入点时间。当我们需要哪方面的知识时,找咨询公司,问一下我们需要读哪些书就好了。读完书,象庞加莱那样,遇到什么问题了,把已知的概念,方法论,列举出来,思考一下,我们每个人都是完美的Coach。

  第三方面,Coach,给我们的感觉就是老师带着学生解题,而学生始终不能自己解题,因为这是缘木求鱼而已。我们需要的是,读书,建立完整的思想体系,健全解决问题的工具,从而某天开始我们每个人都是Coach,Coach自己,Coach别人。

  读书,明晰概念,设计原则,怎么样平衡。遇到问题,写下那些已经学到的,对当前问题有帮助的知识点,让他们在脑中闪耀,停下来多想;问题比Coach解决的还漂亮。

  

    真正的发现之旅不在于追求新大陆,而在于拥有新的视野。

                           -------------马塞尔-普鲁斯特

 (未完待续)。

 

posted on 2014-08-18 21:07  compilerTech  阅读(469)  评论(0编辑  收藏  举报