| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 提问回顾与课程总结 |
一、提问回顾
有幸在软工课程之初完整阅读《构建之法》，同时产生了若干疑问，在经历了结对编程和团队项目后对当时提出的问题有了新的理解，具体如下：
1.什么是Bug？
- 如果不同用户的期望值不相同，此时如何比较软件的行为和用户的期望值？“不一样”从何谈起？
- 如果软件行为因为商业盈利而没有达到（或有损于）用户期望，也算作Bug么？
- 软件的行为是否一定要追求和用户期望保持一致呢？
Bug，又名缺陷，爱迪生关于Bug的描述最为恰当：
It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that "Bugs"—as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.
Bug随着开发进程的推进而不断产生，不断被修复，被记录，被总结，被避免。
回到当初提的有关Bug的三个问题，其实均是忽略需求分析而谈的缺陷。
正如笔者在需求存在，功能存在——Alpha阶段性总结中阐述的一样：
功能永远以需求为导向，产品的价值取决于满足多少需求，而非拥有多少功能
所以在软件开发之前，对目标用户进行充分的需求分析可以及时矫正软件的开发方向；
用户自会根据自身需求在软件本身的核心功能和商业盈利中做出取舍，当然软件中过分的商业盈利行为自然会影响软件的推广与使用；
正如宝玉老师当初在博客下评论的一样，软件的行为不一定要追求和用户期望保持一致，毕竟
在汽车发明之前，用户只会想要一辆更快的马车！
2.单元测试
如果程序的作者在程序的设计实现阶段便忽略了对某些情况的考量，此时再由作者构造单元测试，是否仍然不能注意到这些在程序设计实现上的漏洞呢？
在经历结对项目和团队项目后，笔者认为程序设计者编写单元测试效率更高且更为完备，因为相较于他人，程序设计者最为熟悉自己的代码，构造对应的测试更为得心应手，而且单元测试只是若干测试中的一个环节，单元测试本身也不可以保证规避各种bug的出现，如果确实有所疏漏，也可以在不断的迭代开发中进行改进。
3.goto的使用
goto是否能有助于程序逻辑的清晰体现
goto的使用的确是仁者见仁智者见智，笔者正在经历的编译比赛的高层IR的设计中便有goto的存在（摊手），当然结合目前的普遍共识，在未来的工作中还是不用goto为好，要不然，别人可能也会像我当初提出这个问题一样质问我，为什么要写goto？当然如果在代码规范中明确指明不允许goto的存在，自然更不应该使用goto。
4.结对编程
驾驶员和领航员不应当是各有所长、各司其职么？如果互换的话，会不会不能达到开发效率的最大化？
从结对编程的经历来看，在已经明确了架构设计，接口设计后，为了保证高效率地编程，驾驶员和领航员可以互换（毕竟全程一个人肝代码还是很累的），互换后，原本擅长编程的同学还可以进一步检查自己写过的代码，也可以优化逻辑的实现方式，当然，大部分时间还是应当各司其职为好，这样才能达到效率的最大化。
5.萝卜与白菜
“小强地狱”是否真的合理？
从团队项目的开发经历来看，bug应当由相应的开发人员修（谁的锅谁来修），只有通过设定合理的阈值，才能保证项目既快又稳的推进，当初的理解现在读来有些本末倒置之感，在敏捷开发中，萝卜的做法可以说是普遍存在，往往为了保证功能的正常交付而提升开发速率，降低开发质量，抱有后续再测，现在先不管的态度，结果可想而知，Bug极多，所以当超过阈值后，萝卜就应当前去修复自己的bug，否则积少成多，只会降低项目的整体质量。
二、新的问题
如果在阶段冲刺中，因为种种原因无法做到100%地满足阶段原定用户需求，那么此时
- 100%完成80%的用户需求（核心需求至少满足）
- 完成100%的用户需求，但完成度只有80%（任一需求功能保证至少可用）
两者应当如何选择，或者是否存在其他的更优解？
三、做中学
1.需求
需求分析至关重要，至少在build to win模式下，需求并非从真空来，而是需要从目标用户中挖掘，需要进行充分的市场调研。
这一点在需求存在，功能存在——Alpha阶段性总结中阐述地较为详尽。
2.设计
充分详实的设计可以为后续的实现省去很多麻烦，题士的两阶段开发均是以UI设计、API设计和数据库设计为起点，在实现过程中不断修正和改进最初的设计，明确清晰的设计文档不仅可以使不同人员的开发工作解耦，提升开发的效率，还可以为后续的测试工作提供依据。
3.实现
在实现阶段中最重要的是沟通，充分地沟通可以有效减少技术负债。
开发与测试应当同步进行，一步一个脚印才能走得踏实，走得长远。
4.测试
多维度地全面测试可以有效提升项目质量，满足测试用例只是每一个负责任程序员的基本素质，后续的场景测试、性能测试和压力测试等才能进一步地发现问题。
测试中发现的问题应当及时记录，尽早解决，事后总结，后续规避。
5.发布
面向用户人群的宣发才是行之有效的，每个人的时间都是宝贵的，因此快速地向目标用户展现自己的项目功能，展现为目标用户带来的收益是至关重要的。
当然，在宣发的过程中应当及时关注目标用户的反馈，及时向目标用户做一些进一步的补充。
6.维护
维护的核心在于高响应，发现问题后立刻定位、解决和完善。
项目运维需要有完整清晰的日志，同时在维护的过程中需要反思与总结问题出现的原因以便后续更好地规避问题的出现。
四、个人总结
与其说是个人总结，不如称之为心路历程，谨以此纪念难忘的2021软工课程。
期待
因为两个人，选择罗杰软工时心怀期待。
2020还在经历OO课程时，幸运地读到CookieLau的停下来，回头看万字长文博客，看到当时作为OO助教的CookieLau细腻而又深刻地回顾过去、展望未来时，我不禁畅想，自己未来是否有机会做一份总结、许一份展望；当机会来到时，自己又是否可以像CookieLau一样完整地表达自己的所思所想、所感所悟。
一年后，自己也成长为一名OO助教，此时机会与顾虑也来到身边：希望可以在罗杰软工课程中满足自己曾经的畅想，也因为往届的评价而犹豫不前，而此时HansBug的表态打消了自己的顾虑：
深知他的能力，既然在改革，那便心怀期待着走进罗杰软工课程，至少，试一试。
表达
真正着手做一份总结时，却另有一番滋味。
初始时是打算像停下来，回头看一般款款而谈，但是一番尝试之后，发觉自己更适合言简意赅地做总结，可能自己做不到像CookieLau一样抓住生活中的点滴吧。
在一番调整后产出了你好，软工这篇总结与展望博客，与软工打了一个照面之后，发现这门课原来是建立在人的表达之上，诚然，表达可以理顺人的逻辑，至少，可以拨云见日看清前方的路。谁又能想到最后写了40多篇博客，输出20多万字呢。
持续地输出自然也离不开持续地输入，《构建之法》、案例分析，一份份任务接踵而至，还算从容应对，不至于手忙脚乱。
迷茫
接下来与wpb为期三周的结对编程，应该是最为迷茫的时期。
有思考过自己在干什么：OOPlus，对着issue改代码；
有调研过选择其他软工课程的人在干什么：摸鱼写文档、舒服又快乐。
浑浑噩噩迷茫而又困惑地度过了结对编程的两周，又用了一周的时间探索自己未来应该以怎样的态度对待这门课程。
转变
后续和HansBug的沟通让自己的心态有了微妙的变化。
可能将态度转变为挑战自我应该会过的更舒坦一些，至少没有必要和别人对比，坦然的努力，一分耕耘一分收获。
正如在第三次结对编程作业博客中阐述的那样：
学到就是赚到，尽管过程中会焦头烂额，尽管羡慕隔壁软工摸鱼水文档，但是三周下来，结对编程的快乐是我们的；逐字逐句需求分析的充实感是我们的；绞尽脑汁构造测试样例最后完美通过弱测强测的满足感是我们的；一周一总结，一次一反思的脚踏实地感是我们的；以上，足矣。
敏捷
当态度转变为挑战自我后，迎来的便是真正的敏捷开发。
敏捷，名副其实，题士团队每两天一次线下开发，每次4小时起步，以此保证开发进度。
可以说是逢山开道，遇水造桥，最终在三周之内完成网站备案，APP、小程序的适配和发布，产品主页的初步形成，后端管理平台的搭建。说实话，作为PM，这样的成果很意外，也逐渐懂得了什么是敏捷，什么是build to win，至少，没有build to learn。
不解
对人员转会原规则的设定十分的不理解，各种考量在当时也表达过，在此不再赘述。
当然，还是要感谢课程组后续制定新的规则，与之前相比，更贴近实际，也更尊重每一个开发团队。
取舍
敏捷难在多方面的权衡，做出取舍。
在人力物力资源有限的情况下，选择导入哪些科目的题，各种题库，质量参差不齐，如何挑选与处理，应该是Beta阶段末期考虑最多的事。
最终选择新增计算机导论和经济管理两门课程的题库，放弃了军理这一科目的题库。计算机导论课程与航概类似，考试全为选择题的形式，书后也有现成的例题和答案；经济管理经过多年的迭代与总结，资料较为丰富且稳定；军理由于官方不为学生发复习资料，自己也不能为了用户量和日活导入祖传题库打乱同学们的复习方向，所以最终新增计导和经管，放弃军理。
忐忑
尽管进行了详实的压力测试，并对服务器进一步进行缓存配置，但还是在《航概之夜》担忧题士是否可以顶住高并发，恰逢倾盆大雨，心中十分忐忑。
幸运的是，题士很争气，最终交出了一份较好的答卷。
遗憾
由于微信的玄学审核问题（审核标准不尽相同，拒绝理由各式各样），题士未能在《航概之夜》之前发布改进热区的新版本，希望更好的题士可以更快地为同学们服务。
憧憬
项目已进行了开源
作为半学期开发的心血，如果未来想一直维护题士，课程组是否还会提供资金支持？
感激
最后，感谢老师和助教一学期的辛苦付出，感谢结对编程驾驶员wpb，感谢HansBug对题士的深度评测，感谢团队中每个人的全情投入，感谢坚持到最后的自己。
建议
最后的最后，向课程团队提两点建议，希望可以对未来的课程建设有所帮助：