读书笔记——读《构建之法：现代软件工程》第13~17章

读<构建之法>第4,17章有感 第四章:两人合作 原文:另外,注释(包括所有的源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性. 我的问题和看法:对于英语水平没有那么高的人来说,不允许中文注释真的太难了.刚开始学习代码的时候,老师就教导我们编程的时候一定要写注释,但是并没有非常严格的要求我们必须要用ASCII字符.我上网查找了一些资料,发现大部分公司对于注释并没有明确的要求.注释是为了方便让别人理解你的代码的,所以简洁易懂应该才是最重要的,在水平达到的情

    诗云:半亩方塘一鉴开,天光云影共徘徊.问渠哪得清如许?为有源头活水来. 这是宋代理学大家朱熹对阅读一本好书的感受.这几天我看了邹欣老师写的<构建之法>第4.17章之后,产生了一点点类似的感受.下面我来点评一下. 关于"第4章 两人合作"的点评: 问题一: 原文(见第68页):另外,注释(包括所有源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性. 个人见解:可移植性是指代码在不同平台能否执行.注释会被执行吗?不会.那么,注释就与

读构建之法有感: 今天在实验室读了构建之法书的第4章-两人合作,书上首先讲代码规范,一个程序员写的代码主要个人看,而在给人看的前提是要代码规范. 对我个人而言,其实看到没有规范的代码是看不下去的,自己曾经也犯过代码不规范的毛病,以后这种毛病要改掉. 下面说说结对编程,结对编程有如下的好处: 1.在开发层次,结对编程能提供很好的设计质量,两个人解决问题的能力更强. 2.对开发人员自身来说,能带来自信. 3.在企业管理层次上,有效的交流可以更好地应对人员的流动. 结对编程可以不断的进行复审,可以避免

构建之法读书笔记 #wmd-preview h1 { color: #0077bb } 构建之法读书笔记 沈三景 PB15061249 软件工程 读书笔记 前言 本周阅读了构建之法的四.五两个个章节.这三个章节主要讲述了代码规范.结对编程.团队模式.开发流程. 第四章 两人合作 首先提到的是代码规范,程序员写的代码不仅要给机器看,还要给人看.好的代码规范能事半功倍.代码规范有分为代码风格规范和代码设计规范.代码风格规范是指让代码保持简明,让代码更易读.书中给出的规范是Tab键为4个空格,行宽为1

构建之法读书笔记 #wmd-preview h1 { color: #0077bb } 构建之法读书笔记 沈三景 PB15061249 软件工程 读书笔记 前言 开学前两周,杂事颇多,没有充足的时间阅读<构建之法>,只能每天在睡前阅读约半小时,故只看了前三章.虽如此,但仍收获很多,下面就是我对前四章内容的一些看法和理解,如有理解偏颇之处,望见谅. 第一章 概论 本章主要介绍了软件工程是什么?软件工程的目标是什么?为了解决前一个问题,作者首先提出了两个等式: 程序 = 数据结构 + 算法 软件

谢谢大家能来看我的博客,这是我第一次写博客,大概也会石沉大海吧.但我会逐渐成长,写出更优秀的博客. 那么下面开启正文吧. <构建之法>一书面向初级程序开发者,讲述个人开发.小组开发.团队开发中所要注意到的问题.有助于本学期软工课程的机会,我第一次能够担任一个较大小组(8人)的组长,并带领大家完成自己的小项目.但我深知自身的管理知识是非常贫乏的,又因本书章节很多,所以我特别挑选了几个章节借鉴经验,并且遴选了最有意义的两个章节将精华部分记录下来与大家分享. 第5章团队和流程 团队模式问题是由人数渐

第八章.需求分析 书中介绍了一些获取需求的常用方法.流程.及分析框架,看了后才发现原来需求分析还有着者这么多的学问. 以前听人说,需求分析在实际项目开发中所占分量很重,甚至往往需要花的精力比敲代码要多.我听到时不以为然 ,认为需求分析不就是看一下软件要什么功能,要做成什么样而已吗.再后来,我真的接手了一个小商业项目的需 求分析任务,才明白需求分析是一件多么让人崩溃的事情,客户对软件编程一无所知,只是含糊地给我一些文档, 而我又不清楚他们的业内流程.业内术语等,不知道如何去获取对需求,只能像只无头

第五章--团队和流程      在第五章的团队和流程中,团队有共同的特点:团队有一致的集体目标,团队要一起完成目标.一个团队的成员不一定要同时工作,团队成员有各自的分工,互相依赖合作,共同完成任务.软件团队也有不同的模式.很多软件公司的团队最后都演变成功能团队,简而言之,就是具备不同能力的同事们平等协作,共同完成一个功能.在这个功能完成之后,这些人又重新组织,和别的角色一起去完成下一个功能.他们之间没有管理和被管理的关系.大型软件公司里的不少团队都是采用这种模式.小组内的交流比较频繁.我们在开发

MSF九大原则: 1. 推动信息共享与沟通:"谐",Alert 2. 为共同的远景而工作:目标明确-用户/老板 3. 充分授权和信任: 4. 各司其职,对项目共同负责: 5. 交付增量的价值: 6. 保持敏捷,预期和适应变化: 7. 投资质量: 8. 学习所有的经验: 9. 与顾客合作: MSF团队模型定义了小组同级成员的角色和职责:用户体验.产品管理.项目管理.开发.发布管理.测试.我惊讶地发现,在分配职责时"用户体验"显然不是一项团队的开发活动,MSF使用了&q

第六章--敏捷流程 1.      这一小节中有一个图表,对比了敏捷(Agile).计划驱动(Plan-driven).形式化的开发方法(Formal Method)的适用范围.里面提到的形式化的开发方法,其基本步骤是怎样的呢?为什么它能有极高的可靠性呢?下面是一些关于形式化方法特点的说明,从中可以看出它能力的缘由. 形式化方法建立在严格的数学基础上,其目标是希望能使系统具有较高的可信度和正确性,并能使系统具有良好的结构,使其易维护,关键是能较好地满足用户需求."形式化方法"一词虽然一