《梦断代码》阅读笔记(二)

此次读后感为六章到八章,Chandler的开发真正到了高潮的部分,我也渐渐感觉到了这本书的魅力所在。

首先要提及的就是重要文件一定要备份,书籍作者由此经历了惊心动魄的一幕,长期的努力差点付之东流,而我个人也深受其害,电脑因为没有备份浪费了大量的时间去重新安装软件,拷贝文件。自此步入正题,作为一名程序员必须要能够站在用户的角度去思考问题,只有这样才能开发出用户交互良好的应用程序,书中提到了“妈妈测试”这个理念,正是对程序的深入要求。程序要面临的用户可能有成百万到千万,各种极端的可能都有可能出现,这需要程序开发者们设身处地去考虑。而要做到这一点就需要开发者对计算机有着深刻的认识,而对于像我这般初出茅庐的菜鸟就必须有着终身学习的觉悟,才有希望成为未来计算机产业界的一名合格的推手。

就团队而言,短期目标的实现对团队士气的鼓舞具有极其重要的作用,而文中chandler开发的长期一无所获是网景小子罗·蒙特利和阿历克斯·托蒂克离开的罪魁祸首。

书中提到了《Linux时报》发表的一篇对Linux“仁君”李纳斯·托瓦斯的采访,谈到关于做大型开源项目托瓦斯提出的一些建议:“别做大项目,从小项目开始,而且永远不要期望他变大。如果这么想,就会做过度设计,把它想象的过于重要。更坏的情况是,你可能会被自己想象的艰难工作所吓倒。所以要从小起步,着力思考细节。别去想大图景和好设计。如果项目没解决眼前的需求,多半就是被过度设计了。”这段话个人觉得受益良多,我相信,像我这样抱着美好愿景的菜鸟不在少数,太高的期望或者说太宏伟的计划,无疑会成为放弃的当先理由。这段话与我无疑当头棒喝。每当看客们对Chandler的缓慢进度表示怀疑时,卡普尔总会抬起他严肃的眉毛,评论说:“如果不坚持我什么都不是。”

读到现在,单纯的作为一名读者,我都对Chandler感到了深深的无力感,觉得他们恐怕是做不出来了,可这一刻,卡普尔的形象在我的心目中,再次拔高,这才是卡普尔真正的力量和魅力所在。Chandler是一个从开始就充满着理想主义的项目,很自然,开发的工作量和时间远远超出了预期,然而卡普尔始终坚持,这使我相信只要卡普尔还在坚持,Chandler就不会停止。

时间: 2024-12-17 22:55:13

《梦断代码》阅读笔记(二)的相关文章

掌握需求过程阅读笔记01

掌握需求过程 第一章什么是需求 阅读笔记 我们为什么要进行需求呢? 这样是为了使效率更高,并且减少错误步骤所不必付出的代价. 在我们构造产品之前就要知道客户的需求是什么,大多数的组织都是通过系统分析来进行的,但是需求过程与系统分析并不是一回事,虽然他们之间有联系,但并不完全相同.除了系统分析以外,需求也是很有必要的.他可以对你的分析师生涯有更进一步的促进.当我们接触到一个新的产品时,业务事件和使用情况逐渐清晰了起来,系统分析可以对产品进行更清楚的建模,并为需求过程提供有价值的反馈.对需求的了解增

《探索需求》阅读笔记二

在任何相当规模的开发项目当中,孤军奋战显然是像是一种幻想,为了获得一个团队所能提供的容量和差异性,我们必须放弃任何个人英雄主义的幻想,为和他人合作付出代价.而这种人际的花费在会议中体现的最为明显,会议也是一种工具,一种社交工具.很多人都会感觉会议是很可怕的,它有的时候并不会产生什么效果,但是我们离不开它,一旦离开会议,就只能开发出最简单的产品.每一个会议能达到的结果是度量需求工作的健康状态,一个糟糕的会议,说明了需求过程的不完善.要想每一个参与者都完全的参与进会议中,这个会议就必须是稳定的,我们

掌握需求过程阅读笔记—2

通过对事件驱动的用况.网罗需求.功能性需求这三个章节的阅读.使我们明白了在事件的驱动用况上,我们需要通过一些经验法则来定义用况,发现合适的用况:在网罗需求上,我们最需要做的就是进我们的一切可能去罗列用户的需求,并能及时的与用户沟通交流,确保产品符合最新的要求:在功能性需求方面上我们应当明白它是因为产品的存在的根本原因而存在的需求,它描述的是产品的动作,并能够形成一份完整的尽量避免二异性的功能描述. 事件驱动的用况是业务实践相应(活动和数据)的一部分,这些事件响应有产品来执行.用况成为了需求的锚,

寒假阅读笔记二

大型网站技术架构-阅读笔记二 模式:每一个模式描述了一个在我们周围不断发生的问题及该问题解决方案的核心.这样你就能一次又一次地使用该方案而不必做重复工作. 分层:将系统在横向维度上切分成几个部分,每个部分负责一部分相对比较单一的职责,然后通过上层对下层的依赖和调用组成一个完整的系统.分层时必须合理规划层次边界和接口,在开发过程中,严格遵循分层架构的约束,禁止跨层次的调用(应用层直接调用数据层)及你想调用(数据层调用服务层,或者服务层调用运用层). 分割:网站越大,功能越复杂,服务和数据处理的种类

构建之法--阅读笔记二

阅读笔记二—代码规范 代码的风格的原则就是:简明,易读,无二义性.我虽然是计算机系的学生,但是我以前却没有秉着这个原则来编写代码,现在阅读了构建之法后,我明白了如何让你的代码变得简明,更容易理解. 代码在编写的过程中注意: 用Tab键缩进 要注意行宽,最多限定100字符的行宽 在复杂的条件表达式中,用括号清楚地表达逻辑优先级 要注意断行与空白的{ }行,有明确的“{”和“}”来判断程序的结构 不要把过多的语句放在同一行上 对变量命名要有实际的意义 用下划线来分隔变量名字中的作用域标注和变量的语义

软件需求分析教程阅读笔记二

软件需求分析教程阅读笔记二 管理人员在要求开发一个系统时并不会理解进行需求分析的重要性,他们只知道能不能尽快开发出相应的系统来方便使用,但是如果不做好需求分析,最终开发出的系统也不会有人用. 客户的需求认识并不像软件开发人员这样,了解的比较清楚,客户通常并不懂得从系统的实际用户处得到信息的重要性,然而从产品的实际用户处收集需求有着不可替代的必要性,所以导致项目最终失败的两个原因,一个是缺乏用户参与,另一个是不完整的需求规格说明. 在进行需求分析时,只有系统的实际使用者才能清楚的描述他们要用此系统

《逻辑思维简易入门》(第2版) 阅读笔记二

<逻辑思维简易入门>(第2版) 阅读笔记二 本周阅读的是<逻辑思维简易入门>的第三章,也就是说,本书的第一部分就已经读完了. 第三章.信念的优点 信念和负信念是人们在接受一个事物时一种心理态度,延伸来说也就是对事物的认知态度.因为我们在研究 逻辑思维的时候,都有一个前提:“以正常情况以及说话者真诚”,所以有人如果对于一件事物不做回应,我们可以认为这是一种既不相信,也不怀疑的的态度. 信念的优缺点有很多,在书中主要介绍了下面几种: 1.准确性 好的信念实在准确的表达事实,同样真的信念

《掌握需求过程》阅读笔记二

了解了一些需求过程中的方法和问题,接下来就要网罗需求.网罗工作是由需求分析师来策划的,但是要完成这个工作需要分析师.用户和其他风险承担者相互合作,要明确每一个角色各自的职责.意识到的需求是指那些用户最先想到的需求,这通常表明用户希望改进的一些事情:无意识的需求是指用户没有言明的事情:未梦想过的需求是指那些一旦用户认识到它们可能时就会要求的事情.在网罗活动的过程中,必须揭示和捕获所有的需求,网罗活动具有多面性,它使用了一些来自启动阶段活动的输出结果:业务事件在网罗活动中占主导地位. 需求网罗的第一

《软件需求十步走》阅读笔记二

这一段时间阅读了<软件需求分析十步走>的第三四章,写一写书中一些个人感觉比较好的说法以及阅读感受. 首先是第三章<软件需求工程概论>. 需求工程和软件工程之间的关系界定没有质的变化,只是将需求工程从软件工程中剥离出来,将需求分析的分析工作和管理工作定义为需求工程.需求工程是面向全局的.系统顶层的.着眼未来的工程,是将客户业务作为内部研究对象,将软件工程全过程作为外部研究对象的工程.需求工程是圆心,软件工程是圆点. 需求工程的特征具有:全局性.主导性.主动性.过程性.规范性.可验证性

《探索需求-设计前的质量》阅读笔记二

软件是以人为中心的,所以说需求也是以人为中心的,而在使用一些工具的时候往往会忽略人的因素从而导致含混性.由于需求阶段所发问题越多,以后付出的成本就会越少,所以说含混性是非常重要的.整个需求与系统范围边界是有相似之处的,只要划定了什么是我们的需求,什么不是我们的需求,那就会很容易地,感觉这个也相当于是把复杂的问题简单化地过程,而基本上所有的问题都会是这样一个解决的模式,这也说明了事物之间的共性.而且,要在探索中发现乐趣会别有一番风味. 含混性是由于对事物的不同理解而产生了不同的解释,在对于含混性难