回顾，再出发

作业要求：

• 链接到以前提问题的博客
• 请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。
• 是否原来的问题还不明白？如果有，请分析。
• 是否产生了新的问题？如果有，请提出。
• 软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。
  • 请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点即可。
• 结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。

序

​ 2020年3月3日下午16:48，在博客园发表了本学期软件工程的第零篇博客——停下来，回头看 ——记2020BUAA软工第一次作业-热身！ ，1万5千字的长文收获了1256次阅读和6个评论，其中ScalersTalk作者Scalers专门注册了博客园在我的评论下方留言回复2500字，令我备受鼓舞，还有邹欣老师和宝玉老师的建议我牢记在心，mio4学长的经验之谈也对我很大启发。怀着对所有阅读过我的文章和评论我的文章的人的感激，踏上了软件工程的学习道路。

​ 2020年3月8日临晨2点56分，发出了软件工程这门课正式的第一篇博客——初窥构建之法——记2020BUAA软工个人博客作业 ，这片博客中都是在阅读完邹欣老师的《构建之法》后，对书中存疑的地方提出的问题，并加入自己的思考和理解。这片博客收获了594次阅读9条评论，有其他学校的软件工程老师，还有仰慕已久的SivilTaram学长在我的博客下留言。最令我没有想到的是，负责邹欣老师的《构建之法》和吴军博士的《浪潮之巅》出版的周筠老师联系了我，加了我的微信，带我走进了大神们的世界，周筠老师的群聊中有吴军博士，有轮子哥，还有各行各业的优秀人士，看着他们在群里的讨论愈发能够感受到自己所学和认识的狭隘，除了自己的学习之外，还需要更多的与优秀的人的交流，在交流中增长自己的眼界。为了完成这篇博客，我将《构建之法》每一个章节都进行了阅读，书中还有很多博客的链接我也大多点开来看，对于提出的问题也事先在网上做了充分的调查和搜寻，给出了自己的理解和尝试性的解答。虽然一周的阅读时间很短，但是这个过程真的十分漫长，看完《构建之法》感觉自己在理论上已经开始尝试着从软件工程的思维去思考问题。特别是对PM的章节，除了书之外还搜索了很多地方关于Program Manager和Product Manager的区别，并尝试着将自己代入体验。

​ 2020年3月10日下午18:59，发布了“深度评测官”——记2020BUAA软工软件案例分析作业，对候选素材中最难啃的OCR识别表单的开源工作进行了测评，做第一个吃螃蟹的人，后面总结了经验推广开来，陆续也出现了几篇OCR的测评，收获了1754次阅读，成为了后面团队开发时的产品介绍。在这次作业中，开始体会软件之间的差异，开发软件需要侧重什么，什么样的软件是一款优秀的软件。

​ 2020年03月21日，我和我的组员拼装成了一个团队，并给我们的团队发布了第一篇博客——“介绍一下自己吧”——记2020BUAA软工团队介绍和采访：

我们是 BUAA软软软件工程小队 ，简称 软软软，但是大家也可以看到我们的博客的 TITLE 是 HARD_CORE_SE，指的是 “硬核的软件工程” ，软软软其实是希望我们遇到硬核的软件工程也可以 化硬为软，直面困难，在我们的眼里没有 硬核 二字，一切困难在团队面前都是纸老虎！
虽然我们都没有大型的工程经验，是一直拼装起来的军队，但是我们相信通过我们团队的配合一定能够在软件工程这门课中发挥出色，不只是取得成绩，而且能做出像样的、能流传的、实用的项目出来。

​ 虽然当时我们还没有选好题目，但是我们核心的目标已经确定——做出像样的、能流传的、实用的项目出来。

​ 2020年4月1日，我们团队发布了项目选择博客——“妈妈再也不用担心我忘交作业了！”——记2020BUAA软工团队项目选择，结合本学期的疫情分析了同学们的痛点，决定开发一款帮助同学规划提醒日程的Web应用，而我作为想出这个点子的人，对这个应用有什么页面，有什么功能，能够实现什么最为清楚，因此成为了团队的负责人。

​ 2020年5月5日，修复完所有的Bug、走过不知道多少次流程，我们确定首次公开发布我们的产品——DDLKiller，一款专门面向北航本科生设计的日程提醒助手，并在朋友圈，班级微信群，QQ群等小范围内进行推广：

​ 从后台统计数据来看，发布第一天注册用户达到77人，第二天达到148人，仅仅使用两天的时间就已经超额完成预期的100人，并且从反馈来看，同学们对这一款简洁美观、功能强大的日程管理助手非常满意，并且积极给我们提供反馈意见，帮助我们在Beta阶段做的更好。

​ 第一次发布说实话是非常忐忑的，我们熬了无数个夜晚，开了无数的视频会议，做了无数次测试的软件，突然开放给大家，不知道大家是喜爱，还是无感，我们当天晚上守在后台，看着注册登录的日志，看着注册的人数一个一个往上涨，一个一个开始新建事项，使用我们的功能，守到过了午夜1点仍然没有异常，我们的心才放了下来，大家相互鼓励，洗洗睡了。

​ 2020年6月2日，又经过一轮的迭代，我们发布了Beta版本的DDLKiller，虽然是6月2日发布，但是用户们早已体验过新的功能，结合很多人性化的新功能进行二次推广，用户量达到240人，相比Alpha阶段增长90人。后来经过最后一次项目展示答辩，我们的软件工程这门课程，结束了。

​ 但DDLKiller还没有结束，就像我们UltraSoft - Beta - Postmortem事后分析中所说的：

BUAA - UltraSoft - 软软软小组 2020春大三下学期的软件工程， 全剧终。

但我们DDLKiller的故事还在继续，不要走开，马上回来

​ 我们还留了两个功能没有实现，我们感受到了大家对客户端和小程序的呼声，我们希望在自己的大学生涯中，甚至在未来的生活中，依然继续使用这款我们亲手打磨，亲手建设的产品，说实在的，我们还挺不舍得的。虽然在专业人士的眼中看来这个实现非常简单，可能一个前端大神两天就能做完的事情，一个后端大神一天就能写完的东西，我们却花了整整一个学期。

​ 可是，我们在这个学期里面不是学习的如何写前端，如何使用Vue，不是学习如何写后端，如何使用Django，我们团队的账号发表了39篇博客，技术博客都是在我们的个人账号中发表，这说明什么，团队博客中所记录的，是实实在在的软件工程。那一篇篇设计与规划、Scurm Meeting、发布说明、测试报告、项目展示、事后分析，是DDLKiller像一个新生儿一样，成长的记录。

​ 我们学会了团队成员之间如何高效合作，我们学会了如何使用Github、Gitee管理团队项目，我们学会了使用MockPlus设计产品原型，我们学会了如何权衡需求和实际。确实专业的工程师照着我们的网站实现一个是很快，但是他可能很难做到从0到1的过程。他没有进行痛点的分析，他不知道用户真正需要什么，他没有一个需求和实际使用之间的权衡，他的开发确实了团队协作的乐趣。

​ 说实话刚开始团队开发的时候我还是不习惯多人协作，觉得一个人做完了事就可以省去交流的时间，后来我才发现不是我不会开发，是我不会交流。我们团队后期自研创新的交流方式非常高效，一个石墨文档把锅和坑明确到人，每个人不需要问自己需要干什么，还可以干什么；一天十几个小时在线的腾讯会议，有问题直接进来说，语音来的总比打字快，共享屏幕来的总比截图直接。大家高效交流之后整个难度就下来了，只要说好了谁负责开发什么模块，最晚什么时候需要验收，还有不懂的我们共享屏幕聊，几乎不会产生歧义或者推锅的情况出现。作为一个PM我的体会最深：在Alpha阶段的前期由于缺乏有效的沟通，PM和组员都很累，每个人都有点不清楚自己要干什么，我知道大家要干什么却不能很好布置下去，每天群里的提问和回答带来的却只有效率的低下，我也想着自己一个人做好就算了，要那么多人干什么，但也发现自己越是想全部做完做好越是什么都做不完做不好。这是一段非常难忘的经历，是软件工程这门课提供给我的，给了我一个在步入社会前体验社会毒打的经历，幸好是在课内体会到的，不至于“死”得太惨。

​ 回首望去，觉得这学期很长，也不知道是不是疫情在家的缘故，还是无穷无尽的腾讯会议的缘故，虽然只过了3个月，但是感觉自己做了很多事情一样。3个月后再看自己的第一篇博文，确实有了些不一样的体会。

回答自己

​ 在初窥构建之法——记2020BUAA软工个人博客作业中，我提出了七个小问题，其实在当时已经回答的差不多了，但现在有了一定的软件工程经验之后，又有了一点小的看法。

问题一：是否真的没有银弹

​ “把重点放在质量上，生产力将随之而来”，这是Jones的观点。基于这个观点我当时提出了这样的观点：

我之所以对银弹是否存在持有怀疑态度是因为在大环境下，有一些本可以提高的生产力没有提高，还有很多团队会出现文档与实现分离的情况，出现进度卡在某一个人负责的环节的情况，这些情况都是我们会在后续的团队编程中可能会遇到的，所以我觉得现在就应该思考，如何在团队中破除没有银弹的诅咒，提升团队的整体水平和能力。

​ 我们团队的生产力就有一个拐点，从一开始的效率低下到后来的慢慢摸索再到后来形成体系之后组员们心照不宣。是否真的没有银弹？我们组可能找到了自我协作的方式，充分将每个人的能力在其岗位上发挥，做到了效率的最大化和能力发挥的最大程度，整体生产力得到了提高，是否一定程度上找到了银弹？

​ 其实大家都在寻找属于自己的“银弹”，我看到每个小组都有自己组内的成熟的管理机制和协作方法，大部分是Github的Issue和Pull Request，还有一个Github的看板，还有一些在线文档。并没有说Github上面使用的管理方式就比石墨文档更有技术，我们团队觉得上Github的速度太慢，石墨文档就能很好的解决我们的问题，也可以定位到人，还有具体的任务细节：

Beta阶段开发明显更加得心应手一些，外加Gitee上面的清晰的Issue和Pull Requests：

无论是对内的石墨文档还是对外的Gitee，都对我们的实际开发极大提高了生产力。

问题二：如何选择合适的团队模式

当时邹欣老师给到我的回答是：

想请教老师和助教，业余剧团模式的具体形式能够结合助教的经历或是老师的观察给一个更加清晰的讲述吗？

就是大家可以选择各种角色来扮演， 在下一个项目中，又可以有全新的分配方式。
你们就是用‘业余’ 时间来开发的， 比较适合这样的模式。

​ 在实际的开发中，我们确实也是业余剧团的模式，大家先分好了大方向，前端和后端，然后分配一个模块的任务吧，如日历视图、课程视图等，如数据库、爬虫等，在实际的开发中，主体上不太发生改变，在细分的任务上比较灵活自由。特别是在Alpha发布之后，项目已经成型，大家已经不再限制于模块的开发，细化到功能的开发，比如要实现一个快速创建的功能，可以在日历中，也可以在日程列表中，两个都进行添加。甚至前端的同学可以来优化一下后端的代码，后端的同学学习一下前端的实现，都是“互通有无”的。

问题三：每日例会的效果如何？

在这个问题下面我当时又提出了一个问题：

敏捷开始是否是一个伪命题？

当时找到了Vczh轮子哥的回答：

敏捷不是一群开发者对着甲方的第一版需求猛做几天，而是在做的过程中始终和甲方进行有效的、不间断的沟通，来帮助甲方更加清晰地认清自己的需求，也帮助整个团队确定一个当前的完成进度，也就是一个迭代中的需求分析和验收。

​ 经过两轮的迭代和20余次的Scrum Meeting，感受到了一些敏捷开发的意义：虽然我们没有甲方，但是我们自己就是自己的甲方，我们不断反省和思考着自己需要什么功能，自己不需要什么功能，认清自己的需求，掌握团队的进度，不断验收。

​ 每日例会一开始是拒绝的，我们在Alpha阶段还弄错了例会的时间，导致缺少两篇，觉得这些东西在Github上都有，为什么还要记录呢？后来其实发现每日例会重要并不在于记录，其一在于每日隐隐地督促着每一个成员，“今晚要汇报，自己做了什么？”；其二在例会，一个常规的，团队的固定“节目”，有例会才像是一个成熟的团队而不是一个个散兵，在例会中大家可以找到归属感，大家可以有问题在例会中大胆提出来，有什么想法提出来大家一起实现，有什么功能其实没有什么用大胆删去，例会还是一个平台，提供给大家自由说话、表达意见和想法的平台，在例会中每个人都有说话的权利，每个人的话都能被所有人所听见，这是我理解的每日例会的意义。至于效果，见仁见智吧，我们团队的例会效果我还是比较满意的，大家都有准时参与，都敢说，都是为了我们DDLKiller更好的发展去说。

问题四：为什么除了微软很少见到Program Manager

​ 当时我其实没有找到这个问题合适的答案，也是遗留了下来，自己作为这个学期软软软团队的PM，无论是Product Manager也好还是Program Manager也好，谈一下自己的看法。

​ 很多地方都在吐槽产品经理，说产品经理不管需求是否能够实现，产品经理是程序员的天敌诸如此类，无非就是在说产品经理不动技术，只懂调研和分析需求。作为我们团队的PM，我也参与了调研，我也确定了产品的需求，但我也在我的岗位——后端、部署、测试上工作，所以当我有新的需求的时候，作为一名程序员，我也会要么凭借自己的经验对需求的实现难度进行预估，要么根据已经实现了的功能对需求进行预估。比如临时加入一个消息中心，我其实也是从前端小白到了解了一点前端的知识，我知道这个功能并不麻烦，前后接口一设置分别实现就行了，所以大胆的安排了下去这个临时的任务，我得力的组员也很快完成了，经过我的连接和测试，一天内用我们的“业余”时间就上线了这个功能，提供了极大的便捷。

​ 至于为什么除了微软很少见到Program Manager，希望我能够亲身去微软和其他公司体验一下吧。

问题五：对于小团队而言小强地狱是否可行？

​ “小强地狱”听着特别可怕，但其实在我们的实际开发中没有太多遇到，首先是代码总量不大，经过几次定位就可以找到问题所在；其次是我们保证了合并进入主分支钱经过“充分”的测试，这里的充分之所以打上引号是因为100%的充分并不存在，就像我们的同步课程中心的爬虫核心功能，在我们团队的几个人的账户上测试都没有出现问题，结果小范围的内测立刻炸锅，赶忙修复然后加大内测的范围，在几轮的测试都无误之后我们才正式上线功能，这也是为什么我们发布比较晚的原因。

​ 我们团队也并没有测试这个职位，大家前端和后端自己先测试自己的代码，然后连接的时候再测试连接的代码，不需要不参与开发的人去读代码，只要提供充分的测试样例就行了。小团队连开发都人数有些不够，在项目的尾期设置专门进行覆盖性测试的测试人员即可，这种开发方式在我们的项目中并没有出现什么大碍，所以小强地狱这种东西，只是一个提出来的权衡feature和bug的模式，每个团队可以根据自己的实际情况进行调整。

问题六：迷思之六：技术的创新是关键？

​ 我们的项目有创新吗？可以说有：我们使用邮件给用户进行提醒，只要有网就能收到提醒；也可以说没有，有一部分的用户是被我们的美观的界面吸引过来的，可能并没有使用邮件的功能，而且其实我们的产品有类型的原型——Microsoft的ToDo。但是我们创新性地将同学们的所需以一个更好的形式呈现了出来，进行了高度集成再展现的过程，这也不失为一种创新。

​ 我们在开发的时候想过创新吗？说实话我没有。用户在使用到这样一款产品的时候会主动想到有什么创新吗？可能也没有。无论是开发者还是使用者，大家都在关注一样东西——是否解决痛点。我们可能从来没有想过邮件提醒是一种创新，灵感来源于博客园的作业提醒，我们想的是如何解决用户没有在日程的DDL前被提醒的痛点，邮件只是解决这个痛点的一个可行方式罢了。

​ 我不是在否认创新的重要性，只是在说有的软件可能目的不在于创新，也能够赢得大家的喜爱。新鲜感固然是好东西，但是新鲜感不能持久，当新鲜感褪去，用户是否还会对我们的产品满意？是否会选择其他更具有新鲜感的东西？这些是根据用户的需求是否被解决所决定的，也是一个产品的核心部分，真正被考量的部分。

问题七：最难的问题——排座次

​ 当时提出这个问题时，还是太嫩了，其实排座次在实际执行起来是整个开发中最简单的事情，就像邹欣老师说的，有的人想得60分有的人想得90分，根据大家的Pull Requests和实现的功能的工作量就可以看出来。我们团队的成员大家都非常积极，甚至主动找我领取任务，所以在最后的打分大家都差不多；其他组比如NAG2020就可以看到，其中有一名成员就是想拿60分的，两个阶段的贡献分都是最低，代码贡献也是最少，自然就给了最少的分数。

​ 使用Gitee、Github等项目管理软件之后，每个人的积极程度、活跃程度、项目的贡献量都一目了然，所以排座次的问题，客观公平公正得到了解决。

新的问题

​ 疫情之下，我们体验到了全新的软件工程，可能我们是唯一一届在线上开展软件工程这门课的学生，我们线上开会，线上协作，线上发布，线上展示。Work From Home 成了疫情中主流的工作方式。之前看到Vue的开发团队就是分布在世界的各个角落，线上交流和协作维护，他们已经形成了一种十分成熟的WFH的工作方式。

​ 试想，在WFH是否会成为未来的发展方向？特别是对于程序员而言，WFH其实可以在不影响开发的前提下能节省很多的时间，如通勤等等，很多大公司已经或者开始尝试WFH，包括美国的巨头Google、Facebook、Twitter等等，请问老师和助教觉得，本学期的WFH与之前学期的线下软工有什么区别，有意料之外的提高吗？

“做中学”

需求阶段

学会取舍：冲刺只有两周，而且我们是业余开发，所以不可能将所有的功能都实现，甚至在Alpha阶段我们仅有的反馈中有一项是希望在课程列表中加入测试模块，这个想法在Beta设计与规划前是列入到了Todo List中的，然而在Beta设计与计划实际的权衡中我们将其丢弃了，替换为了课程的通知，因为通知使用的更多，几乎每门课都有，而测试只有少量的一两门课有。

设计阶段

颜值即正义：一款颜值高的产品不一定是最好的但一定是最吸引用户的，我们的Web程序也是因高颜值吸引了不少用户，大家对于课程中心陈旧的排版感到视觉疲劳的时候看到我们的产品会眼前一亮从而想要体验，这是在推广阶段特别重要的一点。

实现阶段

考虑可扩展性、注意代码风格：以我负责的后端爬虫来说，从开始时的只爬取课程作业和课程资源到迭代中加入爬取课程通知再到期末季中爬取考试日程安排，这几样东西应该做到合理归类与分离，以免造成代码太过臃肿接手的人难以及时上手。

测试阶段

回归测试和覆盖测试的重要性：在发布新功能时，要一并考虑到旧有功能是否正常运行，我们在迭代中就遇到这样的问题，比如在Beta阶段我们支持了重复日程的提醒，向日程中加入了字段 repeat，然而我们只测试了常规的添加日程，没有考虑下方的快速添加日程和模板添加日程，导致发布之后出现内部错误，检查日志才发现错误所在然后紧急修复。如果每个新功能在发布的时候都能够有回归测试则可以避免这一问题。

发布阶段

渐进式发布：当一个应用的新功能准备发布的时候，会进行一些测试，比如灰度测试，即选取一小部分用户可以体验到该功能，其他用户维持原来的功能不变，以查看新功能的运行效果和用户反馈意见，在我们的开发中，我们有多台主机可以进行访问，所以会先使用其他主机的ip访问使用“内测版本”的DDLKiller，然后过一段时间再发布。在Alpha的正式发布前我们也做了小范围的内测，让一些自己的舍友和朋友先使用，看看有没有问题，还有么改进的地方，确实内测找出了一些问题，帮助我们在正式发布的时候减少很多事情。

维护阶段

文档文档文档：经验教训是有心东西一定要以文字的形式在文档中呈现，首先是提高了团队内部的沟通效率，大家不用反复询问可以直接查阅文档，其次是积少成多，为后面接手的同学做充足的准备。特别是前后端分离的团队开发，只要文档维护得好，直接事半功倍，反之事倍功半。

理解、心得

​ 个人项目->结对项目->团队项目，是一个课程组有意设计的一个递进的关系，在这一点上我觉得罗老师和任老师班级的软工做的最好，相比于欧阳老师班级的个人项目直接到团队项目，我们中间有一个过渡期，很多人其实在过渡期的时候就知道自己想要干什么了，大致可以分为前端和后端了，这样一来在团队中的项目分工也简便了很多。

​ 在个人项目中，我们实现了一个求交点的程序，没有页面显示，只有命令行的交互；在结对项目中，我们加大了求解交点的难度，同时用图形化的界面将交点的位置呈现在了眼前；在两个冲刺，前后两个月的团队项目中，我们分工更加细致，实现了一个软件。一步步走来，感觉越来越难了，但是也越来越简单了。难在项目确实更大，从技术上来说难度确实增大了；简单在我们不是一个人在战斗了，我们身边从没有人到一个人再到一群人，集体的力量是不容小觑的，每个人都有自己擅长的部分，这一点感触特别深。在团队中，一个人花了很久不能解决的事情，丢出来大家都积极主动伸出援手，一起将困难啃下来；在这个学期学习是在很累的时候，也是我们团队的成员陪伴着我，在此感谢陪我熬夜最多的Kkkk，有时候大家就算不需要说话，只要会议室里面有人，心灵就能得到慰藉——“我背后还有一个团队”。

​ 在团队项目中，我既是PM又是后端开发，还负责部署，这个工作可能比有的团队PM只负责文书麻烦一些，但也暴露出来了一人多职的缺点。由于Alpha阶段对时间的理解错误外加新项目开发难度大，导致Scrum Meeting有一两次开会了但是没有及时记录导致会议纪要缺失的情况，还有就是写完代码之后没时间写文字了于是产生拖延，这一部分应该专人来记录会好一些。在团队项目阶段确实学习到了很多新知识，无论是Django开发还是NGINX部署，都需要啃官方文档，特别是NGINX和Uwsgi的两个官方文档还有不清楚的地方需要自己解决，在五一的五天假期连肝五天才总算把前后端连接和服务器部署彻底啃下来，终于在五一假期的尾声进行小面积的推广。这也让我对网络与系统这一方面产生了兴趣，在暑假期间我会尝试涉猎一些分布式和网络编程相关的内容，如果感兴趣的话希望有机会往这方面发展下去。若是因软件工程这门课能够找到我自己的真实兴趣所在，也是太值得了。

​ 作为PM，特别感谢我的软软软团队的队友们，包括Alpha阶段结束之后转走的Dz，一样非常感谢。是你们一起帮助我完成了我的一个想法，让他不再是一个想法，成为了一个真正能够使用，大家都可以使用，甚至受到好评的一款软件。其实DDLKiller是我实在找不到一款可以提醒我日程的软件下的“被迫选择”，想要一款DDLKiller这个念头在我刚开学的时候就有了，当时和舍友尝试了Tower协作也不好用，尝试了Microsoft的Todo也不好用，自己又开发不了，但是居然在团队开发中被我们做出来了，和我预想的完全一致，甚至某些功能超出预期。是你们让我第一次体会到想法到实现的喜悦，第一次切身体会到代码的魅力，第一次感受到团队的强大，体会到1+1+1+1+1+1+1>7。DDLKiller就是我的软软软团队的孩子，离不开每一个人的付出。

​ 我们在第一篇自我介绍中说到：

虽然我们都没有大型的工程经验，是一直拼装起来的军队，但是我们相信通过我们团队的配合一定能够在软件工程这门课中发挥出色，不只是取得成绩，而且能做出像样的、能流传的、实用的项目出来。

​ 至少在我自己看来，我们已经成功了。

最后想说的

​ 大概的都说的七七八八了，若是要用几个词语总结这学期的软件工程课程的话：

​ 魔幻、刺激、充实、欣慰

​ 在每次的个人作业前面老师都让我们写下这门课程的目标，我写的是：

完成一次完整的软件开发经历
并以博客的方式记录开发过程的心得
掌握团队协作的技巧
做出一个优秀的、持久的、具有实际意义的产品

​ 现在看来，我都已经做到了：

• 一次完整的软件开发经历：从使用MockPlus画出草图，到真正用网址就能访问

• 博客团队的开发：39篇团队博客就在BUAA软软软件工程小队中

• 团队协作的技巧：我们甚至自研了石墨文档+腾讯会议的创新性协作方式

• 优秀的、持久的、具有实际意义的产品：DDLKiller——懂你的日程管家

  从UltraSoft - Beta - Postmortem事后分析中摘取一段话出来：

如果下一年有学弟学妹问我：软件工程哪个老师的课好？

我会如实回答：如果你对自己有要求，如果你想这个学期不碌碌无为，如果你想学期结束收获满满，如果你想逼自己一把，选择罗杰、任健老师的班级吧。过程会很痛苦，你会看到别人都在玩的时候你在写博客，你会看到别人开发的时候你在写博客，你会看到别人只开发一次就结束的时候你在写博客，你在开例会，你在Beta阶段开发，但是当你的博客得到了老师的认可，得到了助教的赞赏，得到了《构建之法》作者邹欣老师的点评，得到了轮子哥Vczh对你的提问的亲自回复，得到了《持续行动》《刻意学习》作者Scalers为你特地开账号的留言，你会感觉，这一切都值了。

​ 庆幸当初的自己没有听到负面的评论就退缩，坚持选择了罗老师和任老师的班级，做出了像样的东西。我确实心里吐槽过博客，用心写真的很累，每次博客能花上3～5个小时，每次都是动辄上万字，但是确实写完之后获得了有意义的评论和建议心里特别舒服，让我受宠若惊的是第一次的Scalers为我注册博客园账号留言7500字，让我感觉到自己的博客没有白费。自己也是北航面向对象课程的助教，也能够一定程度上理解老师和助教的良苦用心，很多东西学生在做的时候是会不理解甚至骂出声的，但是做完之后又是另一种感受了，老师和助教只能委屈成为暂时的恶人，逼着同学去思考，逼着去写下文字，逼着做看不到短期利益的事情，等待着一切都结束时候的理解。

​ 软件工程这门课虽然结束了，但我们的软件开发依然在继续，回顾，为的是更好的出发。

最后

以上就是无心河马为你收集整理的如果你对自己有要求 | “回顾，再出发”——记2020软工提问回顾与个人总结回顾，再出发的全部内容，希望文章能够帮你解决如果你对自己有要求 | “回顾，再出发”——记2020软工提问回顾与个人总结回顾，再出发所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。