咱们在学期开始的时候布置了阅读做业,要你们快速阅读,同时提出本身的问题。
如今一个学期过去了,同窗们完成了一个结对项目,两个阶段的团队项目,中间还经历了转会环节。
正所谓"实践是认识的来源、目的、动力以及检验认识真理性的惟一标准",在经历了一个学期的学习和实践后,请你们写一个提问回顾与我的总结的博客。html
项目 | 内容 |
---|---|
这个做业属于哪一个课程 | 博客园班级连接 |
这个做业的要求在哪里 | 提问回顾与我的总结 |
我的博客做业 | 初窥软件工程 2020BUAA软件工程⋅我的博客做业 |
我在这个课程的目标是 | 得到成为一名软件工程师的能力 |
这个做业在哪一个具体方面帮助我实现目标 | 总结回顾 |
答:单元测试的粒度,依项目而定。例如在团队项目中,咱们作的知识路书web应用,其前端的单元测试是以任务功能进行划分的,输入的数据即为覆盖该功能模块所有逻辑的一组操做。对于结对编程项目,单元测试应该以函数或类为单位,输入输出的数据即按照类的构造函数或函数的输入参数进行。前端
答:使用集成开发环境的git GUI工具,能够更加方便地编辑message,甚至支持markdown语法。还能够github平台的pull request功能,可以更加清晰地写清某次代码迁入作的功能是什么。团队开发时,要商议好commit的message和Pull request的message格式规范,例如咱们的敏杰开发团队规定的commit格式为:姓名:功能1;功能2;...git
这个问题理论上可使用git rebase的方法进行,可是容易出错,不是很安全。在咱们的团队项目开发过程当中,直接使用顺序commit式bug修复,因为不多使用代码回滚,维护的最新版代码始终是当前功能最多、bug最少的版本。github
不一样开发者尽可能不要同时修改相同的文件,每一个Issue和Pull request的粒度尽量细就能够更好地保证这一点。若是真的遇上了必需要修改相同文件的话,两者须要一块儿合并代码,保证双方的更改不出现冲突。在咱们团队项目的实际开发过程当中,每一个人负责开发的部分几乎少有文件重叠,固然也有少许状况出现了代码冲突的状况,咱们是经过有冲突的开发者共同解决冲突的办法处理的。web
对于咱们的团队项目知识路书的开发初期,只有hdl一名同窗拥有开发经验,其它成员都是开发小白,可是咱们队伍的成员都有很强的快速学习能力,咱们经历了2年的编程训练,已经有很好的编程功底,通过熟悉开发的成员一带,很快就掌握了基本的开发技术,以后就是滚雪球式的技术积累了,在完成了alpha阶段的开发任务后,咱们的开发技术就均可以知足咱们项目的需求了。编程
对于技术初创公司,技术当然重要,可是必定不能掉进惟技术论的怪圈,只顾技术,永远在迭代产品、优化产品,而不去想推广、想营销。企业总归是要以营利为目的的,推广、营销能够带来更多的用户,带来更多的用户反馈,使团队更清楚产品的真正需求。同时推广营利能够招揽更多人才,有更多优秀且志同道合的人加入,一样会进一步促进技术的发展。后端
软件工程解决不了的问题是现有的管理学理论没法很好解决的问题,没法抽象成统一的理论,这类问题的解决要因人而异、因事而异。不一样的开发团队、不一样的开发产品都会有不一样的解决方法,因此说管理学是一门艺术,软件工程管理亦是如此,一个软件工程项目的成败、管理好坏,软件工程理论当然重要,但产品经理、项目负责人的管理艺术每每更能决定产品的命运。因此,软件工程的痛点也在于此,只有将软件工程理论,和实践、经验深入结合、互相补充,才能早就一个优秀的产品经理,造成优质的团队管理文化。api
在《人件》中介绍了有凝聚力团队的概念,你们都秉持相同的价值观念、产品观念,团队总体的力量将大于个体之和。可是当团队成员对价值观念、产品观念有不一样观点时,应该如何解决观念上的不一致、从新回到一个有凝聚力的团队总体呢?安全
当观点可调和时,采用讨论分析等办法能够得出一个最优的解决方案,让团队中的全部成员承认。可是当观点矛盾不可调和时,又该怎么办?独裁?分裂?仍是...markdown
当一个产品的实现难度、投入资源、预期收益等与原定设想不符时,团队会倍感沮丧,凝聚力和干劲都会大打折扣。做为项目负责人,有抉择坚持仍是放弃的责任,在何种条件下能够下定决心放弃?有没有理论上的一种条件,达到这种条件就应该放弃,坚持就是浪费资源?
在团队项目中,咱们在实践中学到不少软件工程的知识点,下面分类进行介绍。
需求分析是一个软件工程项目的第一步,抓住一个好的需求每每是项目成功必要条件。咱们敏杰开发团队,通过若干次会议的头脑风暴,碰撞出了几个有痛点的需求,当时的选择有三:
通过NABCD分析,咱们最终得出,图形化文献管理工具这个需求咱们团队更能驾驭,咱们自己就是该项目的目标用户,能够更直接准确地分析出需求。因而咱们选择了知识路书——图形化文献管理工具这个项目做为咱们的开发目标。
经过撰写技术规格说明书和功能规格说明书,咱们更加清晰地描述了整个项目的设计。在实际操做中,咱们在组会中共同绘制ER图,成员一块儿在一份ER图上添枝、加叶、修改,最终共同碰撞出了一份完整、清晰的项目架构,团队成员也都明确了项目的整体设计。在肯定了项目的整体设计后,咱们讨论了实现上的设计,因为目前web端应用的受众广、可移植性强、移植性好,咱们选择了基于web平台的实现设计,并进一步肯定了选择的先后端框架、平台、工具等,你们开始了前期的学习准备工做。
咱们首先根据项目特色进行人员分工,咱们的项目主打前端应用,后端主要提供CURD等api支持,因此前端共4名成员,后端2名,1人PM兼自由人,能够根据开发进度补充至前端或后端。在开发过程当中,咱们采用增量式敏捷开发工做流,在alpha阶段完成了最核心的功能,完成了一个最小可用版。在beta阶段,持续重构与优化alpha阶段的工做,并增量式添加新的功能。在开发中,相似每日构建原则(daily build),咱们作到了实时构建(always build),咱们保证每一次提交都必须可运行,在代码互审时,不只仅要展现所改动的模块是否工做正常,还应简要回归测试原有功能,保证产品时刻可运行。
在项目管理中,咱们学到了很是多的知识,在beta阶段新成员进组时,咱们向其介绍了咱们团队的整个项目工做流,让其颇为惊叹,这才是软件工程。关于咱们的项目管理能够参考个人这篇博客使用Github进行软工开发管理
因为是敏捷开发,在测试中也采用敏捷开发的风格,咱们的实时构建(always build)原则能尽量保证前端在开发过程当中的持续测试,每位成员在开发本身功能的时候,均可以不经意地测试网页其它部分的功能,一旦发现问题,当即写入Issue。因为开发过程当中已经针对功能进行了较多的单元测试,在实际测试阶段咱们重点进行了场景测试,将用户的使用流程分红若干个工做场景,对软件进行总体测试,保证用户不会触及最明显的bug,另外还能够以用户的身份体验产品,获得新的改进需求。
对于后端,咱们采用了覆盖率测试,使用成熟的测试框架,使测试覆盖率达到90%以上,保证了后端api的稳定与精准。
咱们在alpha阶段的推广出现了一些失误,致使了推广效果不佳。主要缘由是选错了“目标用户”,咱们的产品主要面向有科研需求的研究生、博士生、导师等,而在alpha阶段,咱们重点向本科生进行推广,致使咱们没有达到预期用户量。在beta阶段,咱们根据目标用户的使用特征,定向地推广给实验室的研究生,让他们在组会中尝试使用咱们的软件,得到了不错的推广效果。另外咱们还作了针对本科生科学方法论课程的杀手功能,能够利用这个功能,让同窗们更方便地完成该课程的要求,咱们在科学方法论课堂上展现了咱们的产品,也收获了很多的用户。因此,对于软件工程,开发技术当然重要,推广的技巧也必不可少,否则就只是写程序,而不是写软件了。
对于维护,用户的bug反馈十分重要,咱们在开发初期,就在页面中加入了bug反馈入口,在两个阶段的开发中,已经收到了大量的反馈信息,其中不乏对于bug的反馈。
另外,成熟的文档也必不可少,咱们分别针对前端、后端、用户写了三份详细的文档,保证了后续接手的开发人员和维护人员能够快速上手。
一学期的软件工程课收获满满。软件工程课就应该在作中学、学中作。团队项目中,我从一个开发小白的身份在alpha开发阶段一点点摸爬滚打,从咱们的前PM大佬学到了不少开发技术、项目管理方法。进入beta阶段后,我有幸接替原PM大佬的工做成为PM,和团队成员一块儿不断完善咱们的产品。PM的经历让我实践了更多软件工程领域的学问,我学会了如何与人沟通、如何分配任务、如何督促监管任务的执行、如何与团队合做等等。看着咱们的产品从无到有再到基本健全、收到用户的积极反馈,真的是一件无比享受且欣慰的过程。我会珍惜此次软件开发经历、珍惜一块儿结对编程的小伙伴、珍惜在北航度过的软件工程时光~
2020.6.14 补充:最近中国若干高校被封锁了matlab软件,引发了国内社会的不小争议。我以为相似Matlab这种重要的科研软件,我国须要投入人力和资金进行研发,对于这类大致量软件的开发,软件工程理论的指导不可或缺,国内的各大高校计算机专业和软件专业应该更加剧视软件工程课程的质量,培养更多优秀的软件工程技术人员。