个人作业-Week1

  • 快速看完整部教材，列出你不懂的5-10个问题，发布在你的个人博客上。

  1. 作者如何看待代码自动生成这项工作？因为现在已经有人在研究这方面了，当然目前还只能实现一些简单编程，可未来的发展不好说。本书讲解软件工程，那么将来是否只需要少量的程序员加自动生成程序就可以搞定大型复杂的软件过程呢？这几年，各种速成机构培训出的底层程序员实在太多了，行业的门槛是否已被拉低？

  2. 书中1.2.2节里讲了软件工程与计算机科学的关系，其中提到

    计算机科学中的理论研究部分，大多可以从形式上证明，与数学、 离散数学、 数理逻辑密切相关； 计算机科学中与实践相关的部分，都和数据以及其他学科发生关系； 软件工程则和人的行为、现实社会的需求息息相关。

      这里指出了两门学科的区别，我们知道这两门学科确实有不同的侧重点。但就本科教育阶段来说，CS和SE的本科毕业生差距大吗？因为目前很多言论都说，除了少许一流大学，很多学校这两门学科的课程安排、教师团队都是差不多的。那么北航存在这个问题吗？两院学生的差距体现在哪些方面呢？(因为相较与理论的探索，本人对实践应用更感兴趣，但机缘巧合考进了计院...)

  3. 在书中的2.1节，讲了PSP里的单元测试。其中2.1.1介绍了使用VSTS的基本操作，但实际操作中有一些疑问。例如在被测试类A里有一个private函数f()，该如何对f()进行测试？因为在测试类B中无法调用A的私有函数，所以我测试时暂将其改为了public，但在测试时修改被测试文件显然是不应该的。有其他更好的解决办法吗？

  4. 书中3.1节讲了软件工程师个人能力的衡量，其中提到交付的质量与时间。那么这两者应该如何平衡？有人说程序优化分以下几步：

    • make it run
    • make it right
    • make it fast
    • make it maintainable.

    那么当软件达到最基本的right要求后，之后的优化和交付时间之间怎么取舍？

  5. 书中4.4节论述了代码复审的重要性，但关于如何复审我还是有些疑惑。正如第二章所说，最熟悉代码的人肯定是开发者自己，这也是PSP里自我测试的重要原因。那么复审者如何在不够了解代码的情况下进行审核呢？又或者该怎样高效地弄清别人的代码呢？

  6. 书里第五章介绍了各种软件团队的模式。

    • 主治医师模式
    • 社区模式
    • 秘密团队
    • 交响乐团模式
    • 功能团队模式

    看样子我们的课程是采用功能团队模式了。那么这种模式是否有明显优于其他模式的地方，还是只因为它更适合在教学中考查到每个学生？在工作中又是哪种团队模式更常见？

  7. 书的第八章讲需求分析，其中提到了用户调研的重要性。大型企业有相当大的用户量，容易获取大量的用户反馈，但对于创业初期的小公司，如何调查用户需求？怎样提高对市场敏锐度和洞察力？

  8. 书的第九章介绍了项目经理这一职位，其中提到

> PM的出现让团队内部的互动出现了两个新特性：
> 1. 负责一个功能的开发/测试人员和相关的PM密切合作，再由PM代表这一小组去和别的小组或客户代表打交道，大大降低了交流的成本
  1. 有专人负责开发/测试之外的许多事务和项目进度的管理，让开发和测试人员专注于技术方面的工作
 那么PM应该如何与开发测试人员密切合作？两者之间的相对地位应该是怎样的？PM本身是否必须是优秀的开发测试人员？
  1. 暂时先提这些，看书比较慢。感觉这本书确实把从业人员的方方面面都讲到了，好好品读有不少收获。再结合课程实践，坚持下来应该能有不小进步，对以后的职场也是很好的预演了。
  • 请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
  1. 美国统计学家约翰·图克（John W. Tukey）在1958年1月9日出版的《混合数学教学》（American Mathematical Monthly）中首次公开使用“软件”（software）一词。
  2. 在1968年德国的Garmisch，北大西洋公约组织（NATO）举办了首次软件工程学术会议，会上Peter Naur和Brian Randell首次提出了“软件工程”（software engineering）的概念。
  • 大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？(+2')

2001年2月，17 位软件绿林好汉聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。白天除了滑雪, 没啥鸟事; 晚上除了喝酒侃大山, 鸟没啥事… 但是他们都感觉世变时移, 变法宜矣。 经过讨论，《敏捷宣言》应运而生
...
这堆牛人在几个晚上就搞出了一个“敏捷宣言”。

（《构建之法》第三版P127）

  • 上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？ （提示：搜索一下Microsoft TFS、Git、Mercurial、GitHub、Bitbucket、Trac、Bugzilla、Rationale，Apple XCode）?
    平台使用人数估计：GitHub>Bugzilla>Mercurial>Trac
  1. Git
    优点：免费的开源软件，对程序源代码进行差异化的版本管理，代码库占极少的空间，易于代码的分支化管理。
    缺点：对中文不够友好，使用难度较大（但近年推出的Git GUI以及各IDE的集成已经大大了降低学习成本，这也是Git成为当下最主流的原因之一）。
  2. GitHub
    优点：基于web提供Git存储库服务，是Git的网上项目托管平台，内含大量优秀开源项目，适合多人同时维护庞大的开源代码。(16年Octoverse报告显示，中国新用户注册同比增长了97%，居世界第一)
    缺点：github:fi费用过高。
  3. Bugzilla
    优点：检索功能强大，后端数据库支持
    缺点：安装配置过程繁琐
  4. Mercurial
    优点：命令行简单，上手容易
    缺点：功能不足，分支过多
  5. Bitbucket：
    优点：同GitHub，但支持免费私有项目
    缺点：作为同类网站，界面、功能等不如GitHub，使用人数也因此更少。
  6. Microsoft TFS：
    优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM能与 VS 无缝接合。
    缺点：搭建、维护tfs比较复杂，硬件要求也比较高。(微软近年来一改前风，将开源摆在企业重要位置。据GitHub的Octoverse报告，在所有组织中微软的开源贡献者人数最多)
  7. Apple XCode：
    优点：编译速度极快，可编写iOS App，虚拟模型和设计功能让你可以更轻松的开发和维护应用程序。
    缺点：只能在Mac环境中运行，体积臃肿，一般认为不如VS
  8. Trac：
    优点：Trac作为一个SCM配置管理平台，有良好的扩充性；权限体系是比较完备的设计；非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
    缺点：不支持多项目，需求和缺陷没有分离，用 wiki 来替代 Word 等工具编写文档，对中文不友好，核心功能少。
posted @ 2017-09-23 15:50  silentic  阅读(203)  评论(1)  编辑  收藏  举报