软件工程基础 完结撒花

一点说明

这篇博客是软件工程基础（罗杰、任建）的最后一次课程博客做业。

项目	内容
这个做业属于哪一个课程	软件工程基础（罗杰，任建）
这个做业的要求在哪里	做业要求的连接
我在这个课程的目标是	提高对软件工程的宏观和微观的全面认识，并加以实践
课程在哪些方面帮助了我	方方面面，下文中将详细分析与回顾
团队项目的网址（欢迎访问）	http://ddlkiller.top

1、提问回顾

问题1. 我的开发流程（PSP）中关于测试环节的设计是否合理？

在以前的提问中，个人观点是“不该将测试环节安排在具体设计、具体编码和代码复审以后，而是应该在代码设计与编码过程当中同步进行测试”。

​ 通过了一学期”软件工程“的实际体验，我认识到以前的观点是片面的。测试，我认为能够分为两步——自测和他测。“自测”是指团队内部的测试，既包括编码人员对本身代码的简单功能验证，也包括团队内的测试人员进行的单元测试、压力测试等等。充分的自测每每能够从技术层面尽量多的减小BUG，可是产品终究是要面向用户的，因此“他测“也是必不可少的。“他测”是团队外部的测试，产品用户在实际使用中发现BUG（如操做逻辑不符合直觉、功能缺失或冗余后，经过反馈渠道对开发团队进行反馈，开发者经过必定的分析手段从收集到的全部反馈中提炼出有价值的问题，进而能够肯定下一步改进的方向及措施，这也是一个测试的过程，也是提升产品力的一个关键措施。

​ 那么回到以前的问题，测试环节到底放在哪里更加合适呢？我以为应该“有零有整”。一方面，将测试环节融入到具体编码与代码复审中。具体的作法是，咱们能够借鉴契约式编程的思想，在项目正式进行编码开发以前，不只对项目工程的总体逻辑进行设计，还要经过相似JML的格式，对工程中的每一个类、类中的每一个方法进行一个功能和结构上的详细规范，造成一个个的规范文件。在这些规范文件上进行开发，既方便编码人员的自我测试，也方便单元测试集的构建，将测试轻量化，从而能够与编程环节良好的结合。另外一方面，要在具体编码与代码复审后进行独立的测试环节，即对代码实现的系统性的测试，包括“自测”和“他测”。“当局者迷，旁观者清”，独立的测试环节主要是细节的纠错和完善，也是相当重要的。

问题3. 如何更好地管理”人件“？

本书的 11.6 节引伸的博客提到，

“如何在软件工程这门课上模拟出相似真实软件开发的环境，仍是须要‘大智慧’的人去发现”。

​ 反思整个 DDLKiller 开发过程当中咱们团队的状态以及状态的变化，我认为咱们经过必定的规则规约，作到了将 “你们约束在必定的权力和利益的关系之中”，从而“各个角色可以各司其职、各尽其能”。归纳下来主要有如下几点经验。

​ 一是作好任务细化。这一点看似日常实则关键，咱们团队发现的一个行之有效的方法是制定详细的任务清单，团队中的每一个人都像是一个 赏金猎人，完成分配的任务就像是“打怪升级”。若是在规划时将任务尽量的细化、明确化，就能够减轻开发人员的负担，也使得开发人员更加有积极主动性，从而轻松愉悦也更加高效地进行开发工做。

​ 二是用好“胡萝卜”与“大棒”。我还未接触过真正的商业中的“软件工程”，不知道将软件开发放在商业环境中会有什么其余的规律。可是根据本学期软工课程的体验，我认识到营造出一种积极奋进、每一个人的内外压力均衡的团队氛围是相当重要的，而合理地平衡“胡萝卜”与“大棒”就是其关键一环。例如，在Alpha阶段，课程组制定了“强制转会”的规则，不过关就淘汰（毕竟通常状况下，谁也不想放手本身从无到有参与开发的软件），这就有一丝人人自危的味道了，这就是“大棒”。而若是积极表现，既能收获贡献分又可以从一而终地完善做品，这就是“胡萝卜”。固然，企业中的“胡萝卜”更甜，“大棒”打在身上也更痛，可是这种辩证统一的关系应是一致的。

​ 三是保持恰当的距离。因为疫情的不可抗力，本学期全部工做都只能转移到线上，我我的认为这反而有助于开发工做（仅指本课程的开发任务）的高效进行，由于团队成员之间得以拥有一种比较合适的距离——一方面，依托Gitee等工具，咱们得以实现线上开发0距离，而线上便捷的实时交流、说开就开的腾讯会议等也让你们的交流0距离；另外一方面，只要下了线，你们又是天各一方（∞ 距离），因此相对来讲你们有了更大的自由度，来更加自如地安排本身的时间。换个说法，就是每一个成员对于其余成员或PM来讲，都是一个 “黑箱” ，他只须要在指定时间交付上任务便可，中间的实现过程是不受监控的、彻底自由的。这必定程度上也避免了不少不必的冲突和摩擦，让开发工做得以和谐地推动。

问题4. 如何设计软件使软件拥有更多的受众，甚至打造国民级软件？

在以前的提问中，个人主要问题是”如何才能赢得 ‘沉默的大多数’ “。

​ 这个问题如今于我来讲依然无解。在咱们团队项目的推广中，其实也没有很好的解决这一问题。其实 “沉默的大多数” 之因此沉默，我能想到的有如下几种可能。一是他们已经习惯了“沉默”，他们产生反馈的阈值很高，只要这个产品的核心功能能够较好运行，小的BUG不足以提供他们反馈的动力，你若强迫他们反馈，极大可能只能收到一个“好”或“很差”，也许你新加了一个功能、新补了一个BUG，他会感叹“哇，比之前好用了”，可是仅此而已；二是软件提供的反馈时机不对，从技术层面，我认为运行出现BUG的时候当即弹出反馈渠道是最佳的选择，可是若是考虑到须要收集多元化的用户反馈信息，这个时机的选择可能要具体问题具体分析了。

​ 正如王小波先生所说，“在一个喧嚣的话语圈下面，始终有个沉默的大多数”。我认为打造国民级软件的重要一环，就是发掘“沉默的大多数”的需求。也许，他们不发声，咱们也能“听”到他们的声音。答案，我尚未答案。

问题2. 如何恰当的使用goto语句 & 问题5. 科研与创新的关系

​ 问题2实属无稽之谈，而问题5还未有新的想法，故暂且不表。

2、新的问题

问题1. 如何在开发中如何准确划分需求的等级？有没有相关的工程理论或准则？

​ 换言之，如何给软件的优化需求进行一个“轻重缓急”的优先级排序呢？好比，在团队项目开发时，Beta阶段，我对“添加新日程”这一操做进行了从新设计，以下图。在新的版本中，我添加了 “回车快速建立” 功能，在详细建立页中增添了默认的快捷日期和时间，同时支持自动根据描述添加标题，并且整个的UI也进行了从新设计。

​ 这个优化目前看来彷佛没有什么很差，可是，其实在优化以前，我面临着两个选择，一是图中所展现的，另外一个则是 增长AI自动识别内容并自动添加日程的功能，即自动识别 时间、地点、参与者等关键词并添加。因为时间有限，我只能二选一，而实际发布之后，我忽然意识到，其实被我pass的功能或许才是 杀手功能。可是为时晚矣……

问题2. 不一样团队成员对产品定位和发展方向理解不一样，致使在具体功能设计中发生冲突，如何解决？

​ 咱们团队采起的方法是 “搁置争议，共同发展” 和 “谁提出谁解决” ，即若是在某一个功能的增减上发生了冲突，优先选择 “我全都要”，可是对于较难实现的需求，秉持“谁提出谁解决”的方案。这样的作法的好处是，极大地避免了团队内的冲突。可是，这种方法显然不是万全之策。从某种程度上来讲，它并无解决问题，而是逃避了问题。那么在实际的软件工程中，应该如何处理这些冲突呢？

3、学到了！

4、心得体会

我的项目 —— 革命还没有成功，同志仍需努力

​ 软工的我的项目难度并不大，可是在实现过程当中，我仍是对本身的数学知识的遗忘和匮乏有了更深的认识。尤为是，在思考程序优化时，彻底没有头绪，感受无处下手。后来观摩了文瑄老哥的优化方法，看到他使用流水线等方法一层层地抽丝剥茧，最终得出解法，心里实在敬佩。将来但愿本身也能更进一步，认真学习数理知识，在思考和实践中融会贯通。

结对项目 —— 凡事预则立不预则非

​ 第一次接触结对项目，我以为我没有作得很好，可是在与结对伙伴一块儿探索的过程当中，仍是收获了不少。好比，高效沟通的秘诀在于沟通以前的准备，准备的越充分，沟通的效率越高，若是沟通前没有作好准备，那么沟通必定是低效的，甚至是徒劳的。咱们也再一次被生活毒打——因为最初对松散耦合的实现要求没有理解到位，咱们在完成与其余组对接时重构了咱们的代码。这也让咱们明白了两个道理，一是磨刀不误砍柴工，二是凡事预则立不预则非。

团队项目 —— 用众人之力，则无不胜也

​ 本学期在团队项目上的耗时最多，收获也最大。体验了软件开发的全流程，也见识了强制转会等生活的残酷一面。收获在上一部分已经分享了，下面说说个人一些体会。咱们团队整个的工做氛围是比较轻松的，你们原本就很熟，而后也都很上进，虽然到了后期你们都很忙，有一些懈怠，可是在软件的攻坚期，你们相互鼓励、相互帮助，各自发挥所学和所长，一块儿克服困难，最终攒出一个发布版来出来，真的是很是有成就感的！

​ 最后附上咱们团队成员的简介，很是开心可以和你们一块儿完成 DDL Killer ，感谢每一位给予个人帮助，有机会再约一波深夜DEBUG局☺。