再接再厉
| 这个作业属于哪个课程 | 2021春软件工程实践|W班 |
|---|---|
| 这个作业的要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 1.课程回顾与总结 2.个人技术总结 |
| 其他参考文献 | 《构建之法》 |
Part 1 课程回顾与总结
1.提问博客链接
2.曾经的提问
PSP的特点:
• 不局限于某一种软件技术 (如编程语言), 而是着眼于软件开发的流程, 这样不同应用的工程师可以互相比较。
• 依赖于考试, 而主要靠工程师自己收集数据, 然后统计提高。
• 在小型，初创的团队中, 高质量的项目需求很难找到，这意味着给程序员的输入质量不高，在这种情况下, 程序员的输出 (程序/软件) 往往质量不高, 然而这并不能全部由程序员负责。
• PSP 依赖于数据
• 需要工程师输入数据, 记录工程师的各项活动, 这本身就需要不小的代价。
• 如果数据不准确或有遗失, 怎么办? 让工程师编造一些?
• 如果一些数据不利于工程师本人 (例如: 花很多时间修改缺陷), 我们怎么能保证工程师能如实地记录这些数据呢?
• PSP的目的是记录工程师如何实现需求的效率, 而不是记录顾客对产品的满意度。工程师可能很高效地开发出一个顾客不喜欢的软件, 那这个工程师还是一个优秀的工程师么?
在当时提问的时候，我对PSP的可靠性抱有疑惑，而在现在课程结束后，这个疑惑依然存在，我仍然感觉不到制定PSP表格在开发中的作用，可能是我对它的理解还不够深刻吧。
移山公司的人力资源总监给同学们做了职业发展的演讲，大意是随着软件工具和软件工程理论的发展，开发软件将会越来越容易，软件企业的水平都是CMMi4级以上。软件白领的生活指日可待，金领也不是梦，大家前途无可限量，学软件工程的同学越来越多，就是明证。大家纷纷鼓掌。最后他分享了一个故事：
两个劫匪在亡命的路上看到一副绞刑架，劫匪小弟说，大哥，如果这世界上没有绞刑架，咱们的职业就好干多了。大哥说：你真笨！如果没有了它，这世上做劫匪的人怕是太多，我俩恐怕竞争不过同行，早就饿死了！
请同学们思考这个故事对个人及软件业发展的启示。
当时对这个问题最大的感触是不能回避绞刑架，不能怕卷，要迎难而上，顺应趋势，现在考研感受到了计算机考研有多内卷后更坚定了这个想法，还是那句话，“唯一的出路就是，无论怎么样，都要好好学习，保持自己的就业竞争力，职业好不好干不取决于绞刑架，取决于自己的水平高不高。”
如何结对编程：只有水平上的差距，没有级别上的差异。尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。
结对编程是我之前从来没有了解过的，第一次在书中见到，感觉很新鲜。我的疑惑是，在双方水平有一定差距时，双方拥有平等决策权利是正确的吗？水平差距可能会带来编码过程中的一些分歧，这个时候，双方平等的决策权利可能会导致僵持乃至争论，或者是折中的妥协导致程序不够好。而如果决策权利主要在水平较高的那方，由其主导编程，似乎结对编程好像和一个人编程也没什么区别。
现在回头看对这个问题仍然没有太好的解决方法，这里指两个人水平差距较大的情况。而结对作业二的时候我和我队友水平没有太大差距，都是一个前端一个后端从头开始，加上积极交流，完成任务的效率还是很高的，感受到了结对的好处。
单元测试必须由最熟悉代码的人（程序的作者）来写。
我对此表示同意，单元测试不能离开程序的作者。但我觉得只有作者是不够的，应该尽量有其他人的参与。因为在之前的开发、测试过程中，作者本身的思维可能已经固定，考虑到的只有之前测试的固定几种情况，不会再想到更复杂的错误情况，会把它们漏掉，从而带来后续的隐患。比如之前的一个扑克小游戏，我已经对扑克类等进行了多次测试，用户的输入方面也做了较多的输入合法性检验，但当我让同学试玩时，他轻易地炸出了下注可以输入中文、负数等情况，这是我完全没有想到过的。有时候别人确实可以考虑到意料之外的状况，这点应该引起注意。
就像那个著名的计算机笑话，“测试们心满意足地离开了酒吧，顾客点了一碟炒饭，酒吧炸了。”
经历过结对作业和alpha阶段的测试工作后对这个问题有了更深的感触，测试真的是一件很严谨的事，对于单元测试白盒测试这种需要对程序具体结构有所了解的测试还是由最熟悉代码的作者来，而其他更多方面的测试则需要比较熟练的测试人员来完成，这样才能找到程序员本人容易疏忽的漏洞。
文章中有提到过早优化这一问题，认为是思维误区，但它似乎也能带来一定的好处。与全部程序完成后再去寻找可优化部分相比，在编写程序的每个模块时尽量对其进行优化，提高性能，最后省事一些。在多人协作的项目中，有时写完的这一模块也很快会被他人调用，这个时候已经优化过的模块就能提升大家的效率。
如何选择优化的时机呢？
现在觉得不要过早优化，最大的感触是一个项目必须先努力做到基本功能全部达到，能正常运行保证交付，之后针对局部，大家集中优化，这样不会对开发中的队友造成困扰，出现意想不到的bug。
3.每个阶段的收获
需求
在需求分析阶段大家集思广益，详细地分析和考虑用户的直接需求和潜在需求，很周到地考虑了各种情况，建立了NABCD模型，这对我日后开发进行需求分析很有帮助。
设计
这部分进行了各种设计如原型设计、数据库系统设计等等，深刻地感受了一个项目从想法的提出到渐渐有血有肉，出现大致骨架的神奇过程，这阶段绘制了一些系统设计有关的图，对它有了一定的了解，也从擅长设计数据库的队友那里学到了很多。
实现
这部分进行了alpha阶段和beta阶段的冲刺，这阶段的基调都是学习新技术和磕磕绊绊地写代码（抱大腿），这阶段中最大的收获是对SpringBoot以及Mybatis这些后端技术更加熟悉了，也能照葫芦画瓢写出一些能用的接口并进行错误排查了，总体来说还是收获很大的。
测试
最大的收获，测试真的是很严谨的一件事，不像以前认为的随便测测，不仅要考虑正常情况更多的还是要考虑异常情况，并且测试是要在对代码有一定熟悉程度上才能做的，测试一些队友写的不熟悉的代码时要频繁询问细节，非常麻烦，然后工作量也不小，比如进行API测试的时候测试了60来个接口，也算是有所熟悉吧。
发布阶段
这里倒是没有什么收获，主要是找找软件中的bug以及想办法推广，了解到发布后用问卷及时回收用户反馈也是很重要的。
4.心得和收获
总体来说一学期下来收获还是蛮大的，主要是更熟悉了SpringBoot和Mybatis等技术，也体会了和队友结对开发以及团队开发的过程，看着一个项目慢慢长大的过程还是很棒的，算是神奇的体验吧，然后ddl真的多啊！！对考研人真的不友好！好在现在终于可以认真考研了...