构建之法读后感2

1.专业

2.但是不迂腐,很接地气

3.但是不屌丝,很有情怀

由此可见,《构建之法》是一本当代软件工程大学教育急需的好书。

本人在大学上的软件工程课用的也是较老的课本,讲的是瀑布式的环节,带着对这门课残留的记忆参加实习的时候,最大的不适应就是对需求变化的反感,当时还不知道“迭代”这个词,只觉得做事情是要“谋定后动”的,“庙算多者胜”,怎么能大概了解下需求就开始动手呢?“需求分析”难道不该做的认真、准确、达到一劳永逸的效果么?由于自己是深思型的人,偶像是林彪元帅,当时在思考之后得到一个“林总体”的结论——领导催,组长骂,都要顶住,反正我要准备好了(指分析、设计)再动手!

——当时已经是2010年,《敏捷开发宣言》却还听都没听过。

后来看到了,“响应变化胜过遵循计划”,第一反应是排斥,时至今日我也认为“拥抱变化”的提出有取悦某些人的成分,当然,作为一种方法论,想要推广,必须满足市场最大的需求,而这个行业最大的需求,就是业务的变化。因此理想化的一劳永逸的需求分析是不可能的。但“响应变化胜过遵循计划”用偏了就成了不想就做,边做边想,反而容易在整体上失去设计,这句宣言的“拥抱一切可能性”的精神,反而会因整体上的缺乏设计,而能够修改的空间很小,当需求变化的目标与一开始的代码很不兼容的时候,或者大幅度重构(工作量接近重写,而且重构没有重写那样顺畅的体验),或者采用“小修小补”的方式,以不断降低代码质量来“拥抱变化”,饮鸩止渴,至于“持续重构”,其风险和工作量又没人愿意承担,不是说“重构的第一原则就是不要重构”么?

这让我产生了非常大的疑惑,因为我心中的真理是“不谋全局者,不足谋一域”,需求变化自有其范围,我们要做的其实应该是,在计划的过程中考虑到种种变化的可能性并预留出空间,而不是把希望寄托在“随机应变”的不确定性上,“战已合而不知胜负者,无算也”,被“做了再说->修补->走人->接手人员骂娘”坑了的不是一个两个,当然这种现象应该归因于人员素质低下而不应把黑锅丢给敏捷,敏捷自有其建模、重构的方案,但我们往往想得太少,敲得太多,而对“响应变化胜过遵循计划”的错误解读可能会让人想得更少,敲得更多——而且返工得更多。

这是我当时对敏捷的怀疑,但出于对Martin Fowler等大师的敬仰,一直在认为是自己修为不够,不能理解精髓。直到看到酷壳网上的博文,才知道怀疑者大有人在,直到翻开《构建之法》112页,“敏捷宣言表明的是一些优先级,不必当作圣旨或者教条来争论”,才恍然大悟,自己果然是深中迷信权威的毒,“没有银弹”,“兵无常势,水无常形,能因敌变化而取胜者,谓之神”,这些话,怎么就想不到呢。

就更想《构建之法》的好,如果大学就看到这本书,要少死多少脑细胞啊,读君一本书,胜思三年考,什么“终日而思”“须臾之学”的,说的就是这个。

回过头想想在学生毕业成为职业程序员的过程中,《构建之法》能雪中送炭的点。

首先,这是一本全景式图书,会让你更了解这个行业,能让毕业生在对行业从陌生到熟悉的过程中,较少地感到惊讶和出乎意料,这是一本与现实接轨的教材。

其次,这是一本最佳实践式的书,涵盖了科学、健康的软件工程开展中的每个方面,介绍了种种方法论,但不是高高在上、纲领性的方法论,而是方法论的最佳实践,确实可用,拿来就用。

第三,这本书让人有情怀,学生对“古老的”瀑布教材或“舶来的”敏捷书籍,难免会缺乏信心:这东西行吗?适用于现代吗?适用于中国吗?而如果到各大论坛、社区、或者询问“过来人”,往往会收获更多的负面信息,让本来有情怀的学生失望,让本来就缺乏情怀的学生甘心。但很明显我们这个行业需要的是更有情怀的人才、更好的职业道德和素养,如果学生在毕业前就俯首认输,行业还有什么希望可言?邹欣老师的教材会让学生知道“应该如此”而且“可以如此”,从这点上看,功德无量。

第四,这本书在介绍方法论的同时,居然会介绍方法论不适用的场景,介绍方法论在现实中是怎样跑偏的,这就好像讲下棋,“这样走,之后的发展会怎样怎样,所以不行”,怎样做会对,怎样做会错——什么叫宏观视角?什么叫最佳实践?什么叫算无遗策?就像画一棵决策树,向哪个分支走,结果会怎么样,清清楚楚,明明白白,让人信服。

第五,这本书在介绍方法论的时候,并没有把“人”放到“方法论”的下层,而是介绍了种种角色、有血有肉有情绪的人,能让学生了解到工作中接触的种种角色及其想法、诉求,避免“以程序为中心”思考问题,而懂得以人为中心来思考,毕竟程序要解决的,是人的事情。这个思想的转变,对程序员来说,至关重要。

这本书涵盖了现代软件工程的全部,每个章节甚至每个段落拿出来,都可以在实践中作为指导。

这是一本浓缩了无数精华的好书,搞软件的应该人手一册,就像每个兵家必备一本《孙子兵法》一样。

时间: 01-31

构建之法读后感2的相关文章

构建之法读后感----第1章 绪论

首先,文章对于程序.用户需求.工程等等概念用了阿超给儿子编写的一个出题程序来分别解释了个中的含义,尤其是程序和工程的区别,程序大概就是用很多语言或工具编写的一个简单能实现目标要求的一行行代码,而工程就是在这个程序的基础上不断满足用户的需求.修复程序的bug.提供后续维护等服务. 需求分析:梳理需求,逐步展开后续工作,如设计(软件架构).实现(写数据结构和算法),测试,发布软件 软件=程序+软件工程(软件企业=软件+商业模式) 软将工程的核心部分:构建管理.源代码管理.软件设计.软件测试.项目管理

构建之法读后感01

读后感 01: *理论和知识点 *计算机科学的领域 *软件工程与计算机科学的关系 * 软件的特性 * 软件工程的定义与组成 虽然作为一名程序员中的菜鸟 我也深知“软件=程序+软件工程”.在此之前我们学习过一个个从小到大,从简到繁的程序,到了今天才知道这些只是作为一名合格的程序员的第一步,构建之法是一本很专业的书,不仅仅从专业的角度为我们阐释了软件工程是什么? 总而言之从这本书中我初步了解到了如下内容. 软件工程(SoftWare Engineering)的框架可概括为:目标.过程和原则. (1)

一、构建之法读后感

这学期的软件测试课程多加了<构建之法>这本书,这学期利用自己的课余时间学了这本书,感觉受益匪浅. 对于这本书可以简单地有两个词语来概括:"专业"."接地气". 这本书的开头就是给我解释什么事软件.什么是软件工程.上大学将近三年,说实话还没有一次真正的去了解过什么是软件,什么是软件工程,说来还是有些惭愧的. 首先,这是一本全景式图书,会让你更了解这个行业,能让毕业生在对行业从陌生到熟悉的过程中,较少地感到惊讶和出乎意料,这是一本与现实接轨的教材. 其次,这

构建之法——读后感

好吧,其实一开始在课上接触到这本书的时候还是略有点抵触,毕竟不是通过自己“即可寻求”得来的资源,但是看着看着,慢慢也就好了. 在我感性认识上的构建之法,其内容不同于其他的“类教材”书本,甚至都不同于我之前阅读过的所有书(好吧,也不排除我认知局限性因素的干扰),构建之法的叙述方式相对于“书本”来说,更像是以写博客的感觉在写书,让读者有一种仿佛在杂志上阅读博客的享受. 对于计算机相关专业的学生来说,我们学习了很多的专业课程,像编程语言.算法.数据结构.编译原理.软件工程等.很多学生都会有这样的疑问:

《构建之法读后感》

这是一本全景式的书,会让你更了解这个行业,能让毕业生在对行业从陌生到熟悉的过程中,较少地感到惊讶和出乎意料,这是一本与现实接轨的教材. 是一本最佳实践式的书,涵盖了科学.健康的软件工程开展中的每个方面,介绍了种种方法论,但不是高高在上.纲领性的方法论,而是方法论的最佳 实践,确实可用,拿来就用.本书在介绍方法论的同时,居然会介绍方法论不适用的场景,介绍方法论在现实中是怎样跑偏的,这就好像讲下棋,“这 样走,之后的发展会怎样怎样,所以不行”,怎样做会对,怎样做会错——什么叫宏观视角?什么叫最佳实践

构建之法读后感

 我现在是一名大三学生,即将面对实训这件事,而今年才刚接触软件测试这门课程,讲的是如何测试代码可行性,都有什么样的方法可以测试代码可行性.软件测试这个行业对于女生来说是一个比较好的职业,不需要有强大的敲代码基础,需要的是细心和观察力.如果对于软件测试有兴趣就应该看看构建之法这本书,构建之法这本书的好首先就在于这是一本全景式的图书,能让你更了解这个软件行业.可以让人从陌生变熟悉,所以这本书是不错的.其次,这是一本实践式的书,涵盖了科学软件开展的每个方面,不单单只是实践,理论的东西也很重要.我们中国

3137102413_张其仁_构建之法读后感

通过对<构建之法>这本书的阅读,最大的感受就是软件工程原来还可以这么学的.以前写程序最多只会考虑到数据结构和算法方面的知识,只关心程序是不是可用的,实际是不是可运行的.但是现在发现那样的程序写出来是毫无价值的 .首先,软件工程不仅仅就只是涉及到计算机或者软件方面的知识,相反,软件工程涉及了很对其他学科的知识,比如:管理学.数学.工业设计等等学科,一个合格的软件开发人员如果只是懂得怎样去写程序,那么仅仅只是初级阶段,更高级的应该是从一个更加高级的层面上去考虑更多的东西,如整个软件的架构.感谢构建

构建之法读后感part7

这个星期我看到了构建之法的第七章,第七章介绍了微软推荐的软件开发方法MSF. MSF的最大特性是商业化,并一直体现在项目的实施过程中.所谓商业化意味着客户的商业利益.客户 投入多少,得到多少回报,客户要用到哪些最新的技术,最后如何把项目计划变成产品直至产生效益, 等等,这些都是MSF要考虑的问题.我认为MSF的基本原则,不仅符和软件开发流程,而且也也可以应 用到平时生活和学习.如学习所有的经验,学习他人经验及自己的过去的经验,反思错误,才会获取到知识.

构建之法读后感part4

本周读完了构建之法的第四章,本章内容主要是讲"两人合作",有一句话众所周知"三个臭皮匠赛过诸葛亮",无论是从事什么活动或者工作,合作的力量总是1+1>2 软件开发的过程是复杂的,显然的一个人的智慧是不够的,遇到问题一起解决,工作一起分担能使开发的效率提高很多.以后到公司团队工作,合作很大程度上实现优势互补,比如说有人擅长界面设计,有人擅长实现功能,这样的合作能减少工作量提高整个开发效率.有些人技术很好,可是在沟通这方面十分欠缺,这是很不利于合作的,在项目的开发