凡为过往，皆是序章——软工全系列个人总结
| 问题 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 进一步提升工程化开发能力，积累团队协作经验，熟悉全栈开发流程 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾学期初提出的问题，总结课程收获 |
提问回顾
其实，在提问博客里，对于绝大多数问题，笔者已经给出了自己的思考与解答。不过作为一篇总结性的博客，这里不妨更进一步，看看经历了一个学期后，自己是否对这些问题有一个更深入的认识吧。
Q1. 什么样的功能才有实现的必要？
正如笔者在提问博客里所写的那样，这个问题的本质其实是如何判断一个功能的重要性。在提问博客中，根据《构建之法》一书中的观点，邹老师似乎是想强调即使一个功能用户的使用频率并不高，但也不妨碍它的重要性，比如说飞机的安全功能。
对此，在经历了敏捷开发的过程后，笔者既同意，但又不完全同意。
同意的点在于，对于一个成熟的商业软件而言，比如说windows，它的杀毒功能或许普通用户平常很少接触，但是如果没有的话后果会不堪设想，因此对于这一类的基本功能，使用频率并非是衡量其价值的关键。
不同意的点在于，对于一个敏捷开发的产品而言，如何在短时间内最大程度地抓住用户的痛点才是关键，此时或许就更倾向于从用户的角度出发，用户要什么，我们就提供什么。
不过其实深挖下去，这两种场景在深层次上并不矛盾，最终的落脚点还是如何更好地衡量用户需求并加以实现。一个产品在其不同的成长阶段，着眼点也往往是不同的。不过我们目前所接触到的产品更多的还是在成长期，而非成熟期，自然也就更加倾向于后者了。
Q2. 单元测试应该由谁来写？
对于这个问题，笔者的观点没有发生变化——最好还是应该交给专门的测试人员来完成。
不过，在敏捷开发这一场景下，在人力资源捉襟见肘的前提下，那当然还是交给代码的作者比较好——毕竟总好过交给另一个同样还在做其他开发任务的人。
Q3. 专和精的关系到底是什么？
对于这个问题，笔者的观点也没有发生变化——作者这里想讨论的应该是“专”和“全”的关系，而不是“专”和“精”的关系。
而对于后者，笔者已在原博客中进行了解答，引用如下：
对于这个问题，我认为单纯强调”专“更好或者”全“更好都过于片面而不够客观，归根结底还是对于【软件工程师】这一职位地定义太过模糊与宽泛。同样都是工程师，不同人的分工也有所不同：有人专精于前端或后端相关技术栈，有人则需要统筹全局地架构和部署。此外，在一个人的职业生涯中，其承担的职责也是在不断流动的。也许他在入门时可能只是擅长某一特定方向的程序员，但在不断的磨砺与成长后也完全有可能去独自领导一个团队；或者也许他在入门时各方面基础都比较扎实，但在不断的探索中他也完全有可能找到自己擅长且感兴趣的方向，最终成为这个方向上的开拓者。
Q4. ”技能的反面“与提高技能的方法
对于这个问题，笔者当时也已经进行了详细的解答，给出了个人的观点。
在此，笔者想对“熟练”这个概念做进一步明确的定义。
真正的熟练，是超越。
具体而言，我们说熟能生巧，这不是没有道理的。当一个人熟练于某件事的时候，他绝不是简单地提高了自己的速度，而是他在这其中发现了某种诀窍，从而可以事半功倍地完成任务——这和机器语境下的熟练是不同的。
如此一来，技能与“技能的反面”之间的矛盾也就迎刃而解了。
Q5. goto到底该不该用？
goto当然不该用，这没啥好说的。
Q6. 商业价值与开源精神是否矛盾？
这个问题，笔者当时也没有给出一个明确的答案。很遗憾，现在也无法给出。
商业软件的开源与否一直是一个很有趣的话题。Linux是开源的，但UNIX不是；Android是开源的，但GMS不是；苹果的生态是闭源的，但不妨碍人家始终维持行业领导者的地位；某些软件是闭源的，但可能多数人听都没听过他们的存在。
所以矛盾吗？
或许并不矛盾。闭源是为了维持自身的竞争力，开源是为了更好地开拓生态和市场，它们本质上都服务于产品背后的商业逻辑，服务于公司未来更长远视角下的发展。
你看，现在连office不都开源了一部分了嘛，紧随时代潮流才是关键呀。
Q7. “只先一步”最终一定会带来“颠覆式”创新吗？
只先一步必然不会带来颠覆式创新，从个人视角来看。
只先一步必然会带来颠覆式创新，从人类视角来看。
以上。
Q8. PM与开发测试人员的关系和分工应当是怎样的？
对于这个问题，作者的观点是【PM做开发和测试之外的所有事情】；对此，笔者当时给出的回应是：
因此，我认为，单纯地把PM的工作定义为【开发和测试的补集】是非常不合理的。一个合格的PM他在一个团队中所起到的作用更像是【粘合剂+方向标】，他既需要随时把握各个开发测试岗位的当前进度（这如果没有基本的技术功底的显然无法做到），同时也需要及时将客户的需求传达给团队的其他成员们，从而共同协商出下阶段合理的任务计划与分工进度安排。
而在本次敏捷开发中，笔者所在的团队所采用的【轮值PM模式】也在很大程度上进一步模糊了PM与开发测试人员之间的分界（当然这也是迫于人手不足的原因所致），但从结果来看，还是比较成功的。这里也不妨附上本组对于轮值PM模式的一点总结心得：
关于多PM管理模式，并不是简单地将原单PM的工作一分为三，或者拷贝多份，而是建立在PM团队内部的一致性前提下，结合不同PM的个人特点，所实现的多层次、多维度的权责分工模式。
这里我们借鉴了传统管理中职能式、流程式、矩阵式等经典的管理方法，结合敏捷开发的特点，最终在不断实践的过程中完善了本团队的PM机制，并取得了比较理想的成果，客观上有助于提升团队整体的凝聚力与工作效率。
具体而言，根据本团队的实践经验，我们认为实行多PM制度需要满足以下几点先决条件（必要不充分）：
- 各PM均具备远高于平均水平之上的团队责任感，有一定的奉献与牺牲精神，任一人均应在团队遇到困境时有着挺身而出的觉悟；
- 各PM之间要配合默契，最好之前有过一定的合作经验，对各自的性格特点有基本的了解；
- 各PM的性格、能力要能够互补，即在任一特定小领域内，某一PM将有较高的权威甚至唯一决定权，其余PM将在理解的基础上尊重并支持其决定；这些小领域彼此之间不会重合。而由于性格等差异，不同PM对于团队发展的落脚点不同，于是在全局大方向的把控上也往往能够相互补充，以免有失偏颇。
至于本团队，PMz重点负责前端设计与实现，PMm重点负责后端算法及测试，PMt则负责整体的统筹协调以及后端API、环境部署等工作。
此外，在博客撰写、对外交涉、宣发等工作上，各PM也会在充分沟通的前提下保持统一口径，并进行合理分工，以保证团队项目的有序推进。
所以，一个优秀的PM，必须是【粘合剂+方向标】——为整个团队指出方向，且能在最需要的时候随时可以顶上。
不过，一个合格的PM，只要把他该做的都做好，就能对得起他拿的那份工资了不是。
Q9. “杀手” + “辅助” = “维持”？
对于【杀手功能+辅助需求】这样的组合，作者给出的建议是采取“维持”的办法进行实现，而对于【杀手+必要】这样的组合，作者则给出了“差异化”的建议。
对此，笔者的观点未发生变化。引用如下：
在如今的互联网时代，整体上来看，多数公司与产品所采用的商业模式已经与传统制造业截然不同——传统制造业销售的是产品本身，而互联网公司们销售的则往往是产品周边与服务。比如Google公司的核心是搜索引擎算法，但它所采用的盈利方式则是靠广告投放：假如当时Google把全部重心都放在优化它的搜索引擎的性能上的话，那么缺少有效盈利手段的它有可能拥有如今的市场占有率吗？
再比如，现在非常火热的《王者荣耀》等一系列手游，它们的核心功能无疑是游戏的玩法本身，但很遗憾这部分功能通常是免费的，而真正收费的却是各种【皮肤】等看起来并无任何实际用处的外围功能：那这是否意味着游戏公司就只需要提供最基本的皮肤给玩家就够了呢？
因此，我认为在资金有限的前提下，一些必要需求，哪怕是杀手功能，反而只需要“维持”即可；而恰恰是一些看似不那么重要也不难实现的辅助需求，才是真正需要做到“差异化”的关键所在。
新问题
- 敏捷开发的天花板是不是有点低？
- 与一个成熟的软件（比如VS）相比，敏捷开发之后的路应当走向何方？
- 这样下去，中国何时才能造出
MatLab呢？
知识点
需求
- 要提升目标人群的针对性，尤其是对于需求切口相对小的群体而言，需要想办法尽可能与之早日接触
- alpha 和 beta 阶段的宣传结果对比表明，针对性的宣传明显会产生更好的结果
设计
- 设计要保证足够的可维护性，即向前兼容的能力
- 无论是前端UI还是后端数据模型，最开始都不可能做到绝对的尽善尽美，因此必须要留下后续继续迭代的空间与可能
- 可以辅以健全的文档实现
实现
- 前期要注重规范的建立，中期应保证格式内容的审查，后期要注重对前期的兼容
- 比如API的基本规范、CI\CD的实现、回归测试等
测试
- 模拟测试往往不可能考虑到全部情况，因此要尽早部署到真实环境中进行内部测试
- 单元测试的覆盖率不能说明一切，但如果连覆盖率都没有或许可以说明某些问题
发布
- 早发布早治疗
用户表示：只要你敢发，我就敢用
- 注重用户反馈，随时进行产品迭代更新
维护
- 建立维护日志，对于维护记录进行管理，避免重复操作
反思
个人项目
软工的个人项目由一篇篇博客组成。通过这一篇篇博客，以及博客背后所耗费的时间与精力，笔者对于自己、《道法之间》、CI/CD以及若干问答网站都产生了更加深入的认识。并且笔者关于问答网站的博客也十分幸运地成为了班级热门博文的Top 1，得到了更多人的关注与认可。
必须要承认的是，这些博客的存在客观上进一步锻炼了我的写作与分析能力，使得自己笔下的文字更有条理、更有逻辑，在简洁精炼的同时依旧保留了笔者原先对美感的追求。
如果能再提升一波英文写作能力就更好了
结对项目
结对项目中，博客只是锦上添花，重点又重新落回了编程本身，所谓“梦回OO”，正是基于这一原因。
但是正是这些锦上添花的博客，涵盖了笔者对于结对项目本身的思考。无论是【MVP还是MBP】、【需求迭代与升级的方式】，还是那一个个 issue，都能够证明笔者、笔者的队友以及其他选择这门课程的同学们，对此都是用心了的。
而至于编程本身，不得不说，能够再度重新体验一下 java 的感觉还是非常不错的，特别是实现还是文件系统这样一个很全面的产品，其中复杂的逻辑对于个人的编程水平也是一个比较大的考验。
团队项目
团队项目要考察的能力就是全方位的了：文档、编程这些都是基本功，还有在其上的设计、宣传，以及PM所额外需要具备的把控全局的能力等等，不一而足。
至于感想，这里就直接引用 beta 阶段的团队总结里的内容了。
伴随着烤漆的钟声与一门门课大作业 ddl 的结束，软工 beta 阶段的开发也就此终于落下帷幕。
如果把 alpha 阶段比作是在一片白茫茫荒漠中摸索出一条大致的路来，那么 beta 阶段就是要努力让这条路变得更宽更广，让更多的人能够走上这条我们开创的路，并能够收获更美丽的风景。
在 beta 阶段的开发中，我们在 alpha 里积累的所有优良传统（比如全线下meeting，kanban法冲刺等）都得到了很好的保留；同时，更令人欣慰的，是团队中的每一个人都最终找到了自己合适的定位，在这样的一个项目里做着自己感兴趣的那部分工作，发挥自己的长处，几乎是不求回报地想要把自己的那份工作做到最好，做到极致。
这一切，作为PM的我(tcy)，全程都看在了眼里。我记得，小树不断地将前端的 UI 界面进行反复优化与重构，只求为用户提供最丝滑的使用体验；我记得，Mokoghost为了实现词图中单词移动的动态效果，亲自手写了最底层的动画播放逻辑；我记得，潜行的蚂蚁对于主页、教程的反复打磨，以及在宣发时的不遗余力；我还记得，圆那超强的执行力以及不怕苦不怕累的担当和责任感；还有Potassium对于核心算法的实现与数据的爬取做出的无可替代的贡献……
类似的故事还有很多很多，多到足以让我坚定不移地相信，我们团队里的任何一个人，放到外面的任何一个地方，都能做到独当一面，都能一人撑起一个甚至多个部门，都能成为未来IT行业的超级精英。
回到软件本身上来，可以说，beta 版本的『近取Key』已经几乎实现了我们在 alpha 开发伊始所能设想到的全部的功能，『记忆宫殿』、『A4纸背单词』这些最核心的创意与逻辑均已得到了淋漓尽致地展现，此外还增加了诸如自定义加词、智能推荐等等意料之外的功能。但是，这还不能说它已经足够完美了，只能说这是我们6个人在短短2个月时间内，在无数烤漆裹挟下，在极有限的资源加持下，所能交出的一份最好的答卷。
但是，这绝不是这个软件本身所能达到的最完美的形态。
无论是从软件本身的可维护性、安全性、跨平台兼容性，还是从用户体验视角下使用的流畅性、健壮性、交互友好性，抑或是从商业视角下的盈利能力、宣发能力，我们和它都还有很长很长的一段路要走；甚至也许，这条由我们亲自开辟的路，永远也不会有所谓的尽头。
毕竟，对我个人而言，团队项目带给我最大的收获，就是有幸遇见了优秀的你们呀。
