阅读《构建之法》

在邹老师来学校讲课时,我便花了2个晚上在图书馆看到一半了,那就先遵循国内的现象,只看结果不看过程,直接上内容。

第一章:

在阅读完第一章只有一个困惑那就是:1.怎样才算是一名合格的工程师?

第二章:

第二章的问题有较多。

1.单元测试要快,既然要快,那同时单元测试要测试API中每个方法以及每个参数,而且同时还要覆盖所有代码路径,那无疑会增加大量程序代码,如何做到快?(章节2.1.2)

2.学生毕业到走向社会成为职业程序员,这过程需要时间,而且国内的程序员又有一个35岁危机,那我们该如何对待?提前转行向管理或者其他方面?(2.3)

3.回归测试要怎样实现?而且还需要自动化?老师一直未讲过相关知识,这与社会发展趋向会不会背道而驰?

第三章:

1.  一个能力出众的程序员要如何融入到团队中去?而不是会被团队排外,不积极就会被看轻,而积极又会被误会抢风头,完全是因为国内环境导致吗?(章节3.2)

2.在3.2节的软件工程师的职业发展中,提到考级,而在社会工作中,实践经验比证书更重要,要是在大学期间就接受这种固定性思维成长,在将来工作中岂不是会影响到以后的工作模式的创新吗?

第四章:

1. 老师上课讲的注释三载代码后面加2个斜杠直接中文解释,更甚的是连变量都要加中文注释,,与4.2.9节中所讲的注释很不一样,那我们该如何选择?应付老师又有可能让这种行为将变为习惯。

2. 结对编程目的是相互监督,更好地开发,但我们在实验过程中却反而不是怎样,而是更容易被队员带入误途而越走越远,还远不如分模块写效率更高,时间更快,结对编程反而更费时,为何还要推行这个方法?(4.5.2)

第五章:

1.  在5.3节的开发流程中,个人或者是小组中,大多都是使用写了再改模式,这也可以更快完成,在前面也提到要降低任务交付时间的标准差,这也能更符合,为何不提倡,而只说对实际用户,解决实际需求来说缺点太大?在团队中,写实际软件过程中,更多的也是分模块来写,并想不出有何缺点。

第七章:

在7.2.5中说商业项目要重视市场和用户,技术三第三位,当然这本就是商业在前面,但是没有高深的技术支持如何能更好让项目顺利完成,让用户体验一流的服务,在各种创业大赛中,所谓的商业项目也是来自于一个好想法好点子,难道这不更应该需要技术去实现吗?(顺提第六章的敏捷流程,看完后云里雾里,不懂,是我没抓到核心思路还是因为其他?)。

时间: 2024-11-11 20:11:31

阅读《构建之法》的相关文章

《UML基础及应用案例》阅读

<UML基础及应用案例>这本书读了大半了,记住的东西很少,感觉书本有点冗余,但是因为想要了解关于UML(Unified Modeling Language ,统一建模语言)的最基础知识,所以还是硬着头皮看了一遍,把目录用思维导图软件列了出来. 到目前为止,脑子里还是一团乱麻,图的种类太多,关系也很多,目前没有比较好的方法把它们记住.专门下了个StarUML软件,打算一步一步边做边学. 先搜了一些关于UML的基础知识: 在UML类图中,常见的有以下几种关系: 泛化(Generalization)

UML基础与应用总结

      敲响一段键盘的乐响曲,一段路程留下一些足迹.       UML.是Unified-Modeling-Language的缩写. 首先要明白知道它是一种可视化的建模语言.   什么是UML基础与应用?简言之.就是UML描写叙述一个系统的静态结构和动态行为,从不同的角度为系统建模并形成系统的不同视图.用图形的方式表现典型的面向对象系统的整个结构:应用便是UML及九种图在系统中的运用.       用一张图来说,例如以下:       UML,是面向对象的可视化建模语言.所以,学习UML,

UML基础知识

(这个是很久以前写的一篇关于UML的文章,现在放出来和大家共享) 了解一下类与类之间的关联基础知识很有必要,因为这些关系就像我们建造房子的基石,是面向对向编程的基础. 类中的关系有六种,分别是关联(Association)关系.聚合(Aggregation)关系.组合(Composition)关系.泛化(Generalization)关系.实现(Realization)关系以及依赖(Dependency)关系,下面分别介绍这六种关系. 依赖(Dependency)关系 依赖是对象之间最弱的一种关

UML基础

UML基础系列:类图 类图描述系统中类的静态结构,它不仅定义系统中的类,描述类之间的联系,如关联.依赖.聚合等,还包括类的内部结构(类的属性和操作).类图描述的是静态关系,在系统的整个生命周期中都是有效的.对象图是类图的实例,它们的不同之处在于对象图显示类图的多个对象实例,而不是实际的类.由于对象存在生命周期,所以对象图只能在系统某一时间存在. 1. 类图概述 类图(Class Diagram)是描述类.接口.协作以及它们之间关系的图,用来显示系统中各个类的静态结构.类图是一种模型类型,一种静态

UML基础概念(转)

UML基础概念 UML概述 uml简介 uml(unified Modeling Language )为面向对象软件设计提供统一的.标准的.可视化的建模语言.适用于描述以用例为驱动,以体系结构为中心的软件设计的全过程. uml的定义包括UML语义和UML表示法两个部分. (1)UML语义:UML对语义的描述使开发者能在语义上取得一致认识,消除因人而异的表示方法造成的影响. (2)UML表示法:UML表示法定义UML符号的表示法,为开发者或者开发工具使用这些图形符号和文本语法为系统建模提供了标准.

接口测试基础以及postman案例实战

接口测试基础以及postman案例实战 接口测试 1.就是功能测试; 2.对于咱们班来说测的都是程序对外的接口 3.接口其实就是各种操作数据库 前端(客户端包括客户后台)       后端(服务器端) 前端一般使用(html/css/js等语言开发)     后端一般使用(java/php/python等语言开发)因为语言不通so通过接口来进行交互 接口返回的数据都是通用的数据类型:json类型(所有语言都可以解析) 接口测试 必须有接口文档:(注意参数之间拼接是英文格式填写) 1.url 2.

UML基础—结构和组成

本文主要梳理了一下UML2中的各个图的逻辑划分,UML基础知识. 一.UML2的4个规范 二.UML2的13种模型图 分为3大类:行为视图.交互视图.结构视图 三.UML1和UML2各种视图对照 四.UML图应用 在软件系统的,需求分析.设计.实现中,可以作为标准化的图形建模工具,帮助系统分析人员.软件设计人员.开发人员等,更好的沟通交流. 示例: Donate捐赠 如果我的文章帮助了你,可以赞赏我 1 元,让我继续写出更好的内容)     (微信)                       

OOAD利器之UML基础

UML:Unified Modeling Language,即统一建模语言,简单地说就是一种有特殊用处的语言.本文是我初步学习UML的学习笔记,对于我们菜鸟码农来说,让我们做设计的可能性不大,但至少能看懂是必要的. 一.所谓模型 1.1 模型是对现实的简化 模型是提供系统的蓝图,模型可是包括详细计划.也可是是从更高程度考虑系统的总体计划,每个系统可以从不同的方面用不通过的模型来描述.因而每个模型都是在语义上闭合的抽象系统.模型可以是结构性的,强调系统的组织.也可是是行为性的,强调系统的动态方面.

《UML大象》第一阶段阅读总结

全书分为准备篇.基础篇.进阶篇和总结篇四个部分.我的阅读计划分为三个阶段,所以我把最后两个部分列为了一个阶段,在第一阶段我阅读了准备篇. 准备篇讲述面向对象分析的一些基本概念,及学习建模需要了解的一些基本知识. 这些知识在我们之前的学习中都有涉及到,我简单整理了一下. 面向对象是基于一种哲学思想,它认为:客观实体和实体之间的联系构成了现实世界的所有问题,而每一个实体都可以抽象为对象.这种思想尽可能地按照人类认识世界的方法和思维方式来分析和解决问题,使人们分析.设计一个系统的方法尽可能接近认识一个

UML基础:统一建模语言简介

目录 背景知识 用例图 类图 序列图 状态图 活动图 组件图 部署图 结束语 英文原文:UML basics: An introduction to the Unified Modeling Language 到了21世纪——准确地说是2003年,UML已经获得了业界的认同.在我所见过的专业人员的简历中,75%都声称具备UML的知识.然而,在同绝大多数求职人员面谈之后,可以明显地看出他们并不真正了解UML.通常地,他们将UML用作一个术语,或对UML一知半解.大家对UML缺乏理解的这种状况,促进