目录
- 一、请回望暑假时的第一次作业,你对于软件工程课程的想象
- 二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
- 三、对下一届实践的建议,或者对于开学初的你,对于大一的你,对于开学初的我,对于同期的TA们,对于后来的学弟学妹:
- 四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段,你的团队都经历过么,最后到达了“创造”阶段了么?(参考《构建执法》第17章 人、绩效和职业道德)
- 五、怎样证明你学会了软件工程?
- 七、个性发挥,包括图文、照片和创意等
一、请回望暑假时的第一次作业,你对于软件工程课程的想象
1)对比开篇博客你对课程目标和期待,“希望通过实践锻炼,增强计算机专业的能力和就业竞争力”,对比目前的所学所练所得,在哪些方面达到了你的期待和目标,哪些方面还存在哪些不足,为什么?
期待在这门课的学习中能够对软件的开发流程有一个深入的了解,也希望在课程中能够学习到更多的开发项目的经验。
对比当时的期待,在这次的软工实践中,确实对开发项目的开发流程、合作方式也有更多的了解,结合其他实践课中管理团队的经验,更加明白了作为一个项目的参与者需要考虑的内容。
2)总结这门课程的实践总结和给你带来的提升,包括以下内容:
1、统计一下,你在这门软件工程实践中,完成了多少行的代码;
2000左右
2、软工实践的各次作业分别花了多少时间?(做一个列表)
作业 | 时间 / min |
---|---|
福大软工1816 | 第一次作业 | 30 |
福大软工1816 · 第二次作业 | 600 |
第三次作业 - 结对项目1 | 150 |
第四次作业 - 团队展示 | 20 |
第五次作业 - 结对作业2 | 600 |
第六次作业 - 团队选题报告 | 50 |
福大软工 · 第七次作业 - 需求分析报告 | 275 |
软工1816 · 作业(八)项目UML设计 | 280 |
Alpha冲刺(1/10) | 170 |
Alpha冲刺(2/10) | 205 |
Alpha冲刺(3/10) | 630 |
Alpha冲刺(4/10) | 740 |
GIT团队实战博客 | 770 |
Alpha冲刺(5/10) | 740 |
Alpha 冲刺 (6/10) | 640 |
Alpha冲刺(7/10) | 640 |
Alpha冲刺(8/10) | 155 |
Alpha冲刺(9/10) | 205 |
Alpha冲刺(10/10) | 70 |
Alpha冲刺之事后诸葛亮 | 50 |
Beta冲刺前准备 | 30 |
beta冲刺(1/7) | 70 |
团队项目测评博客 | 70 |
beta冲刺(2/7) | 10 |
beta冲刺(3/7) | 70 |
beta冲刺(4/7) | 40 |
beta冲刺(5/7) | 380 |
beta冲刺(6/7) | 140 |
beta冲刺(7/7) | 180 |
beta答辩总结 | 20 |
3、哪一次作业让你印象最深刻?为什么?
GIT团队实战博客
到深夜还在和队友们编写测试和部署
4、累计花了多少个小时在软工实践上?平均每周花多少个小时?同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答
打算每周拿出15个小时
总数约159个小时,以13周计算每周12.23小时,基本符合预期
5、学习和使用的新软件;
Postman Axure
6、学习和使用的新工具;
石墨文档
7、学习和掌握的新语言、新平台;
基于laravel的web后端框架
8、学习和掌握的新方法;
学习撰写文档来对代码进行解释
学习如何进行单元测试
9、其他方面的提升。
对项目团队的组织,身为其中一员有了一些体会
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
经验是为后续的扩展设计留下余地。举例说明,在个人作业时,设计程序结构的时候考虑到了可能的扩展需要,采用了一次从python中学到的类组织模式。在结对作业中这个预留下的设计起到了一部分作用,节约了我大量的时间。回想上一门课程的作业中,需求第二次更改时被程序整体结构束缚,无从下手。
上面的这个例子可能不太有代表性,但注释、文档、git版本控制、框架的使用、设计模式的使用,我想都是为了进一步的重构代码,为了应对需求的更改而做的准备,值得花上时间去完成。
三、对下一届实践的建议,或者对于开学初的你,对于大一的你,对于开学初的我,对于同期的TA们,对于后来的学弟学妹:
1)你有什么想建议、告知和期许想要告诉他们呢?
用这是真正的项目的心态去看待将要做的软件,努力去留下扩展设计的余地(比如结构、文档等等)
2)特别地,特别地,下一届要不要中途换队员(强制的、彻底的从一队换到另一队)?
不要。这可能需要完善的文档体系、交接体系作为支撑,而在这次的课程时间中难以做到。
3)身在一个格外大的班级,竞争强劲,你认为一个组的人数应当在多少比较合适?
6-7人。
4)个人/结对/团队作业应该控制在怎样的规模?
个人作业和结对作业规模可以稍微减少,留下更多的时间给团队作业。
5)这学期下来,你最感谢的人是谁?有什么话想要对TA说呢?
我想感谢赵畅,从代码编写本身到其引入的团队管理机制再到团队的协作过程,在这次实践中帮助了我和我们团队很多。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段,你的团队都经历过么,最后到达了“创造”阶段了么?(参考《构建执法》第17章 人、绩效和职业道德)
萌芽阶段:项目进程早期都可以算作学习相关的技术的阶段,我们对项目所需的技术进行学习
磨合阶段:开始进行编写后,确实暴露出了一些配合上的问题,在沟通中得到了进一步的磨合
规范阶段:我认为我们的团队在一定程度上达到了规范阶段,项目的文档撰写已经具有较高的完成度,但还存在一些没有明确的规范,比如更加详细的代码风格、其他类型的说明文档。
创造阶段:我认为我们的团队一定程度上触及了创造阶段,成功提出了一些在原来的设想中未涉及到的功能点,并付诸实现。
五、怎样证明你学会了软件工程?
1)研发出符合用户需求的软件
必须公开发布,有实际的用户,一定的用户量和持续使用量 (3 天后能保持10 - 100个用户);而不是: 做没有用户使用的软件
2)通过一系列工具,流程,团队合作,能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护,有定时的进度发布 ; 而不是: 通过临时熬夜,胡乱拼凑,大牛一人代劳,延迟交付等方式糊弄
3)并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码,代码无文档,代码不能编译,没有task/bug 等项目的发展资料
4)对着这个检查表:http://xinz.cnblogs.com/p/3852177.html 检查一下,自己如果去企业面试,这些常见的问题是否都能回答,并在此总结。
请在随笔中用数据证明上述内容或侧重选择之一。
一方面,我们使用git进行代码/文档的版本控制管理
一方面,我们使用石墨文档进行公共文档的书写
从而使得开发过程能够更加有序的进行
(下图来自PM的博客)