一点说明
这篇博客是软件工程基础（罗杰、任建）的最后一次课程博客作业。
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 软件工程基础（罗杰，任建） |
| 这个作业的要求在哪里 | 作业要求的链接 |
| 我在这个课程的目标是 | 提升对软件工程的宏观和微观的全面认识，并加以实践 |
| 课程在哪些方面帮助了我 | 方方面面，下文中将详细分析与回顾 |
| 团队项目的网址（欢迎访问） | http://ddlkiller.top |
一、提问回顾
问题1. 个人开发流程（PSP）中关于测试环节的设计是否合理？
在之前的提问中，我的观点是“不应将测试环节安排在具体设计、具体编码和代码复审之后，而是应该在代码设计与编码过程中同步进行测试”。
经过了一学期”软件工程“的实际体验，我认识到之前的观点是片面的。测试，我认为可以分为两步——自测和他测。“自测”是指团队内部的测试，既包括编码人员对自己代码的简单功能验证，也包括团队内的测试人员进行的单元测试、压力测试等等。充分的自测往往可以从技术层面尽可能多的减少BUG，但是产品终究是要面向用户的，所以“他测“也是必不可少的。“他测”是团队外部的测试，产品用户在实际使用中发现BUG（如操作逻辑不符合直觉、功能缺失或冗余后，通过反馈渠道对开发团队进行反馈，开发者通过一定的分析手段从收集到的所有反馈中提炼出有价值的问题，进而可以确定下一步改进的方向及措施，这也是一个测试的过程，也是提高产品力的一个关键措施。
那么回到之前的问题，测试环节到底放在哪里更加合适呢？我觉得应该“有零有整”。一方面，将测试环节融入到具体编码与代码复审中。具体的做法是，我们可以借鉴契约式编程的思想，在项目正式进行编码开发之前，不仅对项目工程的整体逻辑进行设计，还要通过类似JML的格式，对工程中的每个类、类中的每个方法进行一个功能和结构上的详细规范，形成一个个的规范文件。在这些规范文件上进行开发，既方便编码人员的自我测试，也方便单元测试集的构建，将测试轻量化，从而可以与编程环节良好的结合。另一方面，要在具体编码与代码复审后进行独立的测试环节，即对代码实现的系统性的测试，包括“自测”和“他测”。“当局者迷，旁观者清”，独立的测试环节主要是细节的纠错和完善，也是至关重要的。
问题3. 如何更好地管理”人件“？
本书的 11.6 节引申的博客提到，
“如何在软件工程这门课上模拟出类似真实软件开发的环境，还是需要‘大智慧’的人去发现”。
反思整个 DDLKiller 开发过程中我们团队的状态以及状态的变化，我认为我们通过一定的规则规约，做到了将 “大家约束在一定的权力和利益的关系之中”，从而“各个角色能够各司其职、各尽其能”。概括下来主要有以下几点经验。
一是做好任务细化。这一点看似平常实则关键，我们团队发现的一个行之有效的方法是制定详细的任务清单，团队中的每个人都像是一个 赏金猎人，完成分配的任务就像是“打怪升级”。如果在规划时将任务尽可能的细化、明确化，就可以减轻开发人员的负担，也使得开发人员更加有积极主动性，从而轻松愉悦也更加高效地进行开发工作。
二是用好“胡萝卜”与“大棒”。我还未接触过真正的商业中的“软件工程”，不知道将软件开发放在商业环境中会有什么其他的规律。但是根据本学期软工课程的体验，我认识到营造出一种积极奋进、每个人的内外压力均衡的团队氛围是至关重要的，而合理地平衡“胡萝卜”与“大棒”就是其关键一环。例如，在Alpha阶段，课程组制定了“强制转会”的规则，不过关就淘汰（毕竟一般情况下，谁也不想放手自己从无到有参与开发的软件），这就有一丝人人自危的味道了，这就是“大棒”。而如果积极表现，既能收获贡献分又能够从一而终地完善作品，这就是“胡萝卜”。当然，企业中的“胡萝卜”更甜，“大棒”打在身上也更痛，但是这种辩证统一的关系应是一致的。
三是保持恰当的距离。由于疫情的不可抗力，本学期所有工作都只能转移到线上，我个人认为这反而有助于开发工作（仅指本课程的开发任务）的高效进行，因为团队成员之间得以拥有一种比较合适的距离——一方面，依托Gitee等工具，我们得以实现线上开发0距离，而线上便捷的实时交流、说开就开的腾讯会议等也让大家的交流0距离；另一方面，只要下了线，大家又是天各一方（∞ 距离），所以相对来说大家有了更大的自由度，来更加自如地安排自己的时间。换个说法，就是每个成员对于其他成员或PM来说，都是一个 “黑箱” ，他只需要在指定时间交付上任务即可，中间的实现过程是不受监控的、完全自由的。这一定程度上也避免了很多没必要的冲突和摩擦，让开发工作得以和谐地推进。
问题4. 如何设计软件使软件拥有更多的受众，甚至打造国民级软件？
在之前的提问中，我的主要问题是”如何才能赢得 ‘沉默的大多数’ “。
这个问题现在于我来说依然无解。在我们团队项目的推广中，其实也没有很好的解决这一问题。其实 “沉默的大多数” 之所以沉默，我能想到的有以下几种可能。一是他们已经习惯了“沉默”，他们产生反馈的阈值很高，只要这个产品的核心功能可以较好运行，小的BUG不足以提供他们反馈的动力，你若强迫他们反馈，极大可能只能收到一个“好”或“不好”，也许你新加了一个功能、新补了一个BUG，他会感叹“哇，比以前好用了”，但是仅此而已；二是软件提供的反馈时机不对，从技术层面，我认为运行出现BUG的时候立即弹出反馈渠道是最佳的选择，但是如果考虑到需要收集多元化的用户反馈信息，这个时机的选择可能要具体问题具体分析了。
正如王小波先生所说，“在一个喧嚣的话语圈下面，始终有个沉默的大多数”。我认为打造国民级软件的重要一环，就是发掘“沉默的大多数”的需求。也许，他们不发声，我们也能“听”到他们的声音。答案，我还没有答案。
问题2. 如何恰当的使用goto语句 & 问题5. 科研与创新的关系
问题2实属无稽之谈，而问题5还未有新的想法，故暂且不表。
二、新的问题
问题1. 如何在开发中如何准确划分需求的等级？有没有相关的工程理论或准则？
换言之，如何给软件的优化需求进行一个“轻重缓急”的优先级排序呢？比如，在团队项目开发时，Beta阶段，我对“添加新日程”这一操作进行了重新设计，如下图。在新的版本中，我添加了 “回车快速创建” 功能，在详细创建页中增添了默认的快捷日期和时间，同时支持自动根据描述添加标题，而且整个的UI也进行了重新设计。
这个优化目前看来似乎没有什么不好，但是，其实在优化之前，我面临着两个选择，一是图中所展示的，另一个则是 增加AI自动识别内容并自动添加日程的功能，即自动识别 时间、地点、参与者等关键词并添加。由于时间有限，我只能二选一，而实际发布以后，我突然意识到，其实被我pass的功能或许才是 杀手功能。但是为时晚矣……
问题2. 不同团队成员对产品定位和发展方向理解不同，导致在具体功能设计中发生冲突，如何解决？
我们团队采取的方法是 “搁置争议，共同发展” 和 “谁提出谁解决” ，即如果在某一个功能的增减上发生了冲突，优先选择 “我全都要”，但是对于较难实现的需求，秉持“谁提出谁解决”的方案。这样的做法的好处是，极大地避免了团队内的冲突。但是，这种方法显然不是万全之策。从某种程度上来说，它并没有解决问题，而是逃避了问题。那么在实际的软件工程中，应该如何处理这些冲突呢？
三、学到了！
四、心得体会
个人项目 —— 革命尚未成功，同志仍需努力
软工的个人项目难度并不大，但是在实现过程中，我还是对自己的数学知识的遗忘和匮乏有了更深的认识。尤其是，在思考程序优化时，完全没有头绪，感觉无处下手。后来观摩了文瑄老哥的优化方法，看到他使用流水线等方法一层层地抽丝剥茧，最终得出解法，内心实在敬佩。未来希望自己也能更进一步，认真学习数理知识，在思考和实践中融会贯通。
结对项目 —— 凡事预则立不预则非
第一次接触结对项目，我觉得我没有做得很好，但是在与结对伙伴一起探索的过程中，还是收获了很多。比如，高效沟通的秘诀在于沟通之前的准备，准备的越充分，沟通的效率越高，如果沟通前没有做好准备，那么沟通一定是低效的，甚至是徒劳的。我们也再一次被生活毒打——由于最初对松散耦合的实现要求没有理解到位，我们在完成与其他组对接时重构了我们的代码。这也让我们明白了两个道理，一是磨刀不误砍柴工，二是凡事预则立不预则非。
团队项目 —— 用众人之力，则无不胜也
本学期在团队项目上的耗时最多，收获也最大。体验了软件开发的全流程，也见识了强制转会等生活的残酷一面。收获在上一部分已经分享了，下面说说我的一些体会。我们团队整个的工作氛围是比较轻松的，大家本来就很熟，然后也都很上进，虽然到了后期大家都很忙，有一些懈怠，但是在软件的攻坚期，大家相互鼓励、相互帮助，各自发挥所学和所长，一起克服困难，最终攒出一个发布版来出来，真的是非常有成就感的！
最后附上我们团队成员的简介，非常开心能够和大家一起完成 DDL Killer ，感谢每一位给予我的帮助，有机会再约一波深夜DEBUG局☺。
