速读《构建之法(第三版)》20199319

fanxiaonan fanxiaonan     2023-05-06     531

关键词:

本周速读了《构建之法(第三版)》,本书共有十七个章节(如下图所示),介绍了软件工程的方方面面,干货满满。在速读完成后我思考了以下几个问题。
技术图片

1、目前流行的几种源程序版本管理软件和项目管理软件各有什么优缺点?

  • Microsoft TFS
    微软的团队代码管理服务平台Team Foundation(通常记作“TFS”)是一种为 Microsoft产品提供源代码管理、数据收集、报告和项目跟踪,而为协作软件开发的项目。
    • 优点:TFS功能非常强大。微软对于个人或小团队推出了免费的TFS Express版,功能齐全,主要提供如下功能:源代码管理、工作项跟踪、自动化生成、敏捷任务版。
    • 缺点:搭建、维护TFS比较复杂,硬件要求也比较高。个人用起来一般也就主要用其源码管理功能。
  • Github
    GitHub是基于git实现的代码托管。git可能是目前最好用的版本控制系统了,非常受欢迎。
    • 优点:GitHub可以免费使用,并且快速稳定。 适合分布式开发,强调个体;任意两个开发者之间可以很容易的解决冲突;离线工作,管理代码成本低,不需要依赖服务器;部署方便,基本上下个命令就可以用;良好的分支机制,可以让主干代码保持干净。Git对程序源代码进行差异化的版本管理,代码库占极少的空间。易于代码的分支化管理。
    • 缺点:代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。不支持中文,图形界面支持差,使用难度大。
  • Trac:
    Trac是一个为软件开发项目需要而集成了Wiki和问题跟踪管理系统的应用平台,是一个开源软件应用。
    • 优点:Trac以简单的方式建立了一个软件项目管理的Web应用,以帮助开发人员更好地写出高质量的软件。Trac有良好的扩充性。
    • 缺点:不支持多项目;中文化不完整,不显示中文名,本地化做得不够好;核心功能很少,需要安装很多插件。
  • BUGZILLA:
    Bugzilla 是一个开源的缺陷跟踪系统,它可以管理软件开发中缺陷的提交(new)、修复(resolve)、关闭(close)等整个生命周期。
    • 优点:BUGZILLA不收费,有中文版支持;具有强大的检索功能以及完备的产品分类方案和细致的安全策略;用户界面友好;版本间向下兼容。
    • 缺点:BUGZILLA只能管理缺陷。
  • Apple XCode:
    Xcode是苹果公司向开发人员提供的集成开发环境(非开源),用于开发Mac OS X、iOS的应用程序。
    • 优点: 编译速度极快,操作起来比较快速和轻松; 支持开发人员使用 C、C++、AppleScript 和 Java等多种语言。
    • 缺点:更新版本后,某个插件可能会失效。

2、Coder and Hacker 的区别:

  • Coder:写程序的人
      这种类型的人单纯的只是为了工作、功课、任务而写程序,写程序对他们来说枯燥无味只是获取成绩、金钱的工具,但为了生活,他们继续产出他们的程序码。他们每天的任务只是把事情做到交差了事,他们喜欢简单的任务,最好是一看到就知道要怎么做,最好有开源的程序码可以直接套用,只要他们的程序可以过关。
  • Hacker:有目标而写程序的人
      这种类型的人并不是因为热爱程序本身而开始写程序,他们写程序是为了要达成某些目的。这些人虽然不是天生的程序高手,但是很会用别人写好的套件去兜出一些应用,当有一个好的点子时,他们会去找既有的资源架构,尝试做出原型,并且乐在其中,常常会不眠不休的写程序。他们不会因为一项新产品做起来简单、轻松,工作负担轻而开心 (Coder 会),他们会因为这些东西好用、创新而兴奋不已。

3、 软件开发是一门工程(Engineering), 是一门艺术(Art),还是一门手艺(Craftmanship)?

感觉这是一个各抒己见没有定论的问题。做软件更多是成熟的技术,通用的平台,可控的流程,可预期的结果,从这个角度看本质上是一门工程。但是资深码农经常是以一当十,因为他们在追寻一种工匠精神,经验的积累来自于日复一日不断地读改写思考讨论及领悟,一次次的debug,code review,prototype design等等都在潜移默化地提升着他们思维能力,所以软件开发又像是一门艺术。而对于开发者这又是他们生存的一门手艺。

4、团队模式和团队的开发模式有什么关系?

  • 团队模式是团队内的人如何分工,每个人的职责是什么,软件团队有各种形式,适用于不同的人员和需求。
  • 团队的开发模式是团队如何工作,什么时间应该干什么,一群人在一起做软件开发,总是要有一些方式方法。

这两个应该是相辅相成的,需要思考在项目面前使用哪种团队开发模式,而团队模式更像是一个确定了就一般不会改变的东西,所以需要结合团队内成员的特点来规划确定。

5、如何避免诧异的反应?

当客户对我们的软件不了解的时候我们需要尽量详细的给用户分析说明,而且我们在设计软件的时候也尽量的要考虑用户的感受,从用户的角度去考虑问题。给用户演示一些界面的时候,要说明哪些界面只是示例而已,哪些界面是大家同意的最终设计,总之要尽最大努力达成一致,但是也要从开发的实际情况出发,有事也要对用户说不。

6、如果在团队中有些人经常花很多时间进行“技术研讨”但并没有具体结果或报告,这些人对团队的产品开发和公司的业绩真的有贡献么?

这个问题不能一概而论,要看这些人的技术研讨是否真的是有价值的。如果他在技术研讨中提出的想法给其他人带来了帮助或者激发了新的idea,那么他在无形之中也为团队的产品开发和公司的业绩作出了贡献。如果只是一味的在形式上进行所谓的“技术研讨”,这样不算是作出了贡献。

除此之外还存在两个需要跟大家讨论的问题:

  • 当公司要求你用数据来证明41种蓝色到底哪一种更好,或者为一条边框宽度是3、4或5个像素而争执不休,纷纷表示要拿数据来证明时,你怎么办?
  • 对通用的软件设计思想和软件工程思想的理解这一方面就比较虚,什么是好的软件设计思想?什么是好的软件工程思想?一个工程师开了博客, 转发了很多别人的文章,这算有思想么?另一个工程师坚持做任何设计都要画UML图, 这算有思想么?

《构建之法》(第三版)——邹欣读书笔记

...读书应该是从“薄”->“厚”->"薄",此时完成第一步速读已力有不逮,况细读精读乎?如果知识得不到及时巩固和积累,学习的同时没有留出时间给人思考,学的断片了,那以后重拾此书时又要从头开始,从时间上来讲并不... 查看详情

《构建之法(第三版)》第三章

3.1个人能力的衡量与发展1.软件开发流程不光指团队的流程,还包括个人开发流程。把每个人的工作有序地组织起来,就是团队的流程。“有序”,并不是“无争论”。每个人的工作质量直接影响最终软件的质量。2.初级软件工... 查看详情

《构建之法(第三版)》第一章

...间的依赖关系、编译参数、链接参数等。这些都是软件的构建过程。和软件开发活动(构建管理、源代码管理、软件设计、软件测试、项目管理)用关的内容是软件工程的核心部分,由此推论软件企业=软件+商业模式。程序(算... 查看详情

《构建之法(第三版)》第二章

第二章:个人技术和流程书本内容回顾概述一个团队需要一定的流程来管理开发活动,每个工程师在软件生命周期所做的工作也应该有一个流程,在这一章里会介绍PS(PersonalSoftwarePro-cess,个人软件开发流程)。单元测试单元测试... 查看详情

《构建之法(第三版)》第二章

2.1单元测试1.软件的很多错误来源于程序员对模块功能的误解,疏忽或不了解模块的变化。单元的测试可以让自己负责的模块功能定义尽量明确,模块功能的改变不会影响其他模块,而且模块的质量能得到稳定的、量化的保证。2... 查看详情

《构建之法(第三版)》第四章(代码片段)

4.1代码规范代码规范可以分为两个部分:代码风格规范:主要是文字上的规定代码设计规范:牵扯到程序设计,模块之间的关系,设计模式等方方面面的通用原则。4.2代码风格规范代码风格的原则是简明,易读,无二义性Tab键在... 查看详情

2018--20179215--《构建之法(第三版)》第四章两人合作

构建之法第四章读书笔记4.1代码规范代码规范可以分为两部分:代码风格规范—主要是文字上的规定代码设计规范—牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则4.2代码风格规范代码风格的原则是:简明,... 查看详情

201571030129速读《构建之法》有感

首次接触软件工程这门课程,存在很多疑惑,速读《构建之法》提出了以下5个问题:1、软件工程研究的是什么?怎么样研究?2、一个合格软件工程师的成长需要经历那些过程?3、团队合作的重要性体现在那些方面?4、敏捷流... 查看详情

速读《深入理解计算机系统(第三版)》问题及解决

第一章计算机漫游P13:用户栈和运行时堆有什么区别?数据结构中经常说堆栈,这里的堆和栈一样吗?和操作系统的堆、栈有什么区别?参考:堆和栈的区别(内存和数据结构)操作系统:栈:由操作系统自动分配释放,存放函数的... 查看详情

入坑构建之法

...书。移山之道?emmm,太老了。我经过一番权衡,决定拿构建之法(第三版)这本2017年才再版的书,新书嘛,显得心诚:P然而那个时候,我只知道这是一本讲软件工程的书,以我对之前看过的软件工程的刻板印象以及一些周围 查看详情

《构建之法》第三次

本周着重阅读了《构建之法》的第三章:软件工程师的成长。  软件工程包括了开发、运营、维护软件的过程中的很多技术、做法、习惯和思想。软件工程把这些相关的技术和过程统一到一个体系中,叫“软件开发流程”... 查看详情

构建之法第三章读书心得

  在构建之法第三章中,我们主要学习了个人能力的衡量与发展。  初级软件工程师有以下几个成长阶段:1、积累软件开发相关的知识,提升技术技能。                   2、积累问题领域的知识和... 查看详情

20179215《构建之法》第三章

《构建之法》第三章读书笔记?本章为软件工程师的成长,主要介绍了评价软件工程师水平的主要方法,技能的反面,TSP对个人的要求。一、个人能力的衡量与发展?软件开发流程:软件开发流程包括团队的流程,也包括个人的流... 查看详情

快速阅读《构建之法——现代软件工程》

...之法——现代软件工程》一书,2017年4月13日上午终于快速读完了一遍。书中包含的内容丰富,其中大量的网上链接没有阅读。在我看来,读这本书应该先通览全篇,不能被大量的链接在第一次阅读的时候就打断。网上的链接一... 查看详情

《构建之法》第三次随笔

 从《构建之法》前两章的阅读学习中,我了解到了软件工程的概论,知道了“软件=程序+软件工程”,明白了个人技术和流程。阅读了第三章之后,我体会到了软件工程师的成长。 软件工程包括了开发、运营、维护软件... 查看详情

《构建之法》小组第三次

   这周我们小组学习了《构建之法》的第四章,从中知道了很多代码规范的各种原则,这些原则在编程时约束我们,可以使我们的程序更加规范化,可读性更高,便于复审,测试和修改。   代码规范可以分... 查看详情

构建之法第三章

构建之法第三章本章为软件工程师的成长,主要介绍了评价软件工程师水平的主要方法,技能的反面,TSP对个人的要求。软件开发流程:软件开发流程包括团队的流程,也包括个人的流程初级软件工程师有几方面成长:1、积累... 查看详情

《构建之法》第三章学习心得

这周我学习了《构建之法》第三章,讲述了软件工程师的成长。软件系统的绝大部分模块都是由个人开发或维护的。在软件工程的术语中,这些单个的成员叫做Individ-ualContributor(IC)。IC在团队中的流程是怎么样的呢?以开发人... 查看详情