软工网络15个人作业4——alpha阶段个人总结

一、个人总结

第一部分：硬的问题

第二部分：软的问题

二、回答问题

问题一：

我看了这一段文字

软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。

那么软件工程到底有什么用呢？

回答：

• 软件工程的思想目的和其他学科的工程方法（比如土木工程等）并无太大差异，主要是降低软件系统的复杂性、提高其可控性，以此在软件开发、维护、测试等各个阶段提高效率。
• 让整个软件系统“大而不乱”，井井有条。减少程序员工作的负荷并提高软件需求、设计、开发、测试、维护的效率。

问题二：

我看了这一段文字

从学生到职业程序员，并不是更加没完没了地写程序——花在写代码的时间反而少了许多。

职业程序员的能力比学生强多了，会做的东西就更多了，就会敲更多的代码了。那为什么职业程序员花在写代码的时间反而少了许多呢？

回答：

因为职业程序员任务的质量要求不一样。职业程序员在“需求分析”和“测试”这两方面明显地要花更多的时间。但在具体编码上，花费的时间会比学生少。从学生到职业程序员，并不是更加没完没了地写程序——花在写代码上的时间反而少了许多。

问题三：

我看了这一段文字

在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。

那么敏捷流程到底是什么东西呢？

回答：

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。总结如下：

• 不断交付软件以满足客户需要
• 欢迎需求的变化
• 可以工作的软件是进度的主要衡量标准
• 对卓越技术与良好设计的不断追求将有助于提高敏捷性
• 简单——尽可能减少工作量的艺术至关重要

感觉敏捷是态度而不是流程，是氛围而不是方法。

三、再提问题

第4章 两人合作

我看了这一段文字

代码复审就是看代码是否在“代码规范”的框架内正确地解决了问题。

Q1：

那如果开发人员在写代码的过程中就严格按照代码规范来写，做到完美，那此时代码复审不就毫无意义了？复审者本就是在替开发者干开发者本应干的事情，那意味着开发者自己做好的话，复审就没必要了？

第5章 团队和流程

我看了这一段文字

软件团队有各种形式，适用于不同的人员和需求。基于直觉形成的团队模式未必是最合适的。

Q2:

如果要开展一个全新的项目，到底该怎么选择“合适”的团队模式呢？课本中仅仅是介绍了各种模式，但并未教我们到底该如何选择。

第7章 MSF

我看了这一段文字

二柱：软件工程讲的净是一些奇妙玄幻的概念，拗口的专业名词加上纷繁复杂的流程，其实做软件完全没那么难，主要靠的还是程序员自身的修养和完成工作的素质。

Q3：

我觉得这段话讲得很有道理啊，请问你怎么看呢？

第12章 用户体验

我看了这一段文字

用户体验设计的一个重要目的就是要降低用户的认知阻力，即用户对于软件界面的认知和实际结果的差异。

Q4：

既然用户体验设计的目的就是为了用户，那是不是可以理解为要根据大众的想法来设计？但我们平时使用的一些软件，比如知乎，这些公司对于用户体验设计应该都是很在行的，但为什么在用户体验这一方面会越做越烂呢？
我的问题是，是什么原因导致了这种情况的发生。每次出新版本，每次都会受到用户的大量吐槽，为何会一直在错的路上一直走下去呢。如果在内容和功能上，加入了可以获利的东西尚可理解，毕竟一个公司都是需要收入的。那么UI越做越丑，怎么就不会改回去呢。

第16章 IT行业的创新

我看了这一段文字

不但大众不喜欢创新，甚至连创新者自己都不例外，有些创新者甚至恨创新。

Q5：

我反对作者的这个观点，而且反对作者关于这句结论的一个设想。

作者说：假设你发明了电报，创办了电报公司，并花费毕生的精力建起了覆盖全国的电报网。这时有个年轻的发明家上门推销他的创新——电话。这个早期的电话看起来其貌不扬，后面还拖着一条尾巴。可是你敏锐地看到，这个创新将会颠覆目前的电报产业，它预示着你辛辛苦苦建立起来的电报公司将会失去市场，这是你会怎么想？会不会恨这个发明？

依我的看法，作者的结论是错的。这并不是说有些创新者不喜欢创新或者恨创新，这根本就是利益冲突的问题，是一个创新者的利益被另一个创新者所破坏，不是不喜欢创新或者恨创新。单就创新而言，若创新者不喜欢创新抑或恨创新，那他如何创新？他如何实现创新？他做不了，他根本就不会成为一个创新者。