构建之法浅读

1.“软件工程”和“计算机科学与技术”的区别是什么,事实上我们和计算机科学专业也有好多相同的课程而且这两个专业的就业方向也大体相同,所以二者的区别之处在哪?

2.在实现一个用户所需的软件时,我们往往要尽量减少并尽全力bug的产生,而这些需要对用户需求有详细的分析,包括对将来这类软件发展的趋势的分析。主要功能都有设计文档,源代码完整,有修改记录,并有最后版本。关键模块有可以执行的单元测试、压力测试脚本,等等那是否意味着我们在学习过程中更应该注重软件分析。

3.结对编程中,二人所长不同,单纯采取交替执行“驾驶/领航”的工作方式是否影响效率?

4.完成一个项目,需要一个成功的团队。一个人的能力有限,一个公司开发一个大项目,要如何才能让一个软件团队有条不紊等工作,他们之间如何分工,如何把所有人所负责的部分整合成一个项目?

5.合格的软件工程师,有什么具体的标准吗?还是说能写代码,又能发现问题解决问题就可以成为了呢?我们现阶段可以从哪方面开始培养自己的开发思维和能力,开始向一名工程师迈进?

6.有的软件企业不但免费,而且连源代码也一并奉送,但是要求获得源代码的开发人员遵守某种约定,我不明白对于这种软件企业它们怎样盈利?还是说他们就只是提供一种免费服务来获取开发人员使用度从而提升企业知名度。

时间: 2024-08-02 00:30:52

构建之法浅读的相关文章

《构建之法》读第六、第七章有感

<构建之法>读第六.第七章有感 第六章: 第六章主要详细介绍了敏捷流程,在软件工程范畴里,“敏捷流程”是一系列价值观和方法论的集合.这一章以敏捷流程的Scrum方法论而展开,Scrum 采用迭代.增量的方法来优化可预见性并控制风险,并且SCRUM 是一个用于开发和维持复杂产品的框架. 敏捷开发的流程如下: 1.找出完成产品需要做的事情,每一项工作用天为单位计算. 2.决定当前的冲刺(Sprint)需要解决的事情--Sprint Backlog. 3.冲刺阶段各个团队相互独立,所有的问题都只能在

《构建之法》读后心得,问题

我觉得构建之法这本很不错,书的内容给我一种欢快的阅读体会,能让人更加的快速去接受里面的内容,并吸收为自己所用:并且里面的内容都举例生活中的例子,并且在一些容易有疑惑的地方,以问答形式解答,而且语言通熟易懂,使人看上去更加的了解其实软件工程就在我们的身边. 之前上过软件工程这门课程,那本软件工程的书本不像<构建之法>,都是一些很枯燥乏味的内容,并没有像<构建之法>让人舒适,让人以一种欢快的阅读体会.其实软件工程就是包括了“开发.运营.维护软件的过程中的很多技术.做法.习惯和思想.软件

构建之法粗读读后感_1

通过粗略的阅读<现代软件工程构建之法>,使我对于这本书有了初步的认识. 本书共分十七章,内容层次分明,很多知识点通过几个小点列出.书中用角色之间的对话来揭示一个概念的本质.使得我这种菜鸟也能很容易理解一些道理.本书有关于单元测试的简要介绍,关于个人开发的流程,两人合作的代码规范和审查,团队的模式和开发流程,还有软件的分析和设计方法,软件各种的测试方法,运用的测试工具等等.就我目前的能力几乎是啥也理解不了,但是还是有很多可以使我们可以细细品味的. 从本文目录来细细体会下的本书的结构.第一章,其实

《构建之法》读后

  简略通读了一遍<构建之法>,感觉很像和一个老朋友聊天,讲述职业道路.职业方法.专业技能方法,讲述社会,教导做人……. 首先,讲到了开发过程中核心——个人技能培养,然后讲到了应该怎样团体共同解决问题,然后介绍了时下流行的开发方法,实施过程,最后讲述了作为实施过程中的个人素养的培养. 当然由于初略的阅读,有些问题没有很明白,以后我会认真阅读,理解每个环节的问题. 问题一: 我所理解的软件工程,是使用计算机语言,编写一个实用的软件,以及让软件安全.流畅运行的过程.与盖房子流程一样,只是使用的工具

《构建之法》读后之思

一.前言 不同于以往的解决问题,这次是需要阅读,自己思考来提出问题.经过阅读书上的部分内容,再结合一年半以来的大学经历,我也清楚地认识到了,它并不是我想象中的那么单纯的以代码去实现一切.正如专业的名称,完成软件开发就应该像是完成一项"工程",需要分析设计构建维护等.书中的介绍使我对软件工程又有新的认识,但是在经过阅读后所获得的又一轮新的认知中,又有些许不太清楚,或许也有些不敢苟同的地方.关于个人主观提出问题,如下. 二.关于问题 第1章   概论: "软件工程是把系统的.有序

《构建之法》读第四、十七章收获

第四章 两人合作 读了第四章,我才意识到代码规范的重要性,代码不仅要自己看懂,也要能让别人看懂,代码规范能使团队合作更好的进行.代码规范分为代码风格规范和代码设计规范.其中代码风格规范要注意缩进.行宽.括号.断行与空白的{}行.分行.命名.下划线.大小写.注释等问题. 问题一.命名法 文中关于命名这一注意事项,作者向我们详细介绍了"匈牙利命名法".基本原则是:变量名=属性+类型+对象描述那还有没有其他的命名方式呢? 1. Java变量的基本命名法则: a)   以下划线.字母.美元符开

《构建之法》读感-03

今天我阅读的是第四章关于双人合作的种种. 对合作项目来说,代码规范是很重要的一点,代码不仅仅是给机器看的,更是要给人看的,机器编译代码,只要没有语法错误,无论你格式再纷乱无章,也能正常运行,但如果要是交给队伍里其他成员看,那估计会让人产生一种打人的冲动了. 书中描述的代码规范有几个很重要的点.代码风格,简明,易读,无二义性,各家有各家的风格,但核心还是围绕“简明易读”来的.如缩进4字符,100字符行宽,括号的断行简明,大小写,变量函数的命名等等.同时注释也是特别重要的一点,自己的程序不写注释过一

软件工程——《构建之法》读后困惑

通过一周多对这本新书的快速阅读,发现自己存在很大的问题, 如下: 一.软件工程这门课与JAVA,C++等这些面向对象程序设计应该怎样对接起来? 二.软件工程这门课,除了在上课的时候认真跟着老师的思路走,课后空闲时间,我们该怎样单独,或者在团队里怎么学习? 三.提高我们这门课的能力是通过敲代码,还是提高自己的逻辑思维能力? 四.在即将到来的人工智能时代,软件工程师这个职业是否能一直活下去?

《构建之法》读感-01

从第一章概论中提到,软件工程要创作足够好的软件. 而有一些同学认为,所谓好软件,就是没有Bug的软件,所谓软件工程,就是把软件中的Bug都消灭掉的过程,这确实抓住了软件工程中的一个要素,和软件打交道的专业人士都知道软件有Bug,软件团队的很多人都整体和Bug打交道,Bug的多少可以直接衡量一个软件的开发效率.用户满意度.可靠性和可维护性.——p15 而什么是Bug呢?书中明确提出,就是软件的行为和用户期望度不一致,当一个软件被使用时,用户希望软件可以流畅运行并且不崩溃,但这时软件因为不知名的原因