提问回顾与个人总结
提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 北航2020软工 | 班级博客 |
| 作业要求 | 提问回顾与个人总结 |
| 我的课程目标 | 学习软件工程相关知识,增强自己的开发能力。 |
| 个人博客 | 提问博客链接 |
问题解答与分析
关于PM
问题1 PM作为一种非常优秀的制度,在行业能广泛采用.那么微软的PM到底和其他公司的PM有什么不同之处?无法被成功拷贝的关键点在哪里?以及一个真正优秀的PM是如何成长的，他们是从猪逐渐演变而来还是从鹦鹉变成的?
在提出这个问题之前我对软件开发的过程只有一个大致的概念性了解，而对于其中的操作细节以及流程的时间方面一无所知。经过这次的软件工程课程，我对PM这个岗位的大致工作也有了一个具体的认识。PM可以说是整个团队中最重要的角色，不但要与各位同学沟通、分工、开会，还要了解前后端的相关知识以及各工作的难点，合理提出开发要点以及设定开发周期时间。最重要的是当员工工作懈怠或者出现较大问题时还要心平气和的和开发者进行沟通，必要时甚至要自己上场。
一个好的领导者的特质是难以被拷贝的，要点不仅在于专业知识上，还在于为人处世的风格上。此外一个优秀的PM可以从猪也可以从鹦鹉演变而来，关键是他必须做过或者充分了解过猪和鹦鹉的相关工作，否则无法做出正确的管理决定，成为一个优秀的领导。
关于软件工程结构
问题2 根据理论描述,软件工程包括了软件需求分析, 软件设计, 软件构建, 软件测试, 和软件维护。然而在现实生活中,对于一些规模比较小的公司,由于人员限制或者业务比较基础单一,并不需要那么多的流程和步骤,或者由于人数或者专业水平不够无法达到完整的流程。那么在现实工作中对于不同的业务哪些流程可以被简化甚至舍弃?以及是否存在只专注于单个或几个流程的外包公司?若存在,那么外包方和承包方是如何进行交流以及验收成果有效性的?
这一问题得到了助教的回复
百度、华为这些大公司基本都有外包团队，对于技术要求不高的某些工作（比如某些组件测试），会分配给外包团队。
关于外包公司的工作流程比如：我在华为做外包的真实经历
通过阅读相关资料，我了解了大量关于行业内外包工作的相关知识。总体上来说外包就是将大量技术含量低的工作委托给其他公司处理并对反馈结果进行验收。从外包从业人员的自述中可以看出外包行业相较于原公司级别较低，工资、工作环境以及工作作息相较于行业内平均水平都偏低。且外包公司的管理制度较为严格，目的是确保原公司的相关资料内容不会外泄。
代码规范
问题3 在博客讲义的代码规范上讲到了goto语句的一些使用注意,即在单一出口下可以被合理使用。但是我一直看到的建议大多是禁止goto语句的使用。同时何为一个良好的编程逻辑对于不同人的认知可能不太相同。那么作为一个leader时如何确立一个合理正确的代码规范?
根据Dijkstra在上世纪发表的论文，goto语句会破坏程序的结构，从而使得程序可读性和可维护性变差。然而，通过阅读大量其他相关内容，我发现goto语句并没有随着该理论的提出而消失，而是得到了非常广泛的引用。甚至出现了项目因未使用goto语句导致bug出现的情况(https://blog.csdn.net/cpq37/article/details/47342665)。对此我进行了一个简单的总结,goto语句在理论由于其过度的灵活性无法很好的融入程序理论分析结构中，导致在进行程序分析或者编译器优化时由于无序的结构难以处理goto语句。而在现实应用中goto的灵活性使其很好的融入到程序编写过程中。只要使用得当反而能够使得整个程序语句更少，结构更加清晰。
新问题
PM如何在组员人心涣散的时候有效的鼓励团队气氛?同时如果出现个别组员进度落后时是选择主动帮助，还是采取其他措施?
如果一个团队开发项目时对于项目所使用到的技术并不熟悉，同时时间并不允许他们将大量的时间用于开发前的学习中，那么整个开发的流程该如何安排?如果开发时出现了较大的技术问题该如何处理?
学到了什么
需求
对于一个比较大型的项目，我认为这是整个软件开发流程中最重要的一环，直接决定项目的可用性以及合理性。在此阶段需要考虑大量的相关内容，包括具体的实现目标、开发日程、可实现性如何、可使用的资金、人手等大量内容。在我们组的项目中，由于第一阶段需求确立的并不是很好导致开发出的成果并不是很尽如人意。而在beta阶段中吸取了alpha阶段的教训，重新进行了需求分析，有效地推动了后续的开发进度。
设计
在确定了需求之后就要进行整个项目的设计。主要包括3个部分，包括项目规格说明书、开发接口说明书以及分工安排。在beta阶段中，我们的PM将全部的内容划分成了3个部分分别进行开发。同时我负责撰写前后端的规格说明书以及接口说明书。通过我的实践，我认识到项目的设计者应该是整个项目中技术水平较高的人员，需要对前端和后端的内容都有比较深刻的理解。技术规格说明书在我们的项目开发中并没有得到比较广泛的使用，我们采取的方式是通过演示和口述的方式让其他成员理解项目的大致内容。当然对于规模比较大的项目肯定不能采取这样的方法。
实现
对于前端和后端同学，实现的主要内容主要就是代码的撰写部分。通过我的实践，我发现在编程时需要考虑到的问题还是比较多的。例如虽然能够做到前后端分离，但对于开发者而言依然需要同时了解前后端的一些基础内容，否则会出现沟通上的较大问题。同时尽管在设计阶段接口文档已经撰写完毕，但前后端同学对其的理解可能会出现一定的偏差，需要通过反复核查以及沟通解决相关问题。
测试
我们的项目主要通过代码复查、代码覆盖率测试、回归测试以及实际项目的使用来确保我们所开发内容的准确性。由于我们的项目组在需求以及设计阶段都没有制定完整的测试计划，大多采用的是不同模块的开发人员对自己的项目进行测试，导致在整合时形成的项目质量并不如人意，出现了大量的BUG。从中我意识到测试应该是整个项目开发中不可或缺的一部分，不能因为对于功能的追求放弃了程序的正确性。
发布
项目的开发的最终目的就是号召用户来使用它。如果推广不到位，那么整个开发过程就像在闭门造车，毫无意义。因此必须积极拓广渠道将所开发的内容推销出去。
维护
项目上线后，需要根据用户反馈积极修复BUG，改善用户体验。另一方面需要不断检查软件的运行情况，避免无法登陆以及数据库丢失等重大问题出现。
理解与心得
个人项目
个人项目的难度并不高，总体上就是编个程序。但由于需要严格遵循软件开发的流程，体验感还是和数据结构中的编程截然不同的。在编程之外，还需要确保程序的模块化、可读性、可扩展性以及通过各种手段确保其正确性。在此过程中我还抛弃了一直使用的dev c++，学习了visual studio的相关知识。该项目让我意识到软件工程并不只是编程那么简单，需要考虑到的内容还是相当多的。
结对项目
结对项目是在个人项目的扩展。由于我个人项目的可扩展性较好，其实我认为我一个人就能完成所有内容。但由于课程的要求，我和另一位同学组队完成。总体上还是比较顺利的，我负责代码开发部分，他负责进行代码的复核以及测试。在测试过程中他采用的是黑盒测试法，使用.exe文件进行测试。而我作为项目的开发人员进行了一系列的单元测试。在此过程中我感受到了软件开发中1+1>2的力量。由于无法面对面编程，因此体验并不是十分完美，但也还行。
团队项目
在alpha和beta阶段中，我主要负责接口文档的撰写以及后端生成函数的实现。工作主要分为3个部分，第一部分是学习pytorch、django开发的相关内容，并阅读前人的代码，理顺项目的实现路线。第二部分开始进行正式的开发，编写代码生成函数，并撰写前后端的交互文档。第三部分与前端同学进行对接，debug并修改接口文档中不太合理的部分。在软件开发之外，我还需要在每次的会议中汇报自己的工作进度，并且和其他开发人员积极沟通。总体上收获还是比较大的。
