| 这个作业属于哪个课程 | 2020春|S班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 个人作业——软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 回顾这门课程带来的提升、团队总结、实践中的经验总结、对下届同学的建议、个人技术总结 |
| 作业正文 | 个人作业——软件工程实践总结&个人技术博客 |
| 其他参考文献 | Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605 |
一、回望
1. 对比对课程的目标和期待
通过软件工程实践，让我对许多开发中使用的技术和管理方法都有了一定的了解，比如说使用github管理项目代码，使用leangoo管理团队项目进展并绘制燃尽图；以及安卓开发工具和对应的一些开发技术，还有单元测试等测试方法；墨刀、Axure等原型设计平台和软件；还有《需求规格说明书》和《系统设计说明书》的内容需求和撰写方法等。同时还提升了许多技术之外的能力，比如设计合理的问卷调查的能力、对问卷进行数据分析的能力、听取其他小组展示发现问题并提出问卷的能力、与小组组员和组长沟通交流互帮互助的能力等等。总的来说，在了解软件工程项目开发方法、学习一些新的开发技术、合作开发一个比较完善的项目，提升自己的竞争力方面达到了自己的预期，但是在提升自己编程能力、测试能力方面虽然有所提高，但离自己预期还稍有差距，略显不足。
2. 对比之前的预期值
在绘制个人简历时，希望能够合作开发一个比较完善的工程，而团队项目“Jizm”记账软件实现了这个期望，但是预期的技术和技能却没有达到。因为当时个人意向是prefer Web端开发和数据库相应知识，但是因为在项目中有对Web端比较熟悉的开发者，同时安卓端是我们项目的主要部分而且缺人，因此我就去学习了安卓相应的开发知识，完成登录、注册、找回密码三个部分功能。但我完成的部分既不涉及Web端开发和数据库相应知识，也没涉及到我如果打算读研可能研读的网络安全部分的内容。虽然我们的项目确实要考虑数据的安全性，但当时分配任务时并没有思考太多，也没有专门需要人负责这部分内容，因此有所遗憾。
3. 印象最深的一次作业
其实对于我来说有三次作业印象都很深，我觉得它们难分伯仲，让我一时之间在这三者难以抉择，故打算都说一说。
- 软工实践寒假作业（2/2）
这次作业是在寒假，而且是个人作业，代码量和工作量等对于一次两个周的个人作业来说还是比较大的，而且github也是第一次使用，同时开发采用的java语言由于本身就学得不是特别好再加上时间长了很生疏，因此一时之间很难着手开始完成作业。同时当时在实验室的老师也要求修改论文和汇报文献，时间挺紧，给我的压力很大。如果说让我印象最深的原因，主要还是在基本实现过后测试的时候，我没看懂助教给的测试日志，导致我以为我的代码有bug然后疯狂Debug。Debug三小时未果崩溃后发动我的两位高中同学帮着我一起Debug，其中一位更是陪着我通宵在改（没办法，快要到ddl了，本来以为时间差不多刚好，结果遇见了“bug”）。最后天都亮了我俩也没改出来，崩溃放弃过后去睡觉。醒来过后，可能是自己清醒了吧，发现那根本不是“bug”，只是我理解错了测试数据，导致通宵改了一个不是“bug”的“bug”。事后特地在空间发了说说，感触很深。（截图附下）
- 团队作业第二次——团队Github实战训练
这个对于我们团队来说应该都挺有感触的。因为在github实训时我们组刚组起来不久，大家对彼此的能力都不熟，而且时间也很紧，再加上线上的缘故等多方面的原因，我们组未能完成这次实训。这次实训对我们组不少成员都有不同程度的打击，包括我自己需要完成的部分也完成得不是很好，展示的时候组长也有点像检讨一样，让我心里挺难受的。总之那一天就是身心俱疲+备受打击。 - alpha冲刺
alpha冲刺的每次会议迅速的让我们团队成员之间的关系好了起来。对于我来说，由于当班长同时又在准备保研，课也不算少，所以能花在软工实践上的时间确实比较少，再加上alpha冲刺我既要学安卓端开发，又要学服务器端开发，所以虽然自己需要写的代码不多，但是由于学习成本太高，没有完成得很好，给团队拖了后腿。这之后我其实觉得挺内疚的，所以有一些力所能及的事情希望能帮团队多做一点吧，好在组长很包容，并没有责备我alpha冲刺服务器端做得不好，反而帮助我完成了这部分内容。因为自己能力的缺乏很多人帮助了我，也不乏熬夜改代码、在加上自己的内疚，因此印象很深。
4. 课程问卷个人记录
| 问题 | 回答 |
|---|---|
| 统计一下，你在这门软件工程实践中，一共完成了多少行的代码 | 2000-5000行 |
| 各次作业分别花了多少时间？ 软工实践寒假作业（1/2） 软工实践寒假作业（2/2） 结对第一次作业 团队第一次-团队和项目展示 结对第二次作业 团队Github实战训练 团队作业第三次—项目需求分析 团队第四次——系统与数据库设计 个人作业——软件评测 团队第五次——alpha冲刺 团队第六次——beta冲刺 软件工程实践总结&个人技术博客 |
合计：194.08小时 7小时 26.33小时 13.75小时 4小时 12小时 12小时 6小时 4小时 9小时 60小时 30小时 10小时 |
| 累计花了多少个小时在软工实践上？平均每周花多少个小时？ | 加上alpha冲刺前的学习时间和每次交作业焦虑烦恼的时间，应该有240小时左右吧 从寒假算差不多20个周，平均每周12个小时左右 |
| 学习和使用的新软件 | Axure、Android Studio、desktop-Github、Typora、Xmind |
| 学习和使用的新工具 | Mobtech（短信验证码功能）、word（文本编辑、调整格式等比以前精进了一些）、google schoolar和dbip、知网（这次作业查文献） |
| 学习和掌握的新语言、新平台 | Abdroid开发、Android Studio、github、leangoo、博客园 |
| 学习和掌握的新方法 | 单元测试、安卓实现短信验证码SDK使用 |
| 工程能力的提升 | 完成了一个项目能力肯定有所提升，应该就是主要是提升了自己的开发能力、使用一些管理项目的软件以及给了自己能够与小组一起完成一个工程的信心吧。还有就是体验了一个工程从诞生、需求分析、设计等完整的流程 |
| 团队合作上的提升 | 能够更加配合团队完成自己力所能及的事情，还有就是明白了要预先估计自己的时间和能力来接受和完成任务，不然会给团队拖后腿 |
| 其他方面的提升 | 提升比较显著的应该就是我的抗压能力了吧，还有就是对软件的测评，比如设计一个合理的问卷等 |
二、团队总结
1.你是组员还是组长？你觉得你自己在哪些地方做得好？你觉得自己还有什么可以改进的地方，具体可以怎么改进？
- 组员
- 做得好的地方：
- 积极配合组长的任务分配，努力完成自己的部分。
- 遇见困难，比如发现springboot来不及学习可能完不成服务器端部分，及时反馈给组长和组员想办法。
- 与其他团队成员互帮互助。
- 可以改进的地方：
- 遇见组长分配的任务直接接受。改进方案：在组长分配任务时，应该先提前了解一下这个任务需要学习什么，自己有没有足够的时间和能力去学习好，做好预估。比如说我在alpha冲刺的时候，组长让我负责登录的服务器部分代码，当时我觉得可能跟安卓联系比较大，确实也算是自己之前就分配的工作，就直接答应了。后面才知道是用springboot框架写的，由于没有足够时间学习新框架内容，导致没有完成自己的任务。
- 很多时候都没有准时完成任务。改进方案：一定要预留一部分时间，比如说觉得登录和注册差不多，所以就预计花不了那么多时间，结果在写的时候遇到BUG导致没有及时完成。因此不要盲目自信，要尽早开始完成，并且要预留时间。
2.你觉得你的组长（组员们）在哪些地方做得好？你觉得ta（ta们）还有什么可以进一步提升的地方，有什么具体的建议吗？
- 做得好的地方：
- 我觉得他们都很靠谱，都较好的完成了自己所负责的部分，责任心也很强，也懂得互帮互助，也不会抱怨这抱怨那，团队的氛围也很好。
- 很配合彼此的任务。
- 进一步提升的地方
- 希望组长分工可以更合理一点，结合难度、学习成本、个人能力等综合分工。
- 其实可以稍微减少工作量，完成四个端确实有点辛苦大家了。
3. 《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
- 萌芽阶段：
有经过萌芽阶段，也就是团队第一次作业，选题的时候。每个人才刚刚聚集在一起，都很陌生，所做的事没有被记录下来，同时大家也没有很积极的发表自己的观点和意见，有一定的陌生感，做事的规程往往被忽略。 - 磨合阶段：
有经过磨合阶段，团队第二次作业就完成了这一个阶段。在github实训的时候，由于时间的紧迫性，大家完全破冰了。虽然过程中有过矛盾和冲突，最终完成得也不是很好，但经过这一次作业让整个团队彼此更加熟悉、距离感也更近，成功渡过了磨合阶段。 - 规范阶段：
后续的历次作业我觉得都达到了规范阶段。团队的工作流程和方式大家都比较认可，也有了一些成文或不成文的规则，团队的信心也逐渐找回来了。但是甚至到beta冲刺结束，我认为我们团队离创造阶段都还有一点距离。
4.从开发的角度，你在团队中担任了什么角色？你是否完成了该角色的任务？现在你觉得你适合该角色吗？
我担任了安卓端登录、注册和找回密码三个功能的开发，以及部分博客撰写还有问卷设计和评分的角色。我没有完全完成该角色的任务，尤其是开发部分，服务器端没有完成。我觉得我比较适合该角色，但是由于学习成本比较高，所以导致我没有完全完成该角色的任务，因此不是特别适合。
三、人月神话
团队
1. 怎样证明你学会了软件工程？以下要求你们的团队达到了哪几个？
i）研发出符合用户需求的软件
软件开发结束过后我们有发布软件让其他同学使用并填写问卷，
问卷情况链接：用户体验报告
根据问卷情况可以得知，我们的软件达到了用户量，但是没有做到持续使用量
ii）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
根据软件工程实践课程的安排，我们团队有项目规划/需求/设计/实现/发布/维护，有定时的进度发布。
我们团队有项目规划/需求/设计/实现/发布/维护，有定时的进度发布。
(1) 项目规划
时间线
(2) 需求
项目需求分析
软件需求规格说明书
(3) 设计
项目系统设计与数据库设计
下面给出原型界面的部分截图：
- 移动端：
- 登录成功后就可以使用记账功能，APP对账目类型已有我们设定的分类，用户可以根据自己的喜好进行分类的更改。
- 可以选择查看本年、本月或本周以及自定义日期的账单报表与消费趋势了解自己消费结构。
- 用户可以使用软件提供的自动记账功能减少手动记账的次数，其中有周期记账和导入文件的选项。其中导入文件是需要在web端进行操作。
- 在个人界面可以修改个人信息、查看个人钱包、根据服务器存储的数据进行恢复、更新本地数据库、将账单导出发送至邮箱以及设置。
- web端：
- 登录成功后可以查看账单，默认类别分为支付宝账单，银行账单，其他账单，可以在界面查看日期、款项、金额，还可以删除某一条账目，此外还可以新增账单。
- 还可以查看类别统计和收支统计 。
下面给出原型链接，感兴趣可点击查看:
- web端原型
- 移动端原型
(4) 实现
整体开发实现部分分为alpha和beta冲刺。
alpha冲刺任务和计划
beta冲刺任务和计划
十天冲刺实现的博客合集：alpha冲刺博客汇总
七天冲刺实现的博客合集：beta冲刺汇总
每天的冲刺都会有每个成员的任务进度汇总，有实时的任务跟进，每天也有燃尽图。可以证明我们的项目是在一步步慢慢推进的，有规律有计划。
(5) 发布
发布过后设计问卷进行调研
问卷情况链接：用户体验报告
iii) 并且通过数据展现软件是可以维护和继续发展的
我们的实现都是基于github平台汇总代码，每次都有标明意义的提交，可以方便后续维护和修改
安卓端仓库链接
Web端仓库链接
ios端仓库链接
我们也有发布代码规范，对于之后若有修改维护的部分则很有利，也方便新加入的成员读懂我们的代码。
代码规范
个人
2.1 个人实践
个人实践基本都是以博客为主的总结测评或者自我定位，只有一次编程项目是个人完成的。个人实践相对来说时间安排比较自由，可以自己按照每天的实际情况安排工作，缺点就是需要自己完成所有的任务，包括编写代码时，如果使用的技术和命名的约定各个同学不一样，遇到问题和BUG自己难以处理的时候也不方便寻求帮助。
经验总结：主要是要合理规划好自己的时间，写博客要条例清晰，写代码也要头脑比较清醒的时候写，不然会遇到我在寒假第二次作业时理解错数据而改了一个通宵不是BUG的“BUG”。
2.2 结对
结对作业概括来说是做的疫情可视化的网页。
经验总结：第一次结对作业主要是学习原型的使用，对于一个陌生的软件我个人确实上手比较慢，如果有已经比较熟练的人教一教应该会更快上手。随后就是原型的实现，如果使用框架的话应该会更美观，但是当时由于视野和水平有限，就没有使用框架，导致成品的美观度较低。
具体原型和实现过后的成品可以查看下面博客中的gif动图：
原型设计
实现
2.3 团队合作
真正意义上的第一次和团队进行合作开发一个项目，总是担心自己技术不够会脱队伍后腿（但好像这个担心最后还是成真了）
经验总结：
(1) 不要盲目接受分配的任务
就像之前说的，在收到分配任务时，应该先提前了解一下这个任务需要学习什么，自己有没有足够的时间和能力去学习好，做好预估。比如说我在alpha冲刺的时候，组长让我负责登录的服务器部分代码，当时我觉得可能跟安卓联系比较大，确实也算是自己之前就分配的工作，就直接答应了。后面才知道是用springboot框架写的，由于没有足够时间学习新框架内容，导致没有完成自己的任务。
(2) 培养自学能力很重要
由于我们打算ios端、web端和安卓端都开发一个可用的应用出来，组内有已经比较熟练web和ios的同学决定一人承担，服务器端也主要由组长负责，于是其余同学合理共同学习安卓端开发。在学习安卓端开发过程中由于开发与java类似，学起来就比较得心应手，但是在组长分配给我一部分服务器端任务时，我在自学springboot遇到了很大的阻碍，可能是因为基础不牢，导致没有完成。其实许多技术大家多多少少都是需要看书自学、百度找资料学习，因此基础和自学能力就尤为重要。而且计算机行业的技术更新迭代得很快，自学的能力在今后的学习和工作中也十分重要。
(3) 仔细阅读文档
由于负责了注册等界面，需要完成短信验证码功能，而短信验证码一般是由其他企业提供SDK和接口。而在使用时需要查看提供的开发文档，但是在使用的时候由于没有认真查阅，导致开发完成后，组员集体使用APP测试时，出现了短信收不到的情况，以为是BUG，后面排查不出来过后仔细阅读文档才知道免费的短信验证码每天只能接受20个短信。
(4) 命名规则严格按照要求
在后续优化界面的时候，由于使用了新的安卓组件，安卓负责人家榜同学就对界面的组件进行了修改，后续我们再将逻辑部分代码进行修改。在我对逻辑部分进行修改时发现，我和家榜同学的命名虽然意思上是大致一致的，但是确实变量名改变了，在后续的修改时就遇到了一些麻烦，降低了代码维护和升级的效率。这就是没有严格按照要求进行变量命名所带来的后果。
四、 建议
1. 对于下一届同学，或者大一的同学，你想说：
- 基础很重要，希望能在大一大二就能练得良好的编程能力。就软件工程实践这门课而言，确实是一个提升编程能力、了解开发具体情况、学习软件工程开发方法的好课。但是这门课安排在大三下，同时作业占用大家的时间确实也比较多，因此我希望同学们找准自己的定位，思考一下这门课能给自己带来什么。当然完成课程的基本要求是必须的，但是如果特别需要这门课的同学，比如说打算就业搞开发的同学，这个课程带来的项目经验是宝贵的，应当倾注自己更多的心血。
- 就定位而言，我想要仔细说一下。我觉得找准自己的定位，想好自己想做什么特别重要。比如说，自己是想要进工业界搞开发还是进学术界搞研究异或是考公、转行，想要进工业界搞开发是想进大厂还是想进国企，是想本科毕业直接就业还是想读研读博过后再就业。读研是想要考研、保研、亦或是出国，想要专硕还是学硕。保研是想硕士还是直博，方向要选择什么。总的来说，给我们的选择实在是太多太多太多太多了，越早知道自己想要什么，就越能有明确的目标为止努力。比如说，你想要搞开发，那多参加项目提升开发能力，比如说进入“西二在线”、“服务外包”实验室等，对软件工程实践这门课也应该倾注更多心血努力学好；如果想搞研究，那你是想研究什么领域什么方向，是不是可以进入研究生实验室或者与导师一起做一些课题和研究，发一发论文；如果是想出国，那最好大二就开始学雅思托福；如果是想考公，那是不是应该考虑入党；如果是想转行，那选择什么专业，需不需要辅修、旁听这些都是应该考虑的。总之，我的建议就是，仔细思考自己想要做什么，对什么感兴趣，多了解了解专业领域内的东西，而不是仅限于书本，觉得考的成绩越高越好即可，这样视野太局限很影响未来的选择。选择很多，但真的很重要，在选择前了解得越多，选对的可能性就越大。
2. 对于自己今后，你有哪些建言？
就像上面说的，我至今都比较迷茫自己想要什么，还没有找到自己的定位。因此我希望自己能早日找到自己的定位并为之努力吧。另外就是希望能提升自己的自律能力和抗压能力，因为经常会给自己一些压力，甚至还没有开始软工实践的作业，光是看到作业博客就觉得好难完成，然后就莫名会有一种放弃的念头，然后就开始放纵自己。自律真的很重要，从高中起我就认识到了，因为班级同学都特别优秀，也很自律，而我就像班主任所说的“不知道自己真正想要什么”，从而没有动力去严格要求自己，最终高考成绩并不理想。在软工实践中我再次认识到，一旦开始放纵自己，就越来越难收拾，再加上放纵过后又觉得更加完不成作业，几乎就是一边焦虑一边放飞自我。所以希望在以后的学习工作和生活中，能够找准自己的定位，更加严格要求自己，提升自己的抗压能力，能积极乐观地面对困难和一些突发情况。最后，这一年中有同学不幸过世；有姨丈得重病；有姐姐生孩子脑出血；包括我也是皮肤病一直困扰着自己。所以觉得还是身体健康最重要，不管怎么样不要给自己太大压力，也不需要有多成功多有钱，只要有良好的作息，保持身体健康就可以了！
3. 对于助教工作，你有哪些建议？
总的来说助教做得都挺好的，而且看我们的博客还要评论也很辛苦，尤其是徐明盛助教，给我的印象很好，反正我很喜欢他哈哈哈哈！唯一的建议就是希望每次作业结束后，助教都能给出实时的成绩，这样我就不会在beta冲刺结束过后担心自己会挂科的情况出现。
4. 对于软工实践课程，你有哪些建议？对于软工实践课程的上课形式和内容，你有什么具体的意见和建议？在哪儿需要强化或者剔除
- 建议：
随机组队确实随机性比较大，导致各支队伍的实力可能会出现不平均的情况，更极端清苦可能会有某一直团队的所有成员的开发能力都比较弱，这样对于整个小组来说，项目的开展可能会困难重重，会对整个团队造成不小的打击，就像我们小组在github实战训练时一样。因此希望老师和助教再思考思考随机组队是否有改进的方案。 - 上课形式：
希望能优化一下课堂展示。第一是确实可能是同学不好意思，有时候其实会有一些意见和想法或者说是疑问，但是会不好意思提出来。第二就是11个小组展示，尤其是像alpha冲刺展示和beta冲刺展示，全部结束一上午就过去了。经常是来不及休息，尤其是评分的人员，可能连上洗手间、吃午饭填肚子都来不及。（如果说是2个人评分互相分担一下的的话，可能评分标准不一样，难以评出合理的分）所以希望老师和助教能思考一下如何强化。
五、 个人技术总结
在第一次作业“准备篇”中你为自己制定了学习路线，现在学习了怎么样了？你在团队开发中是否担任了开发角色，你在开发中解决了哪些技术问题？获得了哪些技术进展？
很遗憾，在项目中开发我并没有承担前端开发，而是学习了安卓部分的开发知识，基本上是入门了。我在开发中主要是解决了短信验证码验证注册的功能。
使用MobTech平台实现免费的短信验证码验证功能
概述：使用短信验证码验证注册、登录和找回密码几乎是每一个APP、甚至是许多网页所需要支持的技术。对于我们学生完成非商用项目，往往需要一个免费提供短信验证码技术支持的SDK，而许多平台需要收费，很难找到适合的平台。
六、 阅读笔记
参考论文文献：
[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605
文献链接
本文主要研究了软件质量特性时建立了一个概念框架和一些关键的初步结果，其主要结果和结论有：
- Explicit attention to characteristics of soft- ware quality can lead to significant savings in software life-cycle costs.
The current software state-of-the-art imposes specific limitations on our ability to auto- matically and quantitatively evaluate the quality of software.- A definitive hierarchy of well-defined, well- differentiated characteristics of software quality is developed. Its higher-level struc- ture reflects the actual uses to which soft- ware quality evaluation would be put; its lower-level characteristics are closely corre- lated with actual software metric evaluations which can be performed.
- A large number of software quality-evaluation metrics have been defined, classified, and evaluated with respect to their potential bene- fits, quantifiability, and ease of automation.
- Particular software life-cycle activities have been identified which have significant lever- age on software quality.
本文提出了一个清晰，定义明确的框架，着重强调了软件质量，并提出关注软件质量的特性可以大大节省软件生命周期成本；建立了定义明确，差异明显的软件质量特征的明确层次；定义，分类和评估了大量的软件质量评估指标；确定了特定的软件生命周期活动。
本文首先介绍了代码质量的特征，并给出了软件质量特征树.
随后介绍了衡量代码的质量，说明当前的软件最新水平对我们自动化，定性地评估软件质量的能力施加了特定限制,并给出了三个表并从标准CS-13进行衡量，评估代码质量的自动化和半自动化，鲁棒性和自包含性等。
然后研究了利用质量特性改善软件生命周期过程，说明关于它们的潜在利益，可量化性和自动化的简易性，已经定义，分类和评估了许多软件质量评估指标。并提出了质量保证活动的职责通常包括：
- Planning - Preparation of a software quality assurance plan which interprets quality pro- gram requirements and assigns tasks, schedules and organizational responsibilities.
- Policy, Practice and Procedure Development - Preparation of standards manuals for all phases of software production, including requirements, design, coding, and test, tailored to specific project requirements. A key point here is at- tention to quality provisions early in the software life cycle.
- Software Quality Assurance Aids Development - Adaptation and development of manual and auto- mated procedures for verifying compliance to software functional and performance require- ments and project quality standards.
- Audits - Review of project procedures and docu- mentation for compliance with software develop- ment plan standards, with follow-up and docu- mentation of corrective actions.
- Test Surveillance - Reporting of software prob- lems, analysis of error causes and assurance of corrective action.
- Records Retention - Retention of design and software problem reports, test cases, test data, logs verifying quality assurance reviews and other actions.
+Physical Media Control - Inspection of disks, tapes, cards, and other program-retaining media for verification at all times of physical transmittal or retention, and assurance that contents are not destroyed or altered by en- vironment or mishandling.
根据文献作者的数据表明，在分析一个大型项目的验证阶段发现的软件错误时，在对一个大型项目的验证阶段发现的软件错误进行的分析中，我们确定可以通过适当的设计检查技术尽早消除58％的错误。 Fagan在一个控制良好的项目上的结果表明，执行检查所付出的额外努力使操作错误减少了23％。
粗略阅读文献过后（我目前阅读英文文献确实比较吃力，再加上比较理论，只能粗略感受），我认识到了关注软件质量的重要性。并且认识到自己编写的代码质量不是特别良好，虽然说不上是个大泥球，但也是个小土块。
就像文中提到的，我们可以通过适当的设计检查技术尽早消除58%的错误。这一点我还是比较有体会的，一是我在完成软工实践寒假作业（2/2）时由于对要求的理解错误，导致了误认为代码有BUG，然后花了一个通宵修改不是BUG的“BUG”。在软件即将交付的时候，如果遇到像我这样理解错误或者是因为一个技术没有检查而导致的致命BUG，往往所付出的时间和代价是致命的。而是我在beta冲刺时，小组的家榜同学美化界面时使用了全新的组件，他对每个部分的组件进行了修改，并且变量也进行了命名。而后续其他开发人员就要将逻辑部分代码填充进去，但是在填充时我发现家榜同学的变量命名和我的变量命名虽然大同小异，但这存在的差异确实对我进行逻辑部分填充造成了一定的困扰。归根结底就是我们没有严格按照文档规定的变量进行命名，如果说变量命名一致的话，基本上对软件进行升级只需要改一下关键字、标识符等就行了，不用修改变量名，会为后期维护和升级节约不少的时间。这也是软件质量的一部分，如果都能尽早消除，那程序员加班的几率就会大大降低。同时，关注产品的设计和代码的质量，包括可维护性等，是成为一个优秀的项目组长或者是产品经理的必备能力，对于未来想要转入产品岗的我来说，是个必须学习和掌握的本领。