个人作业-Week1

疑问

• 教材中说，PM在衡量需求时需要方方面面的能力与研究。可是，当下许多互联网IT公司只承担外包业务，即客户给什么需求就实现什么需求，甚至可能不要求其它先进的功能。此时，开发团队还需要一个全能的PM吗？

• 我们都知道，客户的需求变化是极其随机且难以预测的。软件工程要求开发团队在coding之前做足准备工作以更好地处理这些需求变动，然而计划赶不上变化快（“神秘的程序员们”一篇漫画有提到），我想知道，当下企业中遇到这种情况是选择重构（能高效实现需求，但耗时耗力）多、还是选择补丁（这么说不准确，能省时省力实现，但增加了负载，效率不高）、还是因为变动过大而放弃项目？

• “用户需要帮助，但用户没有这么笨。”， “用户需要帮助，需要很多帮助。” 对于上述两种情况开发团队如何对其进行界定？

• 软件的设计文档是否从需求至实现进行了全部设计？软件设计文档是否规定了每一个类、每一个函数的参功能、参数、返回值，但不涉及到函数的实现？可是，实现过程中一定会出现意料之外的情况，设计可能也随之改变，请问怎样的设计文档才算作合格或优秀的设计文档？

哲学家的宗旨是：我思，故我在；科学家的宗旨是：我发现，故我在；工程师的宗旨是：我构建，故我在。

• 我的问题是，工程师在构建的过程中，是否受科学家、哲学家思想引领与指挥？灵感来源于生活，来源于一切事物，工程师除了构建，其他方面（如其它学科领域、人文、艺术、哲学等）的涉猎与接触是否对工程师的构建有帮助？

软件与软件工程

• 软件一词的出现：在2000年，耶鲁法学院的图书馆员Fred Shapiro发表一封信，显示Tukey的1958年“混凝土数学教学”文章包含了最早知道使用“ JSTOR ” 搜索中找到的“software”的电子档案。

• 软件工程一词的出现：Margaret Hamilton在为阿波罗11号开发软件的期间发明了软件工程一词。

代码版本管理软件与缺陷管理系统

• Microsoft TFS

  • 优点：
    • 任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用;
    • 集成了项目管理、版本控制、BUG 跟踪;
    • 能有效实现 SCRUM;
    • 能与 VS 无缝接合。
  • 缺点：
    • 整个系统是用 asp 实现的，用浏览器访问相当慢；
    • 用 XP 系统无法访问；
    • 团队的邮件细节配置比较复杂。

  引用：知乎-如何评价微软的TFS(Team Foundation Server),类似的更好替代产品有哪些?

• Git
  • 优点:
    • 免费的、开源的、分布式的版本控制系统；
    • 版本库本地化，支持离线提交，相对独立不影响协同开发；
    • 把内容按元数据方式存储，完整克隆版本库；
    • 支持快速切换分支方便合并，比较合并性能好；分布式版本库，无单点故障，内容完整性好。
  • 缺点：
    • 概念过于复杂；
    • 引入了 index/commit/stash/branch/remote repo 等诸多概念；
    • 对于初学 Git 的用户，在使用 Git 的过程中还会继续遇到更多的陌生概念。
    • 命令行语法设计得比较随意且不一致。例如 git pull 等价于 git fetch 后加 git merge，git branch -b 等价于 git branch 后跟 git checkout；
    • 缺乏良好的封装。初学者有时不得不面对(需要用到(和内部实现相关的知识))的问题；
    • 对代码的维护者友好，但却牺牲了共享者的使用体验。

  引用：Git的优势和用法,
  知乎-Git有哪些缺点

• Mercurial
  • 优点：
    • 跨平台；
    • 封装好。
  • 缺点：
    • 分支管理不灵活；
    • 支持社区略差。

  引用：Mercurial 有哪些优点？适合怎样的开发者或团队使用？

• Github
  • 优点：
    • pull request，issue都是杀手级的feature;
    • 强调个人，符合hacker更看重名誉/成就感的天性。
  • 缺点：
    • 国内访问速度太慢，经常出现connect time-out（非GFW所为）；
    • 不能很好的解决GB2312/GBK，对中文不够友好；
    • wiki功能太弱，直接导致文档（对于开源项目很重要）经常被分离到一个独立站点。

  引用：Github 有什么优缺点？把项目直接搭建在 Github 上合适吗？

• Bitbucket
  • 优点：
    • 支持Hg，最易学易用（但不是最强大的）的分布式版本管理工具。同时也支持Git。他的网页端的git仓库不如github好用，但是作为远端仓库足够了;
    • 完全免费的闭源项目，还支持5人以内的合作开发;
    • 支持中文;
    • 官方的git工具SourceTree比GitHub for windows好用。
  • 缺点：
    • 限制公开仓库，有时候速度比较慢；
    • 域名不好记。

  引用：GitHub、Bitbucket、Google Code 各有哪些优缺点？

• Bugzilla
  • 优点：
    • 免费的开源的一款功能强大的Bug管理系统；
    • 强大的检索功能，强大的后端数据库支持, 丰富多样的配置设定；
  • 缺点：
    • 安装需要Perl和配置MYSQL数据库，过程比较繁琐；
    • 修改配置文件比较麻烦；
    • 能汉化但是汉化后容易出现乱码。

  引用：常用的五大bug管理工具的优缺点和下载地址

• Rational
  • 优点：
    • 可以创建争论地图，推理和论点图表;
    • Rationale 将帮助学生学习良好的推理，重要思维，论文写作的基本原理；
    • 并且还将有助于专业人士更加方便有效地进行复杂的推论。

  引用：http://www.onlinedown.net/soft/6009.htm

趣闻（因为不够冷）

Donald Ervin Knuth习惯用铅笔而非键盘写初稿，他将原因归咎于打字速度远高于思考速度（每分钟 80 个单词以上），而这会导致思考出现太多停顿，用铅笔可以让思考与输入速度保持一致——“我打字的速度比我思考的速度更快，这样当我试图用键盘创作重要内容时，就会产生同步问题。速度通常不会是最重要的标准。科学一般都难以迅速解释或迅速领会……我通常的工作方式是用铅笔和纸先把所有东西都写下来，然后在旁边放一个大废纸篓。然后使用Emacs将所有文本键入到机器中……特定的Emacs快捷键使得写书的过程有点儿像演奏风琴……”

（评价：这老头这么任性也是没谁了。。先膜为敬，反正写软工作业我不会用铅笔 :D