构建之法阅读笔记二。

  过了很久,也可以说是有了编写一个软件的经验回来再看构建之法这本书,对于这本理解是不同的。我刚好看到代码复审这里,而且在小组里也可以算是说是承担了代码复审这个模块。与书中说的一样,在单元测试中成功的功能模块,连接到主程序中确实出现着错误。也是这样,我们也反复修改了好多次代码。另一方面就是,我们的界面一开始都是用Windows builder创建,所以还需要后期调整代码规范。但是相对于书上所介绍到的代码复审过程,还缺少了复审标记,审核表部分。可能是因为我们小组交流起来很方便吧。令我惊喜的是,在书中确实找到了关于对于资源释放的问题,也是在代码复审中修复的,对于我们可能算是一种幸运喽。

  我们小组四个人,在前两天的冲刺刚好可以说是结对编程。两个人研究浏览器部分,一起测试,一起修改。而另两个人负责面板按钮添加以及按钮事件和数据库连接部分。对于我们这种小团队,我感觉这种阶段性功能模块分组,功能上的代码到人是相对比较好的结对编程方法了。

  如何正确地给予反馈,这一节里说到了评论人的三种层次1. 最外层:行为和后果2. 中间层:习惯和动机3. 最内层:本质和固有属性。在讲课时我就对这些话深有感触,因为没有工作上的经验,所以感触都是生活中的,但我觉得这也是一种收获。我的感触有时候说活涉及到本质和固有属性却是令人难以接下一句。套用家里人小时候对我常说的一句话:你怎么这么矫情呢。可能除了委屈也没什么可以回答和反驳的吧。

  我点开了章节末注释里的一个超链接,题目是:送给程序员:关于性格内向者的十个误解。我发现这里解释的内向者好像不是我认为的内向者似的,我刚好把误解的人物性格理解成了内向者,难道不是博主自定义的吗?如果不是他说的和我很像,我就信了。看来我得好好去读一读这本书。

时间: 2024-10-09 11:51:13

构建之法阅读笔记二。的相关文章

构建之法--阅读笔记二

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

构建之法阅读笔记二

快到期末了,我想一想老师留的任务,才写了一篇,今天拿起来又看了一部分,看到了有关代码规范这一方面,结合最近老师留的大作业,对此深有体会,谈谈我自己对此的一些看法. 还记得在大一一开始上的第一堂专业课上,教我们c++的王辉老师就说过,想要做一名合格的工程师,代码规范是基础中的基础,但是在当时我相信大多数人包括我自己都是左耳朵进右耳朵出,根本没在意,虽然在以后的课上老师也会时常提醒我们,可是,感觉也没什么效果,现在的我回想起那时对代码规范的理解,简直那啥...当时的我自以为代码规范不就是形成自己的写

构建之法阅读笔记三—结对编程

构建之法阅读笔记三——结对编程 何谓结对编程,结对编程就是程序员肩并肩,平等的,互补的进行开发工作,他们使用同一台电脑,编写同样的程序,一起分析,一起设计,一块交流想法. 然而我以前却并不是这样做的,我以前喜欢在没人打扰的环境下写代码,我觉得有人在我身边看着,会影响我的思路,还有我个人自尊心比较强,不太喜欢被人指指点点,所以每次都是,我写完代码之后,自己先找自己的bug,每当自己实在找不到之后,才会请教大神,但是有时候可能由于自己的能力不足,往往一个很简单的问题,我自己发现就会花费很久的时间,让

构建之法阅读笔记四—团队开发

构建之法阅读笔记—团队开发 软件开发过程中有团队和非团队之分.其区别就在于目标利益的不同,团队中每个人的目标是一致的.共同的,会根据实际情况给每个人分配不同的任务,不会计较个人利益的得失.非团队每个人的目标都是不同的,大家都为自己的利益而奋斗. 在阅读了构建之法后,我了解到团队开发有以下的特点:1.团队开发有一致的集体目标,团队要完成这个目标.一个团队成员不一定要同时工作.2.团队成员有各自的分工,互相依赖合作,共同完成任务.还有完成一个项目开发的工作流有业务建模,需求,分析和设计,实现,测试,

构建之法阅读笔记6--敏捷开发2

构建之法阅读笔记—敏捷开发2 敏捷开发并不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发:而这种开发方式的主要驱动核心是人:它采用的是迭代式开发:敏捷开发并不是瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据:而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心.而所谓的迭代开

03构建之法阅读笔记之一

构建之法阅读笔记03 遇到问题总是想弄清楚所有细节.所有依赖关系之后再动手,想的太多,没法前进,分析的就会出现错乱,或者直接动手,慢慢发现偏离的一开始的轨道,忘记了目标,这样就会产生"分析麻痹"和"不分主次,想解决所有问题",以后遇到问题应该时刻记住自己的目标,在解决问题的时候不断提醒自己,应该如何思考.越早对自己有一个清晰的定位,对自己越好,很多人只是把软件工程师当成一个工作,当成一个能挣钱养家的营生,而我想把它的当成自己投身的事业,把软件项目相关的目标作为长期的

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

构建之法阅读笔记05

2017.5.20 今天阅读的是<构建之法>第8章需求分析的阅读笔记,我们如果要开始做一个软件,最先要进行的就是需求分析,我们应该充分的了解我们这个软件是否具有前景,我们为用户提供的服务是不是用户所需要的,这一章详细的叙述了如何进行需求分析. 首先是获取和引导需求,我们应该找到软件的利益相关者,了解挖掘他们对软件的需求,引导他们表达出真实的需求.然后分析和定义需求,对各个方面的需求进行规整,定义需求内涵,从各个角度将需求量化,然后估计实现这些需求所需要的时间和资源,确定各个需求的优先级.紧接着

构建之法阅读笔记(4)

这周通过阅读构建之法,知道了MSF的原则,团队模型,开发模式. 基本原则: 1.推动信息共享与沟通 2.为共同的远景二=而工作 3.充分授权和信任 4.各司其职,对项目共同负责 5.交付增量的价值 6.保持敏捷,预期和适应变化 7.投资质量 8.学习所有经验 9.与顾客合作 MSF基于一组工作模型,这组模型是由微软公司及其合作伙伴,在与客户成功开发分布式计算和客户服务器应用程序的经验得来的. 简而言之,一个项目要达到的目标很多,MSF团队模型让不同的角色实现这些目标,在一个项目结束时,每个角色都