构建之法 05

从上次作业中我了解到了结对合作的好处,当自已出现一点小错误时,同伴的一句提醒,让我更加的谨慎,弥补了个人的不足,而在结对中也遇到了一些问题,出现矛盾时,怎样才能配合好对方做出更好的选择?

4.1大节提到的代码规范,我们编写代码时要注重代码风格规范和代码设计规范,无论是类名,对象名,缩进还是行宽什么的,在结对子编程时都要有所规定,不然到后面出现的类或是对象多了,就很容易混乱,分不清楚谁是谁。要学会封装,编写函数,将功能模块具体化,减少主方法里面的代码,避免大规模的出错。

4.4中提到了代码复审,在平时编程程序时,我也会从头到尾的查看自己的代码,运行程序,若是多次结果相同,无误就可以了。没有想过发现代码错误外,还去思考逻辑是否有误,算法够不够优化等其他问题。他人能否觉得我所编写的程序是否简单易懂,能否从中学习。

4.5结对编程,两人合作,一同思考一同编写程序,有利于提高效率,相互学习。所以要学会4.6节提到的合作的不同阶段和技巧,一开始探索项目时,中途遇上不可解决问题时,后期简单的复查时,可以独立思考,期间思路清晰,沟通良好时,一起结对编写,加强合作。在合作中在客观全面的对待自己的结对伙伴,懂得相互鼓励,相互学习。

在我们平时的编程当中,如果遇到一个非常难解决的问题(困难到对该项目产生厌烦的态度),那么你势必会希望录求帮助,无论是从信息量庞大的网上,还是从身边的技术大师那里,你都会努力去解决(前提是你有对计算机知识的热爱)。这个时候不妨采用结对编程试一下,其它的不说,可能感觉就不同。其实结对编程坐起来很简单也很有趣,找个水平差的不太远的程序员和自己配成一对。只用一台计算机,大家选一个人坐在键盘前面负责输入,另一个人坐在后面口述。当然两个人要不断的交流。

时间: 2024-08-03 15:25:52

构建之法 05的相关文章

构建之法05

第11章:软件设计与实现 设计方法: 分析和设计方法:分析用户需求,根据用户的需求对软件进行设计 图形建模和分析方法:利用图形模型对软件进行分析. 日常管理: 我们在编程时,经常被一些“随机”出现的事情所打扰,最终能够编程的时间只有十分之二三.我们需要分配好我们的时间,使编程的时间尽可能的去增加 第十二章:用户体验 对于一个软件,我们应该站在用户的立场上去使用它,不能仅仅只做到能够运行,还需要做到能够让用户更方便快捷的使用.只有这样,才有人会用我们的软件. 第十三章:软件测试: 我们需要利用不同

构建之法阅读笔记05

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

阅读《构建之法》P384~391

通过阅读<构建之法>P384~391以及参考阅读杜老师给出的链接,得出一个重要的结论:软件工程师的职业道德至关重要. 软件工程的动态性和需求的前后关系,要求一个规范能对出现的新情形有较强的适应性和适用性.但是即使在这种一般性原则下,本规范也只对那些以文档记录职业道德态度并采取积极行动的软件工程师提供支持:即提供相应开发组中的个人以及整个开发组都可以求助的道德基础.本规范也帮助定义哪些是对软件工程师提出的道德上不适当的要求. 原则1  公众 软件工程师的行为应与公众的利益一致. 原则2  客户与

回望来时的路:构建之法东北师大站 2016春季学期

1.  前因 微软邹欣老师著有<构建之法:现代软件工程>[https://book.douban.com/subject/26577755/].第一版首版以前,我还不知道邹老师是哪一位,就在网上曾经看到过有人转引他的观点,感到说得太有道理了,一拍大腿的感觉.比如他提到教师和学生之间应该是健身教练和学员间的关系,不是教师带领学生参观浏览,也不是狱警和囚徒的关系.比如他批评没有代码量的软件工程教学.<构建之法>到手,第一遍粗读我花了一周的时间,酣畅淋漓.很多处让你再拍大腿,"

2018-2019-1 20189221 《构建之法》第一周学习总结

2018-2019-1 20189221 <构建之法>第1周学习总结 教材学习内容总结 第 1 章 概论 理论和知识点: 计算机科学的领域,软件工程与计算机科学的关系,软件的特性,软件工程的定义与组成部分 1.1 软件 = 程序 + 软件工程 程序 = 数据结构 + 算法 简单的应用程序--->满足各种功能的应用软件--->保证服务质量的软件服务 软件工程的要求质量保证.用户体验.国际化和本地化 软件工程的工作有源代码管理.配置管理.软件项目的管理.需求分析.软件测试.程序理解.软

构建之法——读书笔记(8)

<构建之法>第十&十一章 主要讲述了在软件设计前期的需求分析问题上的方法和实践经验,分为"典型用户和场景"以及"软件设计与实现". 其中第十章大部分内容包含: 用户的分类(典型用户可以包括以下内容: 1. 名字(越自然越好) 2. 年龄(不同年龄和收入的用户有不同的需求) 3. 收入 4. 代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要 5. 使用这个软件的典型场景 6. 使用本软件/服务的

《构建之法阅读笔记02》

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

简读《构建之法》,所想问题展示

1,<构建之法>这本书全局语言通俗,学生很容易读懂,但是存在一个隐患:学过软件工程,我们只是笼统的理解,而对这方面的专业知识很少了解,该怎么办? 2,书中提到的软件结构,软件设计与实现具体是怎样的?怎么理解它们之间的关系? 3,软件在不断更新和增加功能的负担下,一定程度下会崩溃.若有一个软件,即将考虑添加下一个功能,但是在添加这个功能之后,系统一定会崩溃,但是这个功能对这个软件的市场前景起着至关重要的作用,这是该怎么办? 4,软件设计和软件构建有区别吗?不同之处是什么? 5,当软件中的依赖关系

《构建之法》学习(5)——团队和流程

<构建之法>学习(5)--团队和流程 1.非团队和团队   团队共同的特点: 团队有一致的集体目标,团队要一起完成这目标 团队成员有各自的分工,互相依赖合作,共同完成任务 2.软件团队的模式       一窝蜂模式       主治医师模式 有首席程序员,他/她负责处理主要模块的设计和编码,其他成员从各种角度支持他/她的工作.       明星模式 主治医师模式运用到极点,可以蜕化为明星模式,在这里,明星的光芒盖过了团队其他人的总和.       社区模式 社区由很多志愿者参与,每个人参与自己