软件工程个人总结作业

学期总结

持续一个学期的软件工程课程告上了一个段落,在学期的结尾,回望这学期的课程,想起那些和团队一起奋斗的日日夜夜,收获和感想太多,想说的也很多。
这学期软工的课程选课的人数不多,到最后也只剩了18个人,分成四个组,于是我们团队,就成立了四个人这个有史以来最小规模的软工团队。
选择项目的时候,我们一致同意了选择一个自选项目,经过某个下午的讨论,敲定做一个狼人杀助手的app。
可能是为着一种执拗和挑战,在一开始我们就决定要做一个不止运行在安卓平台,要同时在安卓和iOS平台上运行的应用。于是为着这个前提,我们在为数不多的跨平台开发方案中选择了React Native来进行开发。
刚开始的我们并没有意识到这是一个多么具有跨跃性的前端技术。以至于到了后来整个alpha阶段大半的时间都用在了学着用javascript这个看着很不前端的语言写前端。虽然写出来的代码可以同时运行在两个平台上,但是这极高的学习成本不得不说是一个在以后必须考虑的因素。
而且软件开发的整个项目进程是动态的,如果想我们团队这样选择上手一个新技术,那么前期的代码必然有很多不规范杂乱的部分(虽然我们使用了dva框架给整个项目搭了一个很好的结构,但是最开始开发时候很多代码不知道放到哪里)越滚越多形成一个大泥球,可读性非常低,我在beta阶段又花了很多时间重构这部分的代码。
然后说说我们项目的另一大核心Web Socket,这个技术最开始是因为需要服务器与客户端之间的通讯而引入,但是越用越发现了其中的坑实在是太多。这个技术和普通的http通信一去一回不同,要建立服务器与客户端的双向链接,但是这个链接又很不可控,经常莫名其妙发生丢包和通信延迟的问题,后期虽然引入了短线重连和服务端检查,但是还是没有解决。一个实时的在线网游确实不好做,尤其对于我们这种四个人的小团队来说。
不过,一个学期下来,收获还是满满的,感谢另两位负责前端的队友韩青长和陈彦吉同学,还有独自挑起后端重担的陈鸿超同学。正是由于我们四人团队的坚持与执着,这个软工项目才不至于半途而废。

关于学期前提出的问题

关于变量名的问题

  在书中我看到了在C等弱类型语言中因为变量语义多样所以需要用“匈牙利命名法”等方法来规范变量的命名。实际在我平时的编程之中,对于变量的命名也有很大的困惑,见到有些同学的拼音首字母命名法等等,我想问一下,在实际的工程运用中,对于变量命名又是怎样处理的呢?有没有一个约定俗称的规范呢?如何才能写出更加工程化的命名方式?这点在书中并没有详细说明。

并没有明确的答案,不过在后来的编程实践中,我们采取了查字典的方式命名名词性变量,然后操作类就用动词+操作对象命名,还是比较清晰易懂的。

关于结对编程的问题

  在阅读课本之前,我脑海中对于结对编程的概念是两个人分配好任务,然后各自完成。但是在书中介绍的结对编程却是两个人共用一台显示器一个键盘同时完成一部分程序。这个在实际操作中我认为会有很多的限制,我们课程中的结对编程也要求这样编么?现实的在软件开发企业中,真的有很多人会结对编程么?

这个项目下来,可能正好是我们之前想的浪费时间的结对编程,产出了最有效率的劳动。但是我们后来才用的不能说是严格意义上的结对编程,而是一种大家坐到一块互相商量讨论的模式。也正是这种模式,我认为是最适合熟悉新技术阶段的。

关于编程流程的问题

  在书中介绍了很多编程流程的框图,但是之前并没有接触过类似的编程流程,所以在脑海中印象不深。不知道在之后的学习之中是否会实践这些编程流程呢?有些编程流程看起来过于冗长了并且有很多不必要的工作。现在的软件开发是怎样进行的呢?

我们在实践中,主要采用的是 提出需求/研究技术/验证技术/具体编码/代码复审/提交合并这个流程

关于敏捷编程的问题

  敏捷编程最重要的一个前提就是scrum master要将当前的任务切成一个一个的小块。但是在实际工作中,往往有些工作是不能被分割的,这时候该如何是好呢?还有在这个体系中,是不是过于依赖scrum master的个人能力了呢?感觉整个团队是否能够做好工作,都取决于他的任务分配和互相协调了。

解决方案总比问题多,在实践过程中,基本不会出现这样的大任务,而分配流程也是相当的轻松加愉快。

关于单元测试的问题

  在上学期的OO课程中,我第一次接触到了单元测试。但是,我对此有些疑问,真的做到了100%覆盖,我觉得并不能保证代码就是正确的,因为往往这个时候会有一些情况的分支没有考虑到,而这些分支的确实会导致程序最后的崩溃和功能问题。

我们的项目性质就导致无法进行单元测试,只能手动进行测试,在测试过程中,主要通过输出log文件的方式验证。

请问你们在项目的 需求/设计/实现/测试/发布/维护 
阶段(一共6 个阶段)中都学到了什么 “知识点”, 每个阶段只要说明一个知识点就可以。

需求阶段:需求分析要结合实际,要通过用户调查,调查结果说话!不要臆想用户需求。
设计阶段:选择合适的项目组中有人掌握的技术,这样不至于整组人都像没头苍蝇一样乱转。
测试阶段:测试还是要进行自动化测试,手动测试的效率太低,成本太高。
发布阶段:发布阶段前要进行内测,让那些影响用户体验的bug早日报出,不至于影响真实用户
维护阶段:维护阶段发现的bug要及时更正,最好派出专门人员维护服务器。

posted @ 2017-01-13 03:01  shhr  阅读(704)  评论(4编辑  收藏  举报