【软件工程】 第1次团队做业

项目	内容
这个做业属于哪一个课程	软件工程 罗杰
这个做业的要求在哪里	第一次团队做业
咱们在这个课程的目标是	熟悉软件开发总体流程，提高自身能力
这个做业在哪一个具体方面帮助咱们实现目标	第一次体验一个完整的工程

团队成员介绍

    对没错！咱们就是葫芦娃！！

    咱们的团队由七位男生组成，他们分别是：

• 大娃

      “热爱生活、热爱挑战、热爱编程的大三“准程序猿”一枚”
  

• 二娃

      “男，21岁，爱好足球、乒乓球、打游戏，精通C、Java等语言”
  

• 三娃

      “心走得很远，但身体仍在北航的幻想型程序猿，本科所学略知一二，本科以外一无所知（qwq）的萌新”
  

• 四娃

      “马四娃，男，北航6系普通学生，业余阿森纳球迷，专业低级码农。C,C++,Java,JavaScript,Python都能写，但都不精通。磕磕碰碰，成功完成了两年半的本科学习，有点幸运。没什么项目经历，作的都是些不值一提的小玩意。做为开发组的一员会在团队做业中尽力的。”
  

• 五娃

      “率真，乐观。人生不长，作想作的事，见想见的人，创造想创造的代码！”
  

• 六娃

      “乐观，进取；爱动漫，爱篮球，虚心学习，敢于尝试，追逐梦想；熟悉c/c++、java等语言，积极作好力所能及的事。”
  

• 七弟

      “计算机学院学生，偶尔打打篮球，超爱游戏的咸鱼程序员一枚”
  

咱们团队成员的初步分工以下：

PM： 二娃、三娃

开发组： 大娃、四娃、五娃、七弟

测试组：六娃

学长的经验之谈

软件工程这门课已经开设了几年的时间，之前也有不少学长作过团队项目，为了更好的推动咱们的项目，咱们请到了15级的刘子渊学（巨）长（佬）来学习经验。

“当时的项目有多少用户？给用户多少价值？如今还有人用嘛？”

当时完成了一个物理实验报告的在线生成网站，用户数没有一个具体的统计。

“这个项目可否让咱们团队继续开发呢？”

固然能够继续开发，若是咱们的版本不行的话大家也可使用再上一届的版本。不过大家也能够写一些本身喜欢的、感兴趣的东西。

“项目开发有什么样的经验或教训呢？”

经验和教训的话，就要有一个充分的准备，也要有一个计划，好比说对作好一个项目的时间成本有估计嘛？遇到一个新的框架，打算用多久来熟悉它呢？可能概念和语言都和大家以前学的彻底不一样，也要写很长的文档，每周可能要花 3*8 个小时来推动项目，那么具体要怎么推动呢？

我的建议能够天天坐在一块儿干活，中午的时候一块儿吃饭，相互聊聊项目进展怎么样。我本身当时的教训就是时间不是很够，对其余人的进度失控。我认为软工主要分为两部分，一部分是对代码的控制，一部分是对进度的控制。代码控制还好一些，好比说代码规范、版本、工做流之类，有linter还有git flow。进度控制就是一个比较虚的东西，不太好衡量但又必须衡量。要学好软工我以为主要仍是进度控制。

“可咱们对工程的概念挺模糊的，也不知道到底有多大的工做量，老师助教只说要1W行代码左右，但不一样的封装程度和语言，1W行代码能干的事区别可太大了，因此感受......确实挺模糊的”

因此大家学很差软工。

“那学长对学好软工有什么样的建议呢？（绝望.jpg）”

我就说说不谈时间的对工程的认知吧。怎么设计结构？这个应该是OOP。而后是文档，文档决定了你的项目是否能长久。文档包括tutorial，manual和documentation。

Tutorial是用来告诉什么都不知道的人这个项目是如何运行的。Manual包括每一个模块的做用，以及和其余模块的相互做用，想开发一些功能应该如何修改。Documentation就是API文档。

我认为manual是最重要的，它关系到项目的可扩展性，API文档就像人心涣散，manual负责有逻辑的将他们串起来。API是当你已经知道了每一个地方怎么连起来了，而后也知道有相似的例子，但你对每一个参数的意义和返回值的意义不是很清楚，或者想看看这个模块有什么能够用的，你才去查API文档。就好像你Cpp遇到一个东西，想用可变长数组，你去百度，人家推荐你Vector，而后会说明一些做用和例子，这里面就包含了tutorial和manual的东西。等你大概明白是怎么回事了，但可能用起来还不是太方便，你会想去查查cppreference，看看vector具体怎么用，好比我能不能得到头元素和尾元素？能不能把两个vector拼接在一块儿？这比直接读代码要方便的多。前期能够写一写这个，既能够帮助大家掌握进度，还能够加深对项目的理解。

采访所得

经过采访大佬学长，咱们学习到了不少东西，对一个项目从开始到推动到最终的成果，整个流程也有了一个大概的概念，也学习到了一些提升效率的方式和须要注意的隐患。好比：

• 在项目开始前，全面的设计和详实的文档，可以有助于总体项目架构的肯定，也可以避免“走一步看一步”致使项目没法推动，甚至须要重构的问题。
• 以工做组的形式来完成项目，而不是成员各写各的，你们坐在一块儿写一方面对项目进度能够有一个更好的把控，另外一方面若是遇到困难，你们也能够一块儿克服，下降交流成本。

• 虽然说你们各司其职，但不一样组之间也应该相互沟通，密切配合。好比：PM虽然负责前期整体需求分析和产品的设计，但在开发组开发的过程当中，也应该跟随开发组一块儿，了解进度，并熟悉开发组的总体架构，提出合理的需求推动项目，而不是对项目彻底不熟悉，提出一些不太可能实现的需求致使开发组的进度陷入困境。

• 在阅读了其它同窗的博客后，咱们也认识到咱们要对可能出现的状况作出预期，好比说项目进度缓慢、或是团队出现矛盾等等。咱们做为一个团队，只有志同道合、一块儿努力，才能最后达到不错的结果。

实际花费时间

• 采访：50min
• 编写：90min