【2020BUAA软件工程】个人博客作业
个人作业博客
| 项目 | 内容 |
|---|---|
| 北航2020软工 | 班级博客 |
| 作业要求 | 具体要求 |
| 我的课程目标 | 学习软件工程，掌握团队合作，锻炼自我 |
| 作业在哪个方面帮助我实现目标 | 通读《构建之法》，尝试理解软件工程 |
Part1 5-10个问题
问题1 过早优化。我们如何来鉴定某个优化是否是过早优化，还是压根就先不考虑优化，最后进行量化后再优化，这样不是又会导致重构等一系列问题？
2.2 效能分析工具中提到了过早优化
我自己就深有体会，在写编译器时，常常会提前考虑这个函数会不会很慢，需不需要优化一下之类的事情，但是事实证明，在后期，一个逻辑的不正确导致程序速度急剧变慢，而一开始的函数即使再优化也占很小的一个比重。但是又常常掉进这一思维陷阱里。
我找到vczh的回答：
过早指的不是在开发过程的早期，而是在还没弄清楚需求未来的变化的走向的时候。你的优化不仅可能导致你无法很好地实现新的需求，而且你对优化的预期的猜测有可能还是错的，导致实际上你除了把代码变复杂以外什么都没得到。
但是我又看到一些说法似乎是把这个过早就是理解为工程早期。所以我的疑问是什么是过早，我们该如何鉴定这样的优化而尽量避免重构呢？
而且还有原文：
We should forget about small efficiencies, say about 97% of the time: permature optimization is the root of all evil. Yet we should not pass up out opportunities in that critical 3%
似乎是赞成那3%的可能性的，于是我对这一概念的理解有些晕了，希望解答！
问题2 代码设计规范
4.3 代码设计规范
4.3.1 函数：只做一件事，并且要做好
4.3.2 goto：只要有助于程序逻辑的清晰体现，什么方法都可以用，包括goto
函数：
在这里，我的疑问是函数只做一件事，那么这一件事的范围是多大呢，在实际的写代码过程中，我常常会遇到这样的问题，需不需要把一个函数拆分成两个，方便对接，但是如果把一个函数面面俱到的拆分开，完全是一件事情一个函数，这样子会不会嵌套太多呢？
我承认函数只做一件事是很好的原则，但是对于有些情况，这样做反而会导致嵌套过多，如果说为了解决嵌套问题，而又没有使用函数，那之前的原则不是又不适用了？
goto:
这里作者提到为了程序的清晰度可以使用goto，但是我个人的体验是goto对于程序的清晰度远不及if或者是switch等，goto的本质和汇编中的jump指令一样，而高级语言就是为了抽象才增加了层次，这种返回去的做法会不会弊大于利呢，我个人认为使用goto就说明程序的逻辑已经开始出现问题，这时候不如通过重构来解决。
不过我在知乎上看到大家对这一问题的评价：
工作中错误处理时经常会用到。不要把goto妖魔化。
特定场景下可以用并且很常用，比如驱动开发
......
很多人确实是赞成的，goto对于统一处理错误，或者在驱动程序中开发确有利用，这一点让我冲重新理解了goto。
就是说很多流行说法其实是存在片面化的问题的，甚至是独断的，但是大家却习以为常，慢慢演化为常识一般，谨记！
问题3 关于敏捷开发
第六章讲了敏捷流程
我注意到敏捷开发里面讲到需要不断的迭代来频繁更新维护软件，我的怀疑就是用户会喜欢这种不断的甚至是频繁的迭代吗？
拿我个人举例，我现在几乎不会去关心什么软件的更新，甚至是采取除非必要否则不更新这样的策略，像我这种用户频繁的迭代似乎也不是一个很好的体验，而且现在的软件很多的更新都是维护一些小的问题，对于用户的体验影响感觉不是很大，反而频繁的更新带来一定的副作用。
进一步，这种更新需要和用户的需求联系起来，但是我认为有时候小团队真正困难的恰恰就是如何搞明白用户需求，甚至是不断的迭代来满足用户需求，像我这样的用户很多，有多少人是在认真看更新的公告的？（就像是你在点“我同意并且已阅读相关条例”）所以反馈可能并不是那么准确且及时，那这个时候敏捷开发还会有效吗？
现在国内还挺推崇敏捷开发，但是真正做到的很少吧，这个流程看起来很不错，但是对于我们的国情真的适用吗，敏捷对于我们很有必要吗？
问题4 创新对于专业度的需求真的不高吗？
16.1.5 迷思之五：要成为领域的专家，才能创新
这里，作者提到了WWW的创建、诺基亚以及索尼“单放机”的例子是领域外的创新成功
但是我觉得不是很妥：
- 诺基亚和索尼的本质属于商业，他们的选择，应该是在商业模式中的选择，不能说诺基亚一开始卖通信外的产品就说它在商业模式上不专业，它的成功应该归结于商业的成功选择以及在通信领域的不断发展等多方面因素，我觉得这不算是领域外的成功。我更愿意说诺基亚的成功是多领域结合的，而不是通信领域外一个菜鸟就突然逆袭这样子。更重要的是，诺基亚在通信领域也有很深的基础，完全不是小白，它在手机行业的成功不能说是领域外的成功。
- 对于索尼，作者提到盛田基于自己对电子消费品的趋势的洞察和对未来的直觉才坚持这一创新，这明显是商业领域的专家才具备的意识和大局观，而且领域外体现在哪里呢？难道是和语言专家讨论名字是否符合语言学，但是他们的创新是商业的创新，也不是在语言领域内！我认为还是属于领域内的创新！
所以我觉得创新还是基于一定的领域基础的，甚至必须是达到专家级别，更甚者需求多领域的精通才能够实现，单一领域的创新更是如此。即使是WWW的出现，难道蒂姆·伯纳斯-李在计算机这方面是个菜鸟吗？你管这种人叫领域外？
伯纳斯·李（Tim Berners-Lee）出生于英格兰伦敦西南部。父亲是康威·伯纳斯·李，母亲是玛丽·李·伍兹。他的父母都参与了世界上第一台商业电脑，曼切斯特1型（Manchester Mark I）的建造。
蒂姆进入大学，1976年从牛津大学物理系获得一级荣誉学位，毕业之后，曾经供职于英国一些高技术公司，从事集成电路和系统设计研究，其出众的才华逐渐得以展露。
我的思考是创新存在领域外的成功，但是绝大多数的创新还是基于很庞大的基础，站在巨人的肩膀上才得以实现。
综上，我对作者提出的统计数字表示存疑，对这一说法的判定方式存疑。
问题5 软件不遵守原则
p412 17.8软件工程师的职业道德
原则2 客户与雇主
软件工程师应以其客户和雇主的利益最大化的方式做事，与公众利益保持一致
但是我注意到有这样一些设计：
- 在软件的卸载过程会出现一个界面，通常是卖萌或者需要选卸载理由、更甚者把“取消”故意高亮，“确定”故意淡化，这种设计从用户角度是一种陷阱，貌似并没有给用户体验加分，反而起了反作用，让用户下定决心不再使用;
- 现在软件也经常出现捆绑安装等流氓做法，这似乎也是钻了用户心理漏洞
这些貌似并没有从客户的角度考虑利益最大化，反而是一种投机取巧的行为，而且还层出不穷。从用户体验的角度来看，这种设计也不是良好的用户体验吧，我的疑问是就算是出于利益的角度，这也无异于一种饮鸩止渴、杀鸡取卵的方式，而且还违背原则，我们现在的软件环境还是这样的吗？还是说中国的软件行业仍然有很大的进步空间？那为什么国内现在很多的软件是这样做的呢？
我觉得一定程度上是因为当前国内环境的问题，国内现在其实绝大多数人是属于不懂软件这一套东西的，于是这些软件工程师单纯从自身利益出发，在满足用户基本要求的前提下，不断的突破底线，谋求利益，这俨然违背行业道德。尤其是游戏软件行业，我国这方面更甚。
我自己的问题就是软件如果单纯的只是出于利益，那我们的发展该怎么延续，国内现在的环境不论是版权意识还是软件知识方面，都有很大的欠缺，当我们作为一个软件工程师的时候，是拿起镰刀割草呢，还是坚持原则？
问题6 PHP不是最好的语言？
以上是阅读过程的思考和疑问，可能会有疏漏，欢迎指正和讨论！
Part2 请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件：
In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics"[10][11] contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years.[12] This led many to credit Tukey with coining the term, particularly in obituaries published that same year,[3] although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim.[13] The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a RAND Corporation research memorandum.[14]
- 维基百科上面主流说法认为“软件”出现于John Tukey在1958年发表的论文“The Teaching of Concrete Mathematics”中最早出现，但是他本人没有承认。
- 另外一种说法是Paul Niquette声称他最初是在1953年10月创造了这个“软件”这个词汇，但是他没有任何能够支持他说法的文件。
- 最后已知最早在工程环境中使用“软件”一词的出版物是在1953年8月由Richard R. Carhart在兰德公司的一份研究备忘录中发表的。
软件工程：
When Hamilton started using the term "software engineering" during the early Apollo missions,[61] software development was not taken seriously compared to other engineering,[62] nor was it regarded as a science
还有说法认为：
The term "software engineering" appeared in a list of services offered by companies in the June 1965 issue of COMPUTERS and AUTOMATION and was used more formally in the August 1966 issue of Communications of the ACM (Volume 9, number 8) “letter to the ACM membership” by the ACM President Anthony A. Oettinger;,[8] it is also associated with the title of a NATO conference in 1968 by Professor Friedrich L. Bauer, the first conference on software engineering.
- “软件工程”一词出现在1965年6月出版的《计算机与自动化》杂志上的一份公司服务清单中；
- 在1966年8月ACM通讯中，ACM主席安东尼·a·厄廷格的“致ACM成员的信”中更正式地使用了“软件工程”一词；
- “软件工程”还与Friedrich L. Bauer教授在1968年召开的一次北约会议的题目有关，该会议是关于软件工程的第一次会议。
Part3 【附加题】：大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
据说有一天，冯·诺依曼心神不定地被同事拉上了牌桌。一边打牌，一边还在想他的课题，狼狈不堪地“输掉”了10元钱。这位同事也是数学家，突然心生一计，想要捉弄一下他的朋友，于是用赢得的5元钱，购买了一本冯·诺依曼撰写的《博奕论和经济行为》，并把剩下的5元贴在书的封面，以表明他 “战胜”了“赌博经济理论家”，着实使冯·诺依曼“好没面子”。
——冯·诺依曼
Part4 上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
| 版本管理软件 | users |
|---|---|
| GitHub | 31,000,000 |
| Bitbucket | 5,000,000 |
| Launchpad | 3,965,288 |
| SourceForge | 3,700,000 |
| Microsoft TFS | Microsoft |
| Git | Linux kernel, Android, Bugzilla, DragonFly BSD, GNOME, GNU Emacs, GRUB2, KDE, MySQL, Perl 5,[80] PostgreSQL, X.Org, Cairo, Qt Development Frameworks, Samba, OpenEmbedded, Ruby, Ruby on Rails, Wine, Fluxbox, Openbox, Compiz Fusion, XCB, ELinks, XMMS2, e2fsprogs, GNU Core Utilities, DokuWiki, Drupal, LibreOffice, MediaWiki,[81] Mono, ASP.NET MVC, ADO.NET Entity Framework, NuGet, jQuery and many of its plugins, OpenCV, Wireshark, Django, many companies like Ericsson, Microsoft,Huawei, Apple, Amazon, LG |
| Mercurial | Python, Mozilla, OpenJDK, NetBeans, Xine, Xen, OpenSolaris, wmii, MoinMoin, Linux-HA, Pidgin, Gajim, Nginx, PyPy, SDL, Facebook, Google (as a UI on top of Piper) |
| Rational Team Concert | IBM |
参考链接:
Comparison of version-control software
Comparison of source-code-hosting facilities
优缺点：
Microsoft TFS
-
优：
- 任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM，能与 VS 无缝接合。
-
缺：
- 搭建、维护tfs比较复杂，硬件要求也比较高。
GitHub
- 优：
- GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。
- 缺：
- 可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前，我们已经强调过Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。
Trac
- 优：
- Trac做一个SCM配置管理平台，意味着它有良好的扩充性
- Trac的权限体系是比较完备的设计
- 非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
- 缺：
- 不支持多项目
- 需求和缺陷没有分离
- 用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了
- 中文化不完整，美术人员接触起来困难重重
- 不显示中文名，本地化做得很差
- 核心功能很少，不安装插件基本上没法用。
Bugzilla
- 优：
- BUGZILLA不收费
- BUGZILLA现在有中文版支持
- 缺：
- BUGZILLA只能管理缺陷
Apple XCode
- 优：
- 可以自动创建分类图表。
- 自动提供撤消、重做和保存功能，无需编写任何编码。
- 缺：
- 更新版本后，某个插件可能会失效。
SVN
- 优：
- SVN允许一个文件有任意都的可命名属性，功能十分完全,SVN会关心所有的文件类型，不需要你来手工操作，SVN支持“零或一”事务原则。
- 缺：
- SVN不允许递交后滚回。
Coding
- 优：
- 保护分支，分屏对比，按行评论等高级功能。并且整合了 CodeInsight，质量管理，演示平台等等开发工具，提升研发效率。
- 缺：
- 暂不支持导入外站的私有项目。
Part5 软件实践截图
Git:
使用看法：
其实git在之前就有使用过， 个人的理解就是，善用Git我们可以很勇敢的写代码，因为错了可以回溯，而且，一步步的迭代确实会有一种成就感在里面，具体的使用也不是很复杂，新手只需要简单的add，commit，push，pull差不多就可以上手，不会了找找教程，总之感觉Git比较面向新手，当然很多操作还得去学习才能有酷炫的收获！
BitBucket:
和GitHub的性质类似，也是一个源代码托管平台，由Mercurial和Git作为分布式版本控制系统，提供免费的账户，使用起来和GitHub差不多。
