速读《构建之法（第三版）》 20199319

标签：分类   质量   核心   艺术   一起   最好   生命周期   用户   art   

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

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图， 这算有思想么？

速读《构建之法（第三版）》 20199319

标签：分类   质量   核心   艺术   一起   最好   生命周期   用户   art   

原文地址：https://www.cnblogs.com/fanxiaonan/p/11735592.html