提问回顾与个人总结
这是北航计算机学院软件工程课程2020春罗杰老师班提问回顾与个人总结作业。
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 课程链接 |
| 这个作业的要求在哪里 | 作业链接 |
| 以前提问题的博客 | 博客链接 |
提问回顾
在学期开始的时候布置了阅读作业，同时提出了自己的问题， 现在根据这学期的学习，尝试对自己曾经提出的问题进行解答 。
代码设计规范
4.3.2一节中提到
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto 。
这个问题有关代码规范，在我目前学习和使用经验中都是极力避免使用goto的，各种资料说goto语句 破坏程序的结构化，降低了程序的可读性，我上学期的编译器中有使用goto的需求，但最后基本通过循环或增加变量的方式避免了。所以我对程序的逻辑结构、清晰可读性的具体方向还有疑问。
代码设计规范的目的就是使程序的逻辑结构清晰可读。书上这句话的核心是使函数有单一出口，对于一个比较大的项目代码，这一点即有助于程序逻辑的清晰，又方便后续开展测试（如覆盖率测试），所以这个问题的答案就如上文所说：只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
风险管理
风险是在正常软件生命周期事件之外的、可能发生的影响项目的成功的事件。
美国公共政策和风险管理领域的专家艾伦·威尔达夫斯基（Aaron Wildavsky）说过：没有风险，就是最大的风险。
这句话一般被理解为生于忧患死于安乐，但在本节我觉得这个解释不很合适。个人的理解是工程本身就意味着要承担一定的风险，如果非要追求万无一失、没有任何风险，恐怕将会面临更大的风险，如坐失发展机会、丧失决断力的风险等等。 作者此次想表达的应该与之相同？
其实在问题中我就给出了最初的观点：工程本身就意味着要承担一定的风险，如果非要追求万无一失，恐怕将会面临更大的风险。经过两个阶段的开发过程，我认为这一观点是正确的。比如为了找出一个小问题而延误了整个项目上线的时间，。要减少这样的风险，需要提高PM的领导能力和开发者的个人能力。
Tell mode vs. Ask mode
在讨论如何避免在产品开发后期不断有重大修改，导致其它模块的连锁反应?时书中给出：
在项目早期，如果大家觉得要做一个设计变更，便可以采用告知模式（Tell-mode）的形式，也就是说，修改方必须通告所有关系人：“我在这里修改了某某界面, 我在某个API 增加了一个参数。”但是修改方不必取得其他关系人（或者模块）的事先同意，就是说可以先行设计并编码。当然，如果其他关系人不同意，修改还是不能签入。
当项目进行到稳定阶段，例如达到了代码完成（CC）阶段，Tell-mode 要改为请求模式（Ask-mode），这时，修改方必须先问“我是否可以在这里修改某某界面？”（当然还要有更详尽和充分的理由），得到肯定的答复后，才能进行修改。这时的默认回答是“不”。
如果其他关系人不同意，修改还是不能签入，那告知模式会不会导致项目进度拖延？更严重的如果关键API必须修改，会不会导致大范围重构？
我们组的项目基本采用的是告知模式，在实际操作中基本没有遇到其他关系人不同意的情况，即使是修改的部分需要重构，也可以在相关人员沟通后妥善解决。所以，对于一个设计良好的项目，告知模式确实不会影响项目开发的进度。
创新迷思之三
作者认为好的想法不一定会赢，举了键盘布局和美国度量标准的例子，提出
对利益相关人要讲清楚“你能从中得到什么”。
创新的想法和目前流行的做法相比，有什么相对优势，能让别人清楚地看到这个区别，并能够尝试。
创新和目前大众习惯、已有系统是否兼容。
避免过度描述复杂的技术。
这两个例子似乎都只是不符合大众习惯，因而没有成功。从个人看来创新应该具有颠覆性，如苹果公司多次重新定义智能手机，从而取得成功，越颠覆的产品越能占据市场份额。所以创新应该如何处理旧习惯，怎么考虑兼容性的问题？
一个成功的颠覆应该使得用户的使用体验越来越好，而不是为了颠覆而颠覆。所以创新可以不考虑旧的习惯，但不应该完全违背使用者的使用习惯。每一次创新都应该带给使用者更好、更新颖的体验。
赢者通吃
这个游戏规定第一名得到全部的分数，第二名（不管多接近）到倒数第二名都是0分，最后一名还要倒扣分。软件行业就是一个赢者通吃的环境，最后一名还要把自己的身家倒贴进去。
在这种环境下中小创业者如何发展，竞争软件一定能分出赢者吗？这里赢者吃掉的是定位完全一致的对手，还是行业内的所有软件？用经济学的话说，作者说软件行业是一个垄断行业，那么这种垄断是完全垄断，寡头垄断还是垄断竞争的类型？
在这次项目的发布环节，我们真正体验到了赢者通吃的环境。流量大的项目可以比较容易的推广，而缺少注册量的项目则需要付出更多的精力在推广这一环节上。但是在竞争中最重要的还是自身的实力，所以提出的几个问题并没有正确答案，因为在我们课程这个环境里，各个项目至少还是可以在夹缝中求得生存的。但如果真正在市场上放开竞争，可能流量大者会最终吞并其他人。
新的问题
在开发中我负责前端的部分，也需要经常和后端进行交互，深知一份可靠的文档的必要性。我的问题是一个项目如何产生和维护一份可靠的文档，满足各方开发和测试的需要。
学到的知识点
需求阶段——NABCD分析框架
NABCD分析框架从原始需求、采取做法、给用户的好处、竞争对手和推广方式五个方面进行项目的需求分析，只有明确用户的需求，才能进行下一步的功能设计。
设计阶段——分析需求
功能设计应该针对用户的具体需求，有自己的杀手功能。同时前端界面的设计要谨慎，最好在设计阶段就给出大概的风格与草图。
实现阶段——文档
一份好的接口文档可以在实现阶段省去很多交流的时间。设计良好的接口可以降低代码耦合度，在前后端对接时帮助找出潜在的问题。
测试阶段——单元测试
合理的单元测试是找出bug的好方法。以前我们只是知道单元测试，但在这个项目中我们实际运用了单元测试并了解了它的优点。
前端在测试时应该充分考虑运行环境，不同浏览器可能有不同的支持项。
发布阶段——收集反馈
发布阶段需要做好宣传工作 ，注意收集用户的反馈，最好能根据用户的意见对项目进行修改。
维护阶段——及时维护
发布后除了必要的维护，不应该对项目做出大的改动。这一阶段的重心要放在及时应对各种情况，做好全面的准备，及时维护上。
理解和心得
在这一学期的软件工程课上，我们经历了个人项目，结对编程和两轮的团队项目，不仅训练了开发能力，还学习了团队开发中的各种工作。在开发方面，我主要学习了前端的开发知识，算是掌握了js等基本的前端开发方法。同时也在前后端对接中学习了Django的相关知识，了解到后端的运行过程。
我对于软件工程最深刻的认识就是纯编程的工作在整个项目中并不是最重要的。在软件开发，尤其是像我们这样的团队开发时，团队成员之间的其他工作也起着十分重要的作用。在团队开发时，需要花费很多的时间在设计、讨论、沟通等工作上。而这些工作会为后续的开发工作打下基础。在开发过程中，可以明显的感觉到，这些工作都做得比较充分时，开发工作就会比较轻松。在开发阶段团队也遇到过因为沟沟通等工作做得不够充分，导致后面的开发工作不能很好的进行，但好在最后还是完成了整个项目。虽然在开发过程中遇到了很多问题和挫折，但是我感觉自己收益颇丰。通过这一学期的开发与实践，我对于软件工程开发中各种阶段的工作有了更加深刻的体会，也特别感谢和我一起完成这门课程的各位同学。