| 项目 | 内容 |
|---|---|
| 本次作业所属课程 | 北航2019软件工程 |
| 本次作业要求 | 要求详情 |
| 我在本课程的目标 | 思考实践缺一不可 |
| 本次作业的帮助 | 重通过《构建之法》对软件工程有了大概理解 |
一、关于教材仍然不懂的问题
- 1.2.4中提到了“Bug”和“Feature”的关系：
很多人认为bug就是质量不合格，没有bug就是质量完美，其实这也未必。···对于某些顾客来说，某一类的汽车满足了他们的需求，他们就会买。如果销售人员向不合适的目标用户推销自己公司的汽车，最后销量未必理想。
我可以理解的是，对于很多产品，他们拥有自己的目标人群，又由于有大量替代品的存在，开发者/设计师可以做到忽略bug的存在。例如破洞牛仔裤，完全可以作为feature销售给喜爱这种风格的用户，同时不喜爱的用户有不破洞的牛仔裤供替代购买。但是在没有替代品的情况下，例如大学的教务系统，此时存在的对于某些人的feature是否需要完善和修改？如何平衡面向人群总数和修改这样一个功能的工程量？
- 6.2中提到了了肯·施瓦伯(Ken Schwaber)说到：
我还建议，把所有开发过程的附加物件，像设计文档，都扔掉······SCRUM依赖于团队人员面对面，高容量的交流和合作；每个人独立的小隔间，没有必要的文档都增加了疏离和误解的可能性。
其中本书作者提到了如果团队成员在不同时区工作，就需要文档等辅助手段来达到敏捷的目的，但是敏捷原则中提到了“每天共同工作”，“保持简明，简化工作量”。我认为为了尽早并且持续的交付软件，文档的存在是会延误工程的推进的，撰写过程和阅读过程都是耗费时间的。这与敏捷原则相悖，所以我还是认为文档是不应当存在于敏捷流程的，而这种无法共同工作的成员也是不应当存在的。否则这种团队与非敏捷流程的区别又在哪里呢？
-
8.3.9中提到了A/B测试，里面提到了“在技术上实现A/B测试(通常在5%-10%的用户上运行试验)”，意思是每100个访问web端的用户中会有5-10个尝试到新的布局结构么？我在百度上查询到的结果是“在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本”，但是这个访客群组怎么选取我仍然不太了解，希望能阐述的更细致一点。
-
11.2.4中提到了统一的表达方式，涉及到UML图的一些方面：
“能把设计画成图，让别人理解当然很好。但是说实话我真的记不起来哪些模块应该是圆形，哪些是方形。”
这一段话我的感触颇深。在大二的面向对象课程中我们被要求使用类图绘制出其继承关系，互相依赖，实例化等等，本来是一件能够理清楚程序结构的好事情，但是那些箭头有虚线有实线，父类指向子类还是子类指向父类总是让人混淆。我们在绘图的过程中逐渐烦躁，包括数据库原理课程中的实体属性图等等，虽然我理解这些图对于设计的作用。但是其绘制过程费时费力，我们是否有必要遵循某种规则来绘制？亦或是将图绘制成我们自己能看懂的形式就可以了？毕竟我们才是设计者。包括后文提到的由于在程序中写了太多的注释，导致变成了“写文档，时不时有些代码”。
- 16.1.3迷思之三中提到了好的想法不一定赢，并且举了键盘布局的例子：
原始布局设计的优点反而成了缺点。但是，长期以来，人们已经习惯了QWERTY键盘，所谓先入为主。
我们知道的是技术的革新的一代接着一代的，一个产品没能够成功我认为原因不是因为其竞争者存在的时间之长或者覆盖率之广，试想家家户户都是大屁股电视的时候是谁优化改良了电视使其轻薄？而为什么他就能够成功？我想是因为其推动革新的坚决。优化布局之所以没能撼动原始布局，我认为是因为目前的厂商没有很好地进行坚持。倘若各大电脑厂商从今天开始逐渐提供优化布局的键盘，各个家庭的小孩子从这一代开始接触优化布局，学校中也逐渐配备优化布局的键盘，当人们尝到打字效率提高的甜头，相信很快原始布局键盘会被淘汰。所以我认为好的想法只要坚持就会赢。
二、“软件” 和 “软件工程” 词汇的出现
-
软件：由John Tukey在1958年的论文"The Teaching of Concrete Mathematics"中首次使用
-
软件工程：阿波罗11号的软件开发期间由Margaret Hamilton首次使用
三、软件工程发展过程中的冷知识和故事
-
每个做过计算机图像处理的人都认识 Lena。她是七十年代一个花花公子杂志的模特，她在杂志上的一幅照片被 USC 的两名研究员用来测试一个图像压缩算法。从那时起直到今天，她的这张照片都是图像处理领域里最常用的测试图。图片被起名叫 Lenna。她甚至有时被称为互联网的 First Lady。
-
Lena 本人知道这些事，但从未离开过自己的生活轨道。她不懂计算机。她儿子试图给她解释过，她还是搞不懂。这次 Wired 几经周折才采访到了已经进入暮年的她。
-
还给她拍了一张同样姿势的照片。两张照片相差了 46 年。
四、目前流行的源程序版本管理软件和项目管理软件以及优缺点
-
Git
- GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。
- 可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前，我们已经强调过Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。
-
Mercurial
- 采用了分布式系统，管理更加轻松。不需要定期维护资料库。
- 在合并时只允许两层父阶层版本异动。
-
Trac
- 非常灵活，可以随心所欲控制可以和SVN集成
- 功能不是很强大
-
Bugzilla
- 免费，有中文版支持
- 快速搜索结果不准确。只能管理缺陷。
-
Apple XCode
- 编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。
- 更新版本后，某个插件可能会失效。
-
Visual Source Safe
- 如果开发工具是VS.NET，用VSS较合适，方便，安装配置和使用都简单，版本控制简单，打label后，要还原到这个版本较简单
- 基局域网，效率低，VSS自身安全性较差，只支持widows平台下
-
Concurrent Version System
- 一度成为主流，不必担心数据流失，对中文路径名支持的较好，本地文件与库的对应可以多对多
- 不支持文件改名且只允许存储文件，管理员很难清楚的知道一个项目到底有多少个用户各用户的权限和密码是什么只能用分组的方式管理用户而且密码和权限还是不清晰
-
subversion
- 支持文件重命名提交系统会提示删除旧文件，创建新文件，删除本地文件提交库中文件也被删除
- 要将权限控制文件保存为svn支持的UTF-8格式，一个库可以有多个工作目录但一个工作目录只能对应一个库虽然可以更改库位置但是要求很严格，库中文件存放方式，看不到文件真正的内容
-
Microsoft TFS
- 是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。
- 能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。