第一次博客作业

项目	内容
作业所属课程	2020春季计算机学院软件工程(罗杰 任建)
作业的要求	个人博客作业
我在这门课程的目标是	学习工程化软件开发方法，提高设计与架构能力、团队协作开发能力
这个作业在哪个具体方面帮助我实现目标	浏览《构建之法》，了解工程化软件开发方法；通过查阅资料，了解软件工程的背景、工具链等知识
参考资料	《构建之法》
阅读《构建之法》

问题1

软件工程师比大四学生多读了3年书，多工作了3年，两类人任务的质量要求也不一样。我们可以看到，工程师在“需求分析”和”测试“这两方面明显地要花更多的时间（多60%以上）。
——第2章 个人技术和流程 第3节 个人开发流程

作者将从业三年的工程师和大四学生在项目时间的分配情况进行统计、比较，得出了专业人员更多地将时间花在需求分析和测试上。我赞同这个结论，但是也产生了新的疑问：在平时的作业中，如果学生对编程语言不够熟练，或是设计与架构能力不足，导致在编码上耗费了大量的时间，以至于要赶在DDL之前完成作业，在这种情况下做需求分析和测试的时间很可能会比较紧缺。
之所以提出这个疑问，是因为我的确受到过困扰：做计组时花了大量时间做设计、写代码，匆匆忙忙地赶在DDL之前过了课下弱测，导致强测时出了问题。自我反思了一下，我觉得“花更多的时间做需求分析和测试”与“写出优秀代码”之间的关系，不是前因后果，而是前果后因。因为专业人员有更强的设计、架构、算法能力，所以他们可以用较短的时间就写出较高质量的代码。一个开发周期内，写代码的时间少了，就可以拿出更多的时间干别的：比如说做更细致的需求分析、做更完备的测试。

问题2

函数最好有单一的出口，为了达到这一目的，可以使用goto。
——第4章 两人合作 第3节 代码设计规范

作者在说明函数的编写规范时，提到可以使用goto来规范函数的出口。使用goto语句确实可以让函数内部的逻辑更加清晰，但是也要防止goto语句的滥用。

在C/C++等高级编程语言中保留了goto语句，但被建议不用或少用。在一些更新的高级编程语言，如Java不提供goto语句，它虽然指定goto作为关键字，但不支持它的使用，使程序简洁易读；尽管如此后来的c#还是支持goto语句的，goto语句一个好处就是可以保证程序存在唯一的出口，避免了过于庞大的if嵌套。
——摘抄自搜狗百科

其实有很多方法可以代替goto语句，goto语句本质上也是分支跳转语句，完全可以用if/switch+判别变量来整理程序的逻辑。不过作者是有多年技术经验的业界大牛，我觉得书中的这种说法一定是有道理的，并且在实际开发中是有应用价值的。关键是要理解书中此处文本围绕的中心思想——规范设计。

问题3

只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。
——第4章 两人合作 第5节 结对编程

作者强调在结对编程中双方平级、平等、平权，我有所怀疑：当结对双方的架构、算法等水平具有明显的差距之时，双方是否在结对过程中能够做到决策平等，或者说双方是否应该决策平等？
我虽然没有结对编程的经验，但却有与同学讨论设计、阅读优秀作业代码的经历。不可否认的是不同个体间的设计、编程、算法等能力存在或大或小的差距，而我认为这些差距实际上会造成结对过程中的双方地位、权利的不平等：当我向编程新手介绍我对某个问题的设计方案、展示我的代码实现之时，可能他会花上较长的一段时间来分析理解；同样，当我阅读同届大佬们的优秀代码时，我也会花上一些时间来研究他们的架构、学习他们的思路。在实际的结对编程中，双方都身处高强度、快节奏的工作环境之中，如果其中一人因为能力上的不足导致双方沟通阻塞、造成时间上的浪费，那么二者的地位或权利将会失衡。出于实际情况的考虑，能力较强的一方必定、也应该获得更大的话语权。

问题4

下面是一个实际项目的燃尽图，有三个每天跟踪的时间值：实际剩余时间、预估剩余时间、实际花费时间。
——第6章 敏捷流程 第2节 敏捷流程的问题和解法

文中给出了两幅非常详尽、精确的燃尽图，任务进度精确到小时。在实际开发中，究竟如何估算出项目的耗时。
在平时的作业中，我也会大概计算出完成该项任务需要多少小时。不过我的估算非常粗浅，就是先大致将整个作业分成几个模块，凭感觉估计完成每个模块要花费多长时间。这样每次估算的结果，往往与最后耗费的总时间相差甚远。书中的注解也提到：

最终完成的工作量为524小时，是预计的1.5倍。（这暴露了什么问题呢？）

我的想法是，具有足够经验的开发者，会较为准确地估算出项目的规模（甚至精确到代码的行数），然后根据自己的编码速度，估算出项目大致的耗时。但这毕竟是我的猜想，我的困惑是：有没有一种比较科学的方法，能够比较准确地预估项目的耗时、进度。

问题5

但是，有些创新是颠覆式的(Dis-ruptive Innovation)，这些想法一旦出现，便会引起现有技术拥有着的极大不安。
可以看出，在算法和数据库领域，创新的想法一开始往往不被接受，而那些建立在前人基础上的“线性扩展”则往往有着更好的命运。
——第16章 IT行业的创新 第1节 创新的迷思

作者为了论证“并非所有人都喜欢创新”，确实是用心良苦。理想很丰满，现实很骨感。我们所倡导的创新意识、科技创新的战略，有时候会在现实中遭受阻拦与打击。我的疑问是，如果我们以后能够从事计算机相关领域的研究，是追求变革性的理论突破、创新方法，还是安稳地在前人研究的基础上修修补补、做“线性扩展”？

“软件”与“软件工程”的出现
- 软件
- 1953年8月Richard R.Carhart在兰德公司的一份研究备忘录中首次发表。
- 主流说法认为“软件”最早被John Wilder Tukey在1958年发表在"The Teaching of Concrete Mathematics"论文。
- 软件工程
- “软件工程”一词最早出现在1965年6月出版的《计算机与自动化》杂志上的一份公司服务清单中。
- 另一种说法认为，“软件工程”一词最早由Margaret Hamilton在上世纪50年代命名。

软件工程发展的过程中有趣的冷知识和故事
20世纪60年代，IBM公司的大型操作系统OS/360项目，由于种种原因延误了大约1年时间，难以继续开展下去。1966年1月，瓦茨-汉弗雷接任IBM编程主任一职。上任后，他便取消了当年所有的交付计划，并让各个小组重新拟定可行的交付计划。计划拿到手后，汉弗雷宣布了一系列时间表，总跨度为两年。公司逐个按期完成，虽然晚了一年，并且支出了4倍的预算，但IBM最终兑现了诺言，交付了OS/360系统。该案例成了二战后软件行业最经典的商业案例，它押上整个公司作为赌注，并且取得了巨大回报。

主流源程序和项目管理软件
用户数量排名

名称	用户数量
GitHub	31,000,000
Bitbucket	5,000,000
Launchpad	3,965,288
Source Forge	3,700,000
GNU Savannah	93,346
OSDN	54,826
Ourproject.org	6,353

参考链接

优缺点

名称	优点	缺点
Microsoft TFS	任务板可显示需求、项目进度；集成了项目管理、版本控制、BUG跟踪；能与VS无缝对接	用浏览器访问很慢，用XP系统无法访问
Git	速度快、使用便捷；采用分布式版本库，适合个体开发	保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息；学习周期较长
Mercurial	简洁优雅，pull指令避免创建分支；服务器部署相对容易	分支管理不方便；支持社区略差
Github	浏览器访问，可用性好；管理分支更加便捷；上手快，使用方便	国内访问速度慢；对中文编码不够友好
Bitbucket	灵活的权限控制；BUG跟踪	国内访问速度慢
trac	可与SVN集成，便捷灵活；权限设置完善	功能不是很强大
Bugzilla	免费，有中文版支持	快速搜索结果不准确
Apple Xcode	编译速度快；自动提供撤销、重做和保存功能	更新版本后，某个插件可能失效

使用Git
以下是使用git管理本地分支的截图：
- 初始化仓库：

- 添加所有文件到本地分支：

git是许多代码托管平台所依赖的基础，影响力十分广泛。git对于分支的管理比较清晰详细，熟练掌握几个命令行操作后，可以非常方便地管理本地代码、上传分支到远程仓库。

使用Github
以下是通过访问github网站直接下载远程仓库内容的截图：

想要将远程仓库代码下载到本地，github网站提供了两种方式：clone仓库到本地、下载zip压缩文件，其中clone方式又有SSH、HTTP两种途径。从github上获取开源代码十分方便，并且可以便捷地为分支添加标注，甚至可以直接在github网站上修改仓库内容。