[TopLanguage主题讨论]今天我们思考

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/pongba/article/details/2270171

[TopLanguage主题讨论]今天我们思考

By 刘未鹏

 

最近一段时间,看了许多心理学思维的书,一些数学和解题的书,做了少许题目。两者结合起来,作了一点思考。本来是写了发到maillist里的,但写着写着这段时间以来的一些思考和总结冒了出来,超出了一篇mail通常的长度,遂贴了上来。

 

波利亚的《How To Solve It》里面有一个章节列出了一大堆的Heuristics(启发法),譬如把题目泛化、考察问题的特例、类比、看能否扔掉什么条件、看能否修改什么条件、时刻注意未知量...等等。

我有一个信念,所谓的灵感,背后一定有它的规则,虽然灵感发自无意识层面(参考《追寻记忆的痕迹》(坎德尔),以及《态度改变与社会影响》(津巴度)的"阈下刺激"章节),我们无法在灵感之前就在意识层面觉察到灵感诞生的过程,然而我们的确可以在灵感发生之后通过回顾和合情推理总结出最有可能的思路,数学的发展某种意义上做的就是这样一件事情,从最朴素的推理,到数学方法的产生——从三段论、形式逻辑、数学归纳法、类比、分治这些一般思维规则到鸽笼原理、极值原理、贪婪原理这类解决特定问题的原理,无一不是对思维过程的事后总结和整理。譬如我觉得形式逻辑就是最大的事后整理出来的思维法则,人类天生在无意识层面就具有推理能力(参见皮亚杰的认知发展原理),就像(也许)自然数是根植在大脑里面的概念一样,这些概念是进化出来的,我们无意识间就能够熟练运用。然而,要想让它们得到发展、生长,乃至能形式化到纸上,成为任何人都能操作的方法论,则需要意识的参与。

我们做题、做题、做题,往往认为到达熟练的唯一办法就是做题,认为只有埋头做题才能够提高能力。诚然,练习是必要条件。但有些练习比另一些练习更有效。

我们苦思冥想,在某个瞬间,从无意识层面冒出来一个点子,于是我们意识到,我们得到了灵感,于是我们欢呼雀跃;随着时间的推移,这样的灵感时刻也许会越来越多,于是我们认为这就是最有效的练习方法。我不这么认为,我觉得题目背后的思维大抵是相通的,通过一次次的等待灵感来练习,是被动的。在灵感出现之后总结为什么灵感会出现,背后可能有什么样的思维法则,看看能否泛化到一类题目,这样才是事半功倍的方法。

事实上,你有没有发现,在解决一个问题的时候,你所意识到的思维过程是跳跃式的,伴随着一个一个从无意识层面“冒”上来的点子,每一个这样的点子都会把你的思维推向前一大步,最重要的这样的点子,被称为灵感。由于我们的意识层面无法觉察到无意识层面的推理逻辑,所以人们只能绝望地认为除了在一次次解题中让你的无意识层面的神经元得到锻炼之外别无它法。然而启发法的出现却正打破了这个观点,所谓启发法其实就是"原本被我们无意识运用",而"后来被形式化地提出来,可以由意识来指导的方法"。一旦总结出了重要的、一般性的思维的法则,我们下次便有可能不用绝望地等待摸不着的灵感的闪现,而是可以系统化地尝试各种可行的手法(启发法)了。

要实现这个目的(即总结自己的灵感背后的思维规则进而泛化为一般性的解题思路),我认为一种方法是可取的,即所谓的"看得着的思考"——把你的思考过程详细的写在纸上。人的意识就像暗夜里的灯光,只能照亮一个很小的局部,如果不写下来,思维的灯光总是有限的,有可能走到后面忘掉前面,也有可能干脆就停在当地没法往下思考。写下来,可以避免这个问题,思维就可以往下走,思维的触角就可以扩充,灯光就可以照到越来越多的地方。此外,"写下来"还能够使得自己能够回过头来检视自己的整个思考过程——也许前面某个时候你想到一个东西,但如果不记下来你就很快忘了,而记下来回头一看也许你又有很大的启发。也许,你在思维的某一个环节上无意间引入了一个想当然的假设,从而掉入了思维定势的陷阱,通过写下来,就可以一定程度上避免这样的陷阱。

从一道题目中获得最多的东西,这是做题的目的。

你有没有这样的经历,一道题目你做不出来,你拿去问某个人,某个人想了一会儿,然后指出某个关键的步骤,于是一切豁然开朗。

但这远远不是全部!

如果你继续问他是怎么想到的,经验告诉我,几乎所有的可能性都指向一个答案"我也不清楚"。

为什么?我自己的经验是,我相信是因为绝大多数人都没有仔细反省自己思考的过程。如果想不出来,拉倒。如果想出来了,万事大吉。但波利亚在《How to Solve it》中说到,他在教学的过程中总是碰到这样的问题"你是怎么想到的"?这个问题促使了他去总结思维的规律,有了这些规律,即使不那么富有灵感的人,也可以运用这些规律,让自己的思维的触角能够伸展开去。我们也不妨把这些启发法称作思维的“方子”(recipe)

答案不重要,如果你直接告诉我关键的一步,我什么也没有得到。甚至就算我自己想出了最关键的一步,也许我还是什么都没得到。因为这样的经验只能极其有限地对我下一次的问题产生帮助;除非我能进一步思考思维背后的规则,才能让最多的东西为我以后所用。

所以,重要的是思考的过程,不管这个过程是不是带领你得到答案。我相信只有最深刻反省了思考的真正过程,才能够从做题中获得最多的东西。

遂发起这个系列"今天我们思考"(本来是想写"今天我们做题",但想到这个讨论的目的其实是思考,遂改了),大家都把自己认为最精彩的题目发上来(发的时候加上[今天我们思考<编号>]便于以后搜索),我想一定是一件于人于己都是非常有益的事情。

题目未必要新,很多人都做过的也没关系,我的经验是,就算以前想出来的题目,现在抱着思索“我是怎么想出来的”的态度再去反思,也能够得到很有用的东西。所以关键是题目要经典,要能体现出某种思路。

这个系列的关键是想要讨论做题的思路,而绝非题目本身,答案完全不是目的,就算得不出答案的思路也有很大的价值。如果你想到了一些思路,但看上去离答案还相差甚远,没有任何关系,贴上来,也许对别人的思路有很大启发。这是一个邮件列表内的头脑风暴。如果你想到了答案,并且能够总结出自己思路中的关键法则(你是怎么想到的),我想大家都会受益匪浅。

如果你对以往做题的思路有很好的思考,也欢迎和大家分享~

P.S. 邮件列表内的帖子和题目见这里,欢迎参与:)

展开阅读全文

高程漏题带给我们思考

10-16

从这次考试看,我觉得有下面几个结论:rn 1、国家利用这次考试骗取考生的钱,是不是有些危言耸听?rn 解释如下:rn 高考,作为一个相当重要的考试,费用比高程低,而且几乎没有什么rn 漏题现象(当然也出现过,从来没有像这次沸沸扬扬)。rn 试题的严肃性比高程威信高,从来没有发现过高考试题有错误之处。rn 然而今年的高程却连续出现错误,可见出题人心不在焉,审题人更是心猿 rn 意马。他们心思在哪里呢?在于考生的报名费、国家的保密费,可是这还rn 不满足,还要有漏题费呢!rn 2、考试重视不足,使这样的考试威望越来越低rn 题目出现错误,怪谁呢?rn 我都不知道今年出题目的人是不是懂得电脑(这有些气愤啊!),rn 看书会不会看重点,那么片的题目你也能出到,干吗呢?把我们当成明清rn 时代的八股文考生了?再看看下午的题目吧!出题人更可笑,把往年的试题rn 挪过来用C++描述一边就完事了,真有些佩服这位出题的人,你是不是学rn 文学的或者是鲁迅研究会之类的,《拿来主义》啊!rn 这是高程啊!我们这些考生对什么哪来主义不感兴趣的!rn 3、高程漏题带给我们的思考rn 作为一个编程人员,深知职业道德的重要行吧! rn 编程可以对社会有利,同样也是一把双刃剑,也可能造成危害。rn 所以要加强道德规范,然而今年高程的出题人员,竟然会昧着良心rn 把题目出错,至于漏题有没有你的责任,我不敢说。因为题目是你出的,rn 漏题可能还有其它的原因吧!rn 试想一下,你们的职业道德在哪里?你们的人品是什么?rn     中国出现的一些网络危害,是不是也有你们的一份功劳?你们的良心rn   区哪里了?难道真的是让狗给吃了(用得我们家乡话)rn rn4、最后的思考rn      漏题,已经是确凿无疑了。但是为什么偏偏漏的是高程题目呢。rn    这说明什么呢?一些小丑在我们的参加高程人员中混水摸鱼,所以rn    有个建议:如果大家觉得自己有能力并且对计算机有很浓厚的兴趣,rn    请你里考高程考场吧!去分析员考场吧!这里不再是我们想象的美好rn    地方了。我今年在天津参加的高程考试,其中高程考试人员占到水平rn    考试的2/3左右吧!看一看出这其中一定有部分人在混水摸鱼! 论坛

关于我们思考——“项目开发”及读《人月神话》有感

08-05

原文(原文作者用HTML语法作了标记方便阅读):rnhttp://web.nyist.net/~shadowstar/essay/engineering/thinking.htmlrn作者:rnshadowstar@163.comrn主页:rnhttp://shadowstar.126.com/rn--------------------------------------------------------------------------rnrn  项目开发终于结束了,按项目流程,我应该写一份《项目开发总结报告》。拿来“GB856T——88”标准文档,有框架指导我该写些什么,但是怎么能让这些框架协束缚了自由的思想呢?于是决定换一种形式。rnrn  项目开发接近尾声的时候,也是最关键的时候,有人送来一本《人月神话》。我很幸运能在这个时候读这本书,因为会有很多思考,关于项目,关于团队,关于我们……rnrn一、引言 rn二、成败 rn三、作好充分的准备 rn四、学会放弃 rn五、关于交流 rn六、整合与测试 rn七、留住激情 rn八、确立目标 rn九、结束语 rn一、引言rnrn  经过两个多月的艰苦熬战,我惊奇的发现我们的系统竟然可以良好的运行,而且完成了需求里所有的功能;虽然并没有完全按原计划完成,但仍可以说:“我们创造了一个神话!”rnrn  这段日子每个人都很辛苦。我们日落而作,日出而息;吃方便面,炒鸡蛋;24小时在电脑旁边……这不正是我们曾经梦想的生活么?辛苦的日子总是令人回味的,让我们一起回味这段永生难忘的日子吧。rnrn二、成败rnrn  我们把这块骨头啃下来了,就是我们的成功;我们为最终的成功迈出了第一步。当然,我们还有很多不足的地方。成功还是失败,很难下一个具体的定义。不以成败论英雄,不拿胜负谈输赢。重要的是我们能从这次项目开发中学到什么。rnrn  如果要指出项目的成功之处,“需求分析”算一个,详尽明确的需求分析为设计和开发明确了方向;失败的地方主要应该在协作开发上,否则我们可能会更早的完成任务。rn虽然我们这里有些人在一起合作过,但对于整个团队来说我们是第一次合作,算做一次尝试,我们应该从中吸取经验教训,找到一条适合我们发展的道路。下面把项目中遇到的,我想到的,结合《人月神话》中谈到的一一列出来与大家一起讨论。rnrn三、作好充分的准备rnrn  毛主席说:“不打无准备之战。”rnrn  我们的这一战作了充分的准备。接到客户的“需求说明书”后便着手分析哪些是可行的,哪些是不可行的。经过多次的协商,终于得到了一份双方都认可的《需求分析说明书》。与此同时对项目中必须要完成的技术进行研究,抢得了时间。rnrn四、完美与放弃rnrn  在《人月神化》中有一段被截取,称为“程序员的苦与乐”,在网上广为流传。Brooks大师用简短的篇幅,描绘出整个程序世界的苦与乐。在这次项目开发中,有两个苦恼体现的比较明显。rnrn  一是追求完美。“因为计算机是以这样的方式来变戏法的:如果口语中的一个字符、一个停顿,没有与正确的形式一致,魔术就不会出现(现实中,很少的人类活动要求完美,所以人类对它本来就不习惯)。实际上,我认为,学习编程最困难的部分,是将做事的方式向追求完美的方向调整。”rnrn  看来我再次做出了正确的选择,我是个追求完美的人,而且我也一直认为程序员就应该有这种本性。在写程序的时候,甚至对一个变量名我都要反复斟酌,直到选择一个我认为可以表达这个变量的意义的。我并不认为这是在浪费时间:一是有助于对程序的理解和维护,好的程序本身就是注释;二是减少错误发生的可能。这次开发因为时间短,我尝试采用设计->编码->编译的方式来写程序,经常把一个几千行代码的模块写完之后才开始调试。效果不错,因为对设计考虑的比较充分,基本上都是一些拼写上的错误。不过有一个错误却另我苦恼了很久。因为一个结构的成员变量名与函数参数的变量名一样,而这个参数又在多处使用,写的时候,也可能是拷贝代码的时候,很容易把结构名给忘记或多加了一个结构名,而这时又不会有语法上的错误。吸取了这次教训,我把整个程序检查了一便,并做了一些修改。这段程序我参考的一位大师的原型,令我欣慰的是,他的下一个版本和我的程序做出了同样的一些修改。rnrn  另一个“苦恼来自设定目标、供给资源、提供信息。编程人员很少能控制工作环境和工作目标。”后面章节又提到“结构师获得了所有的创造发明的快乐,剥夺了实现人员的创造力”。“实现同样是一项高级的创造性活动。具体实现中创造和发明的机会,产东会因为指定了外部技术说明而大为减少,相反创造性活动会因为规范化而得到增强,整个产品也一样。”程序员要学会放弃一部分乐趣,整个项目也一样,这是我读《人月神化》感触最深的一点。rnrn  设计网络认证的时候,本打算用一种简单的认证方式实现,因为这不是重点。Y提出用证书加自己写的Socket类实现认证的通讯过程。这是一个很好的创意,但VC写出类无法在Delphi里使用,BCB也不行。封装,回调……大家都搞晕了,只剩下两个字:“放弃”。rnrn  由于时间比较紧,产品的功能上也放弃了一些认为是很有创意的,但需求中没有提到的部分。后面的开发中也有类似的问题,每个人都按自己的喜好调用和提供接口,可以说是八仙过海,各显神通。问题主要在于交流。rnrn五、善于交流rnrn1.一切仿佛都很正常rnrn  由于做了充分的准备,每个人心里的那股劲儿也已经憋了很久了,一切仿佛都是按照“项目计划”中的步骤在紧张有序的进行着。可是没过多久,问题一个接一个的暴露出来了。先是Delphi没法调用Visual C++写的DLL导出类,然后一些人对自己的工作不明确,接着模块的接口没有按照事先约定的实现,之后调用方又不知道在什么情况下调用哪一个接口……rnrn  虽然问题并不是非常严重,而且也都得到了解决,但事实的确如此。有客观方面的原因,比如是在网络上协同开发,但网络的资源是否被有效的利用了呢?有技术方面的原因,比如在编程语言上的缺陷,不能随心所选择一种合适的语言,只能选择一个合适的模块。你可以说:“其实其他公司也差不多如此。”但怎么能把别人的缺点当作自我满足的标尺呢?这都不是主要原因,在设计的时候也都考虑到了,如搭建企业内部协作平台,增加中心调用控制模块。最重要的是交流的不够,或方式不合理。人与人之间的交流是影响整个项目开发的关键,这是我在项目开发中体会最深的一点。rnrn2.交流方式rnrn  人月之所以不能成为神化,正是因为增加人手的同时也增加了人与人之间的交流。rnrn  我们在项目一开始就通过QQ群组进行沟通,后来又搭建了企业内部协作平台,而且还有不定期的会议。与大师所说的三种交流途径——非正式途径、会议、工作手册——不谋而合。但是,执行的效果却不很理想。是大师说的不对?不是。是我们没有利用好这几种途径。我们很好的利用会议,解决很多细小方面的误解;过多的使用QQ群组,一是在登陆QQ的时候消息太多而没看仔细,二是这种方式针对小的误解是很有效的,但对于一些系统的全面的理解必须通过文档;但是很少使用协作平台,没有仔细的阅读文档的习惯,也没有写出一个完整文档的习惯。rnrn  即使在QQ群组的交流中,也没有把问题表述清楚。经常看到:“某某:你那里有问题?”哪里?什么问题?QQ都是通过UDP传输的,这里就不需要发送ACK了,对方不在线可以通过服务器中转,到论坛发一个贴子或直接发送邮件。接着有人回答:“不可能啊?”什么事情都可能发生的,只要能满足条件。域名都会不易而飞,还有什么是不可能的呢?出了问题首先从自身找原因,发现一切的可能。rnrn3.如何阅读别人的文档rnrn  首先必须摆正姿态,把阅读文档当成一种习惯,不要抱有不懂再问的心理,写文档的目的之一就是减少交流的次数,如果你问了一个文档中描述的很清楚的问题,你得到的回答将是:“去看文档。” rnrn  其次你要知道这是一篇关于什么的文档,对于整个项目手册来说它处于一个什么样的位置,可以根据你的需要读取相关的部分。rnrn  再次,当读到不明白的地方,从文档作者的角度出发,想一下为什么是这样。你要尊重他人的劳动成果,也许你觉得很平常的一句话,却是作者用86400ms*1K脑细胞换来的(一个脑细胞对应一个方法)。rnrn  最后,如果还是想不通,可以查阅相关的文档,或到网上去搜索相关资料。实在是想不通,再把你想不通地方整理好,最好也是用文档的形式,也可以直接告诉作者,等待回复。也许你是对的,但在得到正式确定之前必须按照原文档中所说的去做,以保证整个系统的完整性。rnrn4.如何写文档rnrn  由于项目开发周期十分短,我只定义了各个模块的功能,接口标准,和接口说明的标准。这就要求每个成员把自己模块接口的详细说明提供给调用者。但很少有人按照给出的标准书写接口和文档,而且文档说明也不够详细。rnrn  为什么要写文档?一是减少交流的次数,提高效率;二是得到清楚、确定的策略,接口说明应该在接口实现之前就已经写好;三是为整个项目的规划提供依据。rnrn  文档并不一定要按照标准来写,但标准有助于交流。一个好的文档应该让一个没的接触过此项目的人一看就明白你想要做什么,怎么做。有些时候阅读的人只读他感兴趣的部分,因此尽量在每一个部分就把事情描述清楚,如果是引用或继承要说明出处。不要怕麻烦,现在的一点点工作会为以后带来很多方便,否则会适得其反。 rn 论坛

构架思考--我们为什么需要构架

08-23

在一个典型的系统的开发过程中,首先是客户提出需求,设计人员根据需求进行分析和设计,程序员根据设计进行编程,最后是系统的测试和系统的分发。在整个软件过程中,参与到系统的角色各不相同,各种角色之间的关系是既合作又敌对的。系统的客户总希望花更少的前,获取更多的功能。开发公司则相反。开发人员讨厌无停止的改动,客户则认为开发出来的东西总是不满足自己的要求。在开发的过程总需要一个能够折中体现参与到系统的不同角色的不同要求。一套详细的设计说明?如果时间和金钱上允许的话,也许可以这么做,而且客户也许会没有耐心和你讨论关于函数接口的问题。或者是什么都不做,加快时间把系统做出来再讨论。实践证明了此路不通。我们需要的模糊和过分的详细之间找到一个平衡点。我们把它称之为构架。构架体现了不同风险承担者的要求的综合,借助于构架,设计师就可以分析众多风险承担者所提出的各种要求的优先级别,并且将这些要求转化为系统的各个特性,针对这些的特性,系统要在结构上做一些的妥协。rn 在上面我们提到系统特性,在《软件系统和软件构架》中也提到两个概念,原则(principle)和质量属性(Quality attributes)。这三个是相互关联的概念,rn我个人认为系统特性是质量属性的具体的体现。软件的质量属性是指软件的性能,安全性,可用性,功能性和使用性等。系统的具体的某个需求大多数可以归纳为某个种rn类的质量属性。在SEI的Architecture Tradeoff Analysis (ATA)中就讨论了如何将系统的需求归纳整理为不同的质量属性。原则在某种程度上等同于质量属性,比如说某套系统的开发过程中的技术原则是要能实现互操作性,在质量属性中也有类似的概念。基本上来说原则更为工程化一些,也就是在不同的系统中,你可以制定不同的原则。而质量属性相对更为抽象一些。在SEI方面的软件构架文章中,我们常看到的是质量属性,而在IEEE 1470-2000以及TOGAF8中,都是用原则(principle)来表示。无论是质量属性还是原则,都是作为评审软件构架的标准。在以后的文章中,我们就统一采用质量属性这个称呼。rn 由于构架综合体现了不同的风险承当者的要求,不同的风险承当的所关心的问题肯定是不一样的,所以在进行构架描述的时候,我们需要从多角度的来进行描述。就象建筑设计中一样,把所有的东西,比如外观设计,受力设计,水电设计等都放到一起肯定是不可行的,但这些分开的设计也不是都毫不相干的,它们之间既相对的独立,又相互联系,形成对一座建筑的完整的描述,不同的参与人员只关心他们要关系的时间,如结构工程师关注受力设计,水电工程师关注水电设计,建筑设计师负责整体统筹规划。在软件构架设计中也是一样,通过多个相对的独立又相互联系的视图来对构家架进行一个完整的描述,关于构架描述的权威性论述是IEEE 1470-2000,在SEI的《软件构架实践》中用软件结构来表示类似于构架视图的概念。"Architectureal blueprints- the 4+1 view model of rnsoftware architecture"提出了一个被广为使用的构架描述的模型,RUP过程的构架描述模板和HP公司的软件描述模板都和这个有莫大的渊源。也正是因为通过多个不同的角度来描述说明构架。不同的风险承担者可以通过构架进行交流,并且找到解决方案。基本上来说,构架的重要性可以被归纳为以下三点:(1)构架是风险承担者进行交流的手段。(2)构架是早期决策的体现。(3)构架是可传递,可重用的模型。具体的说明参见《软件构架实践》中的‘什么是软件构架’一章。由于构架如此的重要,在RUP过程中更是明确的说明整个的设计过程是以用例为驱动,以构架为核心的。 论坛

没有更多推荐了,返回首页