《你的灯亮着吗》阅读笔记02

  这是书中序言的内容,我觉得作者的思维好跳跃,没有见过序言这么写的,真的令人耳目一新。

  在解决“问题”之前,Weinberg首先抛出六个问题(真够多的)。 这是一本薄薄的书,书是由一个个小故事组成,所以也适合用这种方式来阅读。 应该承认我看得不够认真,没有仔细消化书中的“问题”,但是我已经从书中收获良多,最重要的一点就是:在发觉“问题”或“问题的迹象”的时候,不要迫不及待地就陷入“解决问题”情形中,而应该抽身出来,花上那么一点点时间来考虑“问题的问题”。我相信这种思想上的转变将是这本书带给我最大的好处。

  我们永远都不能消灭问题。问题、解决方法以及新的问题编织成了一条无穷无尽的锁链。我们能期望的最好结果就是新的问题没有我们“解决了”的那个那么棘手。问题其实就是你期望的东西和你体验的东西之间的差别。如果在对问题的理解中,你想不出至少3种可能出错的地方,那么你并没有真正理解这个问题。当我们考虑问题的时候,我们总是倾向于从思考中忽略掉我们已经习惯的东西。只有当“解决方法”导致我们习惯的元素被去除之后,我们才会震惊。所以,鱼总是最后一个看到水的。

时间: 2024-08-11 09:49:01

《你的灯亮着吗》阅读笔记02的相关文章

《构建之法》阅读笔记02

<架构之美>阅读笔记02 今天,我读了<架构之美>第三.四章,第三章主要讲伸缩性架构设计,书中说设计系统架构时,要确保系统在伸缩时的弹性,根据书中的介绍我对系统伸缩性的理解是每个网站在不同时期都会有不同的访问量,有时会很多,有时会较少,当较多的人访问你的系统时,你可能需要数量较多的设备来满足用户与系统的交互,但当访问的用户越来越少时,系统伸缩性如果不够好,很多设备就会被浪费,不能够与系统分离,这对于软件开发者是不可取的.Darkstar项目就是由Sun公司实验室承担的一个将在架构的

《用户故事与敏捷开发》阅读笔记02

 <用户故事与敏捷开发>阅读笔记02       这周读了<用户故事与敏捷开发>的第四至七章,第四章讲述的是如何搜集故事,也就是如何正确的去找到用户需求.作者明确指出"引用"和"捕捉"是不合用的.所谓"引用"和"捕捉",我想是通过用户对功能的表述,开发人员从中获取需求信息吧.如果是这种方法来获取需求,正如作者所说,用户不会知道所有的需求,所以只靠着这方法是远远不够的.对于故事编写的数量以及程度,作者认为

ijkplayer阅读笔记02

ijkplayer阅读笔记02 1.在这一章主要介绍音视频解码和显示线程的创建和启动,直接贴代码如下: IjkMediaPlayer_prepareAsync{ ijkmp_prepare_async_l{ ijkmp_change_state_l(mp, MP_STATE_ASYNC_PREPARING); msg_queue_start(&mp->ffplayer->msg_queue); SDL_CreateThreadEx(&mp->_msg_thread, mp

《需求分析与系统设计》阅读笔记02

在对于<需求分析与系统设计>第一章的阅读中我知道一个项目的成型的大致流程,一个软件的生命周期以及在不同的阶段我们应该采用什么样的方法.在不同的生命周期阶段当中我们应该做些什么,应该注意什么.对于一个软件的开发的方法. 对于第二.三章的精读之后了解到学习对象技术的主要困难在于缺乏明确的出发点和清晰的研究途径.没有像我们曾经了解的自顶向下或自底向上的一种学习方法.学习面向对象技术是一种“从中间出发”的方法.对于一个对象,我们首先要先确认实例对象,并且区分实例对象和类对象.那么关于对象呢,我们需要掌

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

&lt;&lt;需求分析与系统设计&gt;&gt;读书笔记之一

<<需求分析与系统设计>>这本书论述了软件分析和设计的迭代增量式过程,讨论软件分析与设计的原理,方法和技术,并特别关注了设计阶段,对软件体系结构的内容进行了很大的扩充.本书强调对象技术与统一建模语言UML在企业信息系统开发中的应用,并讨论了使用web技术和数据库技术进行开发的方法.这本书集中在面向对象软件开发上,统一建模语言用于捕捉建模的人工制品,主要论述用逐步细化的方式进行开发,并且在整个开发生命周期中都是用UML这种建模语言.系统分析师,设计师和程序员使用同一种语言和工具,但有

&lt;&lt;需求分析与系统设计&gt;&gt;读书笔记之三

终于把<需求分析与系统设计>读完了,感受很多,虽然理解还不是透彻,但还是学到了不少知识.在软件需求规格说明中,需要用图形和其他形式化模型来说明需求,为了完整地说明一个系统,有必要采取多种模型.UML提供了许多集成化的建模技术来辅助系统分析师来完成这项工作.规格说明的过程是迭代增量式的.对成功的建模来说,使用case工具是必须的.需求规格说明产生三种模型:状态模型,行为模型,状态变化模型.需求规格说明涉及需求确定期定义的客户需求进行严格的建模,重点放在那些系统将要提供的所期望的服务上.在规格说明

《UML大战需求分析》阅读笔记02

软件应能真正的对客户的工作提供帮助,只有客户使用并真正对其有用才能说我们做的软件成功了.客户从开始提出需求时到后期的工作过程中,需求总是不停变化的,所以这就需要需求人员对需求领先于客户.所以活用UML进行结构和行为建模,帮助我们更好的认识客户业务和做好业务流程再造工作.UML进行需求分析的过程: 搞清楚系统的目标和范围 找出该系统的所有关键涉众列出他们要解决的问题 分析业务,确认问题,发掘真正问题 针对问题,提出系统的特性 针对特性,提出系统的用例细化功能需求非功能需求 类图是用的最多的UML图

代码大全阅读笔记02

继续阅读代码大全这本书,感觉是好厚好难啃啊.刚刚开始读不久到了作者说把主要精力集中于构建活动,可以大大提高程序员的生产率.我想就一个项目来说,思路和设计是站着主导的地位的,你如果不能把思路理清,可能随时都有可能卡在那里,而一旦灵感来了,你就会想泉涌一样的来思路,我们也算是做了一个小的项目的了,虽然很low吧,但是好歹也算有点体会.我们总是在设计的时候会走投无路,不知所措,以至于每一次开始时都是没有思路起手都只能积压在那里,实在是不知道该怎么做.我觉得 P28 的那个食物链的例子更有说服力,健康的

人月神话阅读笔记02

贵族专制.民主政治和系统设计 本章主要是围绕着: 1.如何得到概念的完整性. 2.这样的观点是否要有一位杰出的精英,或者说是结构设计师的贵族专制,和一群创造性天分和构思被压制的平民编实现人员? 3.如何避免结构设计师产出无法实现.或者是代价高昂的技术规格说明,使大家陷入困境? 4.如何才能实现与实现人员就技术说明的琐碎细节充分沟通,以确保设计整备正确的理解并精确的整合到产品中? 就第一个问题文章是介绍的编程系统的目的是使计算机更加容易使用.对于功能,能够用最简洁的方式来指明事情的系统是最好的,对