通读构建之法提出五个问题

我是通过`软件工程课`认识这本书的。老师要求读一遍构建之法。自己偷懒,其实没读完,大致翻了翻。翻看粗读后,初步有一下感受:

1. 这不是一本传统的教材,没那么多晦涩的概念。

2. 排版挺好看的,文章穿插图表,很精致。

3.语言幽默好懂。

在没读此书之前,只是觉得为什么软件工程里还会有这么多方法,软件工程不就是一些人合作做个项目就好了嘛?但现实远远没有想象的那么简单。《构建之法》一书一共有17章。每个章节讲述不同的重点。构建之法的每一章都是独立的子章节,并且涵盖了测试、项目经理、开发人员、用户体验等多个方面。个人来说比较喜欢这种风格,可以在合适的时候随时温习自己想看的一部分。即使本书涵盖软件工程很多领域,但每一章都值得精读。每个章节最后的练习与讨论是一堂丰富的扩展课也是非常有必要的。在读过此书之后产生一下五个问题:

1、关于单元测试的自动化。

大家都喜欢在写代码时能够确定自己原来写的东西没有错误,所以单元测试确实在开发中起到很是吸引人,但是单元测试又确实很是繁琐。那么这里所谓的单元测试“自动化”,其自动化是针对哪些方面?

2、关于项目设计与开发速度上的问题。

设计到怎样的程度有利于能够提高开发的速度,是否存在某些设计需要在实践中考察后才能判断优劣的情况?

3、关于软件工程师成长方面的问题。

书中有提到很多关于软件工程师资格认证的内容,那么一个优秀的软件工程师应该有怎样的习惯和精神素养呢?

4、关于敏捷流程。

现实的开发过程中往往会比理论中多出很多问题,比如需要如何能够将需求细化到任务,然后在细化到设计,最终使得能够在规定的时间内有条不紊的完成目标?

5、关于优化。

如果最后做性能分析的时候发现的性能问题造成的原因是前期一个隐藏在很深地方的不妥当架构造成的,这个时候该如何取舍?

总而言之,构建之法是一本产生于实践并应用于实践的书,比现在很多只讲框架不讲细节,只讲理论的软件工程理论书棒得多。强力推荐。。。

时间: 2024-10-25 21:24:47

通读构建之法提出五个问题的相关文章

构建之法第五章学习

今天我学习了<构建之法>第五章 团队和流程.首先我了解了写了再改模式(Code-and-Fix) 史蒂夫·迈克康奈尔(Steve McConnell)在这里提到了不少开发流程.第一个提到的开发流程.这个流程也有好处,不需要太多其他准备或相关知识,大家上来就写代码,也许就能写出来,写不出来就改,也许能改好.当面临下面的任务时,也许这个方法是有用的.但是,要写一个有实际用户.解决实际需求的软件,这个方法的缺点就太大了. 然后我学习了瀑布模型 当软件行业还在年幼的时期,它从别的成熟行业(硬件设计,建

构建之法 第五次心得

构建之法9.10.11章 第九章 学习了第九章之后,了解到了在一个项目中项目经理的重要性.生活中,无论什么团队工作,都需要一个领队,来掌控团队项目的发展,以及各个成员工作的分配.PM指Product Manager.Project Manager.Program Manager.这个章节主要讲了Project Manager即项目经理,PM要凭自己的能力,把用户的需求展现成其他成员能够理解和执行的语言.项目经理需要正确地协调团队内部外部,调配各部门资源和时间,有效进行风险管理,保证一个项目顺利按

构建之法第五篇阅读笔记

今天将构建之法剩下的阅读完了,主要讲述如何组队一起设计一款软件软件设计与实现过程中,着实有这么一句话:在理论上,理论和实践是一回事:在实践上,理论与实践却是两回事.若是只是在理论阶段讨论着实践,就永远不知道想象中的目标实现难度与实际的目标实现难度差距有多么的大.这在课程结对编程中有所体现,也感触颇深,动手前将设计思路商量地基本完美,大多会遇到的问题也都通通解决,然而到了实现环节就出问题了,发现原来之前商量的方法并不可行,还有很多突发的问题没有考虑到……所以,有的程序可以“一拍”即得,有的不行.构

构建之法——第五篇

上一周对于需求分析那一模块的内容还存留一点的疑问,经过一周的学习,弄清楚了以下几个方面. 对于软件需求的类型,以及利益相关者,我们根据不同的角度进行了以下的划分,对产品功能性的需求,对产品开发过程的需求,非功能性需求,综合需求:因此,对于软件产品的利益相关者而言,我们要弄清楚"他们想从软件中得到什么".当获取用户需求以及进行用户调查的时候,我们可以采用焦点小组,深入面谈,卡片分类,用户调查问卷,用户日志研究,人类学调查,眼动跟踪研究,快速原型调研,A/B测试. 竞争性需求分析的框架,根

构建之法第五六章读后感

邹欣老师的这本书,写得形象生动,第五章用体育运动等团队例子引出软件开发团队的形式.软件团队形式多样,适用于不同的人员与需求.团队可能会演变的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式等.开发流程模式有:瀑布模式.瀑布模型的各种变形.统一流程.老板驱动的流程.渐进交付的流程等.在过去的学习生活很少有团队合作的时候,看了本章很期待后续与大家团队合作,肯定会遇到很多困难,但只有把学到的运用到实际,知识才会学得更牢靠. 看

重新回答构建之法的五个问题

问题一:这本书一直在强调合作,我不是很理解这个合作的具体含义,我认为的编程是项目经理安排任务然后每个人只要完成自己的任务就好.所谓的合作我认为的不外乎就是沟通.各种接口对接等等.可能会有会议讨论等等.但是合作是不是就是沟通确实不是很清楚. 答:沟通是信息传递的重要方式,只有通过沟通,信息才能在部门与部门之间.员工与员工之间得以传播.工作的开展在很大程度上来讲,就是通过从上到下的层层沟通采得以进行的.沟通是一个双向的行为,沟通双方一个要善于表达,一个要善于倾听,通过双方沟通.倾听.反馈再沟通.倾听

构建之法的五个问题

问题一:这本书一直在强调合作,我不是很理解这个合作的具体含义,我认为的编程是项目经理安排任务然后每个人只要完成自己的任务就好.所谓的合作我认为的不外乎就是沟通.各种接口对接等等.可能会有会议讨论等等.但是合作是不是就是沟通确实不是很清楚. 问题二:我承认文档的重要性.但是我认为更重要的还是代码的实现程度,也就是代码的复用性.可能这就是菜鸟级选手和软件工程师的区别吧. 问题三:对于一般的程序而言,只要客户要求的,或者客户的需求做到就可以了,那为什么还要做各种各样的测试.在我的主观印象里只要做好基于

现代软件工程构建之法 前五章阅读感想&amp;困惑

第一章 第一节 新时代中国的IT产业市场规则不规范,书中提到社会上有个别软件公司的软件一定要卸载别家公司的软件才能运行,我这里感到疑惑---————是不是说如果 一间软件公司他能做出一个像微软操作系统那样的受大众十分喜爱的软件 那么他就可为所欲为 对一些不友好的软件公司进行屏蔽,从而决定了其他公司的生存??? 第二章 第一节 之第二部分 这里说到程序员作为该单元的开发者 必须亲自写开发单元 但如果遇到上头委派的一件又急又大型的项目 那么还要写单元测试?或者不能让别人写? 第三章 第二节 这里说的

构建之法小结五

本周阅读了第五章,第五章讲了几种软件团队的模式.软件开发流程.第五章用体育运动等团队例子引出软件开发团队的形式.软件团队形式多样,适用于不同的人员与需求.团队可能会演变的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式等.开发流程模式有:瀑布模式.瀑布模型的各种变形.统一流程.老板驱动的流程.渐进交付的流程等.在过去的学习生活很少有团队合作的时候,看了本章很期待后续与大家团队合作,肯定会遇到很多困难,但只有把学到的运用到