| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 软件工程 罗杰 |
| 这个作业的要求在哪里 | 第一次团队作业 |
| 我们在这个课程的目标是 | 熟悉软件开发整体流程，提升自身能力 |
| 这个作业在哪个具体方面帮助我们实现目标 | 第一次体验一个完整的工程 |
团队成员介绍
对没错！我们就是葫芦娃！！
我们的团队由七位男生组成，他们分别是：
-
大娃
“热爱生活、热爱挑战、热爱编程的大三“准程序猿”一枚”
-
二娃
“男，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
posted on
