一、请回望暑假时的第一次作业，你对于软件工程课程的想象
-
对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
首先是达到期待的方面，
1.我坚持下来了（这个是重点，划起来要考），软工开始之前，就听人说过，2学分的课有10学分的实力，尤其是开篇博客自己居然提到了往届会有人承受不住压力退选，当时我……那时候最大的期盼就是自己能坚持下来，累的东西总会有收获的，最终坚持下来了。
2.学习了开发知识，完成了自己想掌握一项开发技能的目标。在这之前做过一块vs的软件，很基础的增删改查，调用是，什么的就是直接数据库sql语句，因此其实没有掌握到太多可能跟开发比较密切的知识。而这一次周期这么长的项目开发，从UI到前端到后端，终究是大概的了解了并且实践了。
3.从项目过程中适应团队合作和增强自己的抗压能力。
然后是不足的地方，
1.我在团队中的任务主要是前端，因此对于后端了解不多，其实我蛮希望能学会后端的，所以寒假我应该会自己一个人继续开发。
2.和一开始大家一起努力，然后相互学习的目标比起来中间出现过曲折。对任务复杂度的预判和大家长时间没有相互磨合导致β版本前的合作有点糟糕，身为其中一员，自然我那段时间的工作状态也就比较糟糕了。
-
总结这门课程的实践总结和给你带来的提升，包括以下内容：
-
统计一下，你在这门软件工程实践中，完成了多少行的代码；
代码大概在2350+，这写是完全自己打出来的，虽然过程中很多都没有保留，被最后有些开源代码然后自己修改给覆盖了，但是毕竟都是自己亲手打过的，如果真正算起来最后保留的并且加上我修改的开源代码可能会更多行。
-
软工实践的各次作业分别花了多少时间？（做一个列表）
其实平时博客表里写的时间都只算上了最精髓有起到效用的部分，但其实花费的时间，唉，算不过来了，我都起不起来自己熬过多少个页，做这个做了多少个整个周末了，感觉那段时间自己周末比平时上课累多了（平时上课好歹还能睡睡觉），周末真的一座就是一整天，眼睛看屏幕都看花了，然而有时候一天下去结果成果甚微。以下就贴上自己耗得时间吧（估计值），某些阶段会和原博客上会有些差异（由于很难精确统计，因此只能使用小时为单位进行估计）
作业 用时(h) 自我介绍 0.1 软工第一次作业 1 第一次个人作业 12 结队作业1 7 团队展示 0.5 结队作业2 10 团队第二次作业 5 UML设计（团队） 2 团队第三次作业 8 第七次作业（需求报告） 3 Alpha 冲刺(1/10) 8 Alpha 冲刺(2/10) 2 Alpha 冲刺(3/10) 6 Alpha 冲刺(4/10) 5 抽奖系统 8 Alpha 冲刺(5/10) 10 Alpha 冲刺(6/10) 2 Alpha 冲刺(7/10) 8 Alpha 冲刺(8/10) 6 Alpha 冲刺(9/10) 9 Alpha 冲刺(10/10) 7 Alpha 事后诸葛亮 2 BETA 版冲刺前准备 1 软件测试(团队) 3 Beta冲刺 (1/7) 3 Beta冲刺 (2/7) 3 Beta冲刺 (3/7) 5 Beta冲刺 (4/7) 5 Beta冲刺 (5/7) 6 Beta冲刺 (6/7) 10 Beta冲刺 (7/7) 7 Beta答辩总结 5 个人总结 6 总计 175.6 -
哪一次作业让你印象最深刻？为什么？
Bate版本吧，这个印象真的太深刻了，因为α版本的时候或团队合作或技术层面原因，团队一度面临奔溃状态，大家那段时间都想放弃不想做了，但最后咬一咬牙还是坚持下来了。几个会的大佬带带不会的，不会的自己又学一学，查一查之类的，然后各种加班加点，代码写了改、改了删、删了改。说实话那个阶段用时最久了，而且很累，但是那个阶段最不想放弃，因为每天是真的能看到新的进展，算是一种很大的动力吧。
-
累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答
博客里统计的时间我觉得有些时间写了却没有进展，就不好意思说自己用了那么多时间，实际上花费的时间恐怕有230h左右吧，如果算上学习啊、博客啊之类的，只有更多。平均每周15个小时左右（与软工相关任务，如学习新技术等均包含）吧。开篇博客里计划每周6~8小时，我只能说当时年轻、不懂事、可爱的自己真好，经历过这一波软工操作，三个特点我已经只剩下年轻、可爱了。
- 学习和使用的新软件；
- 微信小程序开发工具（官方指定的开发微信小程序软件）
- vs2017(结队作业时使用)
- Github(网页太难用了，组长切身推荐客户端软件)
- Hbuilder（抽奖系统那次做的html）
- 学习和使用的新工具；
- Leangoo(燃尽图)
- ps(毕竟前端必备)
- 学习和掌握的新语言、新平台；
- 新语言：wxml、wxss、js、html
- 新平台：微信开发者工具
-
学习和掌握的新方法；
- 类图、燃尽图之类
- 自动机（个人作业和结队作业时）等
-
其他方面的提升。
- 最首要的就是学习能力。抽奖系统那次现场学的html，毕竟做软工，要是学的不快，就难受了
- 耐心、团队协作能力等
- 语言表达能力和演讲水平（上去做项目介绍就很考验人）
-
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
主要的阶段变化是：无比期待、充满干劲→还是期待、憧憬项目→学习技术、努力提升→遇到瓶颈、努力尝试→终是挫折、变得颓废→顺其自然、不想抵抗→发现希望、重燃信心→发奋图强、团队协作→冲破桎梏、取得成果。
- 无比期待、充满干劲：
- 刚开始报选软工实践，怀抱突破自我的心态，即使大家说很难，但我就是义无反顾的期待和向往。
- 还是期待、憧憬项目：
- 真正开始软工后，首先是选题，这时候对于新队员还是即将开启的程序猿生活都还是憧憬的，就像是理工男始终觉得格子衬衫就是好看一样，对于写代码生活，我也还是觉得很憧憬。
- 学习技术、努力提升：
- 有多少憧憬就有多少的动力，因此一开始可谓是火力全开、刻苦努力。（只可惜完全不符合惯用开发模型，也不是专用模型还不算敏捷过程，就是撸起袖子蛮干，结结果在预料之外，又在意料之中）。
- 遇到瓶颈、努力尝试：
- 瓶颈大多数人都会遇到吧？我们也是。α版本的时候，我们发现离预期还差好多进度啊，如果拿SPI做指标，那只能说<0.2的完成度，我们遇到了好多好多问题啊，比如前后端交互，原先的UI设计不可用等等。
- 努力尝试→终是挫折：
- 我们努力尝试，但还是一筹莫展。
- 变得颓废→顺其自然：
- 在各种尝试无效的情况下，一段时间都不想再去尝试了。
- 发现希望、重燃信心：
- 但是在β版本即将开始前，我们发现了新的希望，最大的困难前后端交互被后端技术人员攻克，从而以点带面，前后端各开发人员开始顺利交互。
- 发奋图强、团队协作：
- 随后针对UI不适用，前端边开发边设计，后端配合前端的数据调用。同时后端对原有功能做出改造，前端配合后端对界面重构。这个过程最让我十分触动，深刻的感受到不要放弃，理性寻找问题失败关键的重要性。
- 团队重新分工，对功能模块进行划分，不再明确限制作用范围，这样就使得模糊的功能边界无人管理问题被解决，而且加强了团队间的交流合作，一个β版本阶段我们团队的开发模式有点类似于敏捷开发，而且我们是先做了核心功能，然后留下空白的界面供后续阶段使用，时间紧张，任务繁多，这个过程有点像是增量开发。
- 冲破桎梏、取得成果：
- 最后真的连我们自己都觉得是“神话”，有同学在提问中问我们是否是做的静态页面，不是实际功能部件，可见连有的同学都觉得不可思议，我们也是。一个β阶段不仅完成了核心功能，甚至在进度严重落后的情况下，做到了自己说的预期功能，真的让人惊讶，更觉得无比欣悦。
- 总结起来就是“绝对绝对绝对不要放弃！！！”软工真的是灰常考验耐心和毅力，坚持下去，无论还有多少时间和任务，总会有收获的，不一定能达到预期功能，但是至少会有收获1，更多的收获源于经历。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，对于同期的TA们，对于后来的学弟学妹：
-
你有什么想建议、告知和期许想要告诉他们呢？
这一段话很认真：
1.一定要认真看待软工实践，或许它以后还是两学分，但是就像它的工作量达到了10学分一样，他的收获也是按比例增长的。就像每学期上的理论课很多考完放个假我们或许就会忘了，甚至是某些实践课，但是软工实践很难忘掉吧，这段记忆。
2.软工实践或许是很多人开发的“启蒙老师”。我之前知道什么是Java、HTML等等，但我一般就把他们看成就是写普通程序的工具，换句话说就是我不知道如何应用他们写出真正具有应用功能的东西，更不要说知道什么是开发了，这个或许就是一次契机，你主动去了解开发，并因为有约束可以让你坚持下去。
3.这是一个绝对的可以让你体验团队协作的地方。或许也有很多课程会有团队，但在任务简单情况下的团队一般看不出问题。但在高压、高挑战下，这样的团队随时面临挫折、内部争端、甚至崩溃等等的时候才能真正体会到一个团队意味着什么。一个好的团队究竟有多么难以建设，团队间可能存在的问题可能会有多少。
4.还是有想建议之后学习软工的同学。一定要做好开发规划，不要向我们这样前期一团乱，后期来狂赶。我们是幸运的，赶上了，但是真的就算幸运也累死了。
5.最好抗压、熬夜、挣扎等等的充足准备，因为一般情况下你都会经历的，逃不掉的。、
我当时询问的学长、学姐非常一致地这么告诉我，我也想这么告诉即将开始软工之旅地同学：软工真的很累，但是熬过来的话收获真的很大。
-
特别地，特别地，下一届要不要中途换队员（强制的、彻底的从一队换到另一队）？假设依旧是一个90+人数的大班
谨个人觉得，最好不要。因为在初期的产品讨论阶段，大家都极力的去思考自己将为之奋斗的目标（即目标产品），最后得到一个共同认可的方案，因此这样大家充满动力，遇到挫折才愿意去克服。如果强制交换，由于非意愿，就算排除了被强制后的愤然心态，遇到问题可能也更容易崩溃或放弃，因为缺乏主观能动性。其次，当初的对于组成是大家自由组建，一个人的离去也有可能造成原团队的不适应和惋惜，如果再发生些调换过来的人员之间关系原来不恰当等，那可就糟糕了！！！
因此我觉得这学期这种偶尔一换体验一下的制度很好，以后可以从这方面考虑如何拓展，比如设置一个某队对某队进度的任务监察员之类的，而且这学期的跳槽制度就很现实很ok啊。
-
身在一个格外大的班级，竞争强劲，你认为一个组的人数应当在多少比较合适？
我认为7~10人吧。因为学生虽然想象无限，但大多能力受限，就算有很好的idea，如果功能过于复杂和困难，这不是增加人数就能解决的，一个团队人数过多可能引起浑水摸鱼的现象。如一些开发过程中某个或某些功能的开发、尤其是程序的编写很难多人合作，人数过多每个人有需要有任务，但真正有难多或是繁杂的任务也不可能正好每人一个，容易造成组织内不平衡。人数过少又开发困难，不容易开发比较大的项目。7~10人，项目数大概在10个左右，也好进行对比和评判。
-
个人/结对/团队作业应该控制在怎样的规模？
个人作业：进行一些创新思维或基础开发工具应用的任务比较合适，因为毕竟个人能力有限，因此可以倡导创新思维和熟练应用工具，为团队开发做准备，任务量建议控制在两个晚上这样；
结对作业：个人之上、团队未满的状态，但是为团队合作做预备。因此结对作业可以考虑进行一些与团队开发相关的任务，如设计UI模型，简单界面和功能实现等，建议控制在3~4天的工作难度这样；
团队作业：既然是团队作业，自然是interesting的好，正常任务何以考虑一些压缩版的开发项目，如这学期的抽奖系统这样，而创意性的可以进行一些社会调研任务等，这样对于团队开发也会更有市场数据基础，对成员间的交流协作也有帮助。建议控制在一整个周末可以完成这样。
-
这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？
好几个吧，按先后顺序来
1.柯奇豪（PM）：不知道其他队伍怎么样，我们的队长算是很好了。像GitHub之类的我一开始不会传，他都直接帮忙了。过程中有很多问题总结起来一句话就是“他能干的就直接干了”。
2.黄毓明：开发后期快崩掉那段时间，两个前端不够用的时候，他直接跨界帮忙，前后端技术一起学，真的是后面能做下来多亏他。而且也是默默做了好多。
3.黄志铭（舍友）：真的要是一个人做早崩了，有个舍友一起坚持熬夜起来有趣多了。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
- 萌芽：确定议题，发表想法，讨论决定。我们一开始天马行空的提了很多，最后决定了做WeEdit,但是我们有好的idea，却没有好的规划，因此后来开发过程不是一帆风顺。
- 磨合：一开始出于礼貌等等，团队成员间都还是十分温柔的，但是这种温柔并不是团队要的那种默契。随着开发的继续，我们过程中一直缺乏沟通，这也就导致了整个开发过程中最大的挫折出现，即alpha版本。其实大家的分工开起来都有事可做，但最后就像前后端交互那部分极其复杂，事先不了解，没有规划好，后来就变成各部分人员任务严重失衡，摩擦随之产生，整个alpha版本知道beta版本前夕都是一个相当长的磨合过程。
- 规范：整个规范过程都是开发过程中比较重要的阶段，从任务的调整，开发形式的确定以及开发过程中例如接口类型、接口普适命名规则等等的制定都是规范过程的内容。期间确定了很多规范要求，有不支持或是向左观点即使提出和讨论解决。因此起到了较好的可供查阅，可供阅读，具有引导的作用。
- 创造：虽然我们最后推出了可执行（可运营）版本，但是由于个体号限制，一些功能被迫屏蔽，所以这个过程内容不多。
五、怎样证明你学会了软件工程？
- 研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
证明：如下图可见用户数和人流量均满足条件
2. 通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
虽然前期经历过项目进展较缓慢的“瓶颈”期，但是随着后来团队间的磨合和技术跟进，在之后的开发过程中我们以核心功能为主，其他功能为辅，迭代开发，按照时间进度表执行，有严格的团队组成和定义。并定期对功能测试和维护，所以我们的开发过程也是有计划的开发过程。而之后也成功发布了运营版本，每个人在过程中都有工作，并非一个人包揽，每个人合理的按进度完成。
3. 并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
具体的数据表现最清楚的应该就是Github上的进程更新了吧！当然还有alpha和beta版本我们的博客更新也可见一斑。我们的博客和GitHub都是公开的，并且在博客连接里都有，都可以查询。还有我们代码是开源的，可以进行对比是否是可执行代码。而至于测试、文档等等在之前相应阶段的博客中均有附链接。
4. 对着这个检查表：http://xinz.cnblogs.com/p/3852177.html 检查一下，自己如果去企业面试，这些常见的问题是否都能回答，并在此总结。
| 类别 | 具体技能和面试问题 | 现在的回答 |
|---|---|---|
| 语言 | 最拿手的计算机语言之一,代码量多少?(偏web前端,PC/Mobile App) | html（wxml） 总共3000line左右 |
| 语言 | 最拿手的计算机语言之二,代码量多少?(偏后端,数据处理,网站后台,机器学习,等) | Java 2000左右 |
| 软件实现 | (阅读代码的能力,实现,单元测试)你有没有在别人代码的基础上改进，你是怎么读懂别人的代码的,你采取了什么办法来保证你的新功能不会影响原来的功能?你在开中碰到最复杂的bug是什么,你是如何解决的?这个bug出现的原因是什么,你在将来应该怎么去避免bug再出现? | 有过，主要是先知道代码的执行目标和观察运行成果，然后再从主函数看起，随之调用各子程序过程看懂代码，对于保持原功能上，首先编写过程中尽可能多的采用局部变量，注意使用全局变量。注意新功能的命名和调用问题等，保护原功能数据或相关数据被不利影响。碰到的最复杂的bug就是明知道bug出现的子程序，但该子程序的修改面临着全局变量等等的修改，势必引起整体变化，也需要其他子程序的修改，致使debug起来异常困难，将来的话会尽量注意变量的使用和子程序间的调用关系。 |
| 软件测试 | (测试方法、测试工具、测试实践、代码覆盖率)你如何测试你自己写的代码?你如何测试别人的代码?你掌握了多少种测试工具和方法?你写过测试工具?你如何对一个网站进行压力测试和效能测试?你如何测试一个软件的人机界面(UX/UI)? | 测试自己的代码的话要么是自己写测试用例，分析结果，更多的是去网上找测试用例或工具评测。测试比人的的代码的话更多的是去寻找问题的特殊角度，创造特殊测试用例。目前只会VS，没有写过测试工具。没有对网页进行过压力和效能测试。人机界面测试可以从一致性和信息反馈等角度出发。 |
| 效能分析 | 效能分析,效能改进，你写过的最复杂的代码是什么?你是如何测量和改进它的效能的,用了什么工具,如何分析的? | 感觉写过的最复杂代码（软工是最累哈哈哈）应该是编译原理实践上的语法制导。通过测试用例的复杂度和处理时间判断程序的效能。用了VS，通过处理时间判断性能。 |
| 需求分析 | (需求分析,典型用户,场景,创新)你做过多少个有实际用户的项目,用户最多有多少?你的项目有什么创新的地方? | 1个，就是这次软工的WeEdit，一共120个用户，项目创新的地方在于1.微信办公2.办公一体化3.有安全保障和反馈的共享编辑 |
| 行业洞察力 | 你最感兴趣的领域是什么?这个领域过去10年经历了哪些创新?你分析过这个领域前10名产品?请分析一下他们的优劣,你要进入这个领域,应该如何创新? | 最感兴趣的领域是web前端吧。这十年来web应用就发生了很大变化，还有web的响应设计等，编程语言也在变化，起初就是简单的html和css后来js类库逐渐完善，html5开始成熟到现在还有gulp等等。有js，html5等。js库比较完整，但是不利于基础设计，他适用于加强设计。创新的话可能主要是从数据方面吧，大数据时代，数据存储、转化和选择很重要。 |
| 项目管理 | 你参与过项目管理么?请描述一下两个当下流行的开发方法在你的项目中的具体应用情况;请问你如何决定项目中各种任务的优先次序,有什么理论来支持你的做法如果你突然发现项目不能按时完成,你作为项目领导,有什么办法? | 没有参与过，所以不知道具体应用情况。如果我是管理者，我会依据创新程度和市场大小决定优先次序吧。理论的话就是软工原理中的软件过程理论吧。如果突然发现不能完成，我作为领导，1是可能着重于开发核心产品，然后增量开发；2的话很有可能外包给其他公司。 |
| 软件设计 | 你做过架构设计,模块化设计,接口设计么?请说明一下你为何是这样设计,你比较过什么不同的设计方式,你的设计取得了什么结果? | 勉强算接触过的是接口设计吧，统一的接口规则是交互更简洁。 |
| 质量意识 | (代码复审/代码规范/代码质量)你是怎么做代码复审的,你加入我们团队后,能帮我们提高代码质量么,请具体说怎么提高? | 代码复审主要就是寻找不要角度和难度的测试用例，或从不同角度分析功能点和实现效果。可以吧，至少可以多一个人从不同的角度看待代码的质量，提高上就是帮助简洁程序和降低程序执行响应时间吧。 |
| 工具/社区 | Software Tools (performance tool, version control, work item, TFS)你在各种开发平台(web,linux,PC,mobile,machine learning)都使用过什么样的工具,自己写过什么工具来改进工作效率?给社区贡过什么工具和代码?Github有分享代码么?你写的技术博客坚持了多久,读者最多的是哪一篇? | 常用是vs，没有写过工具来改进效率，没有贡献过工具，代码贡献过前端的，本次软工开始使用的GitHub有放过开源代码。没有很技术吧，最多浏览量的是写过一篇解释匈牙利算法的博客，浏览人次是58. |
| 团队协作 | work with others(协同工作,提供反馈,说服别人)请描述你在项目中何说服同伴采用你提出的更好的解决方案,或者你如何听取了别人的意见,改进了自己的方案?你如何说服懒情的同伴加紧工作,实现团队的目标? | 要么用已有数据或结果说问题，说的可靠性高听谁的，或者是评价二者的方案，选择优的。告以利弊吧，主要是以利诱之，以弊吓之。 |
| 理论素养 | 你上过什么数学,计算机或其他理论课,请举出具体的例子,说明你学到的理论知识如何帮助你解决实际问题。 | 数学分析、解析几何、高等代数、概率论、离散数学、算法与结构、面向对象与程序设计等等，比如高等代数中的迪克特斯拉理论或是数学分析中的欧式定理都帮助过我寻找最优路径等。 |
| 自我管理 | 全年级你专业排名多少?你从刚入学(大学一年级) | 33/110.成绩好像略有下滑，中间有较大起伏，主要是刚转专业过来那时候不熟悉，现在在缓步提升。 |
请在随笔中用数据证明上述内容或侧重选择之一。
对自我管理模块的话就以刚转专业第一学期绩点和第二学期的图示证明如下：
六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：
参考论文文献：
[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.
这篇论文主要介绍的是关于开源软件开发。开源项目的代码需要是“严格模块化，自包含，自我解释”，由于其他程序员可以自由读取、修改，加快了系统的演化速度。而审核代码质量的关键在于代码是否有注释，编码是否规范以及代码的可扩展性和移植性。
按照这篇论文说的我的代码确实有点像滚泥球，没有建立合适的调用机制和变量机制，需要就临时新增，造成代码冗余。没有较好的模块化，“一锅煮”，解释等比较乱，代码见分块不清晰，也没有做到某程序对于不需要他的程序做到隐蔽，甚至有比较多的数据相关，类似于牵一发而动全身，出现错误，修改难度较大。
七、个性发挥，包括图文、照片和创意等
做软工的这个过程当真是各种情况各种现象
这是我们看起来的样子
但实际上我在写代码的时候是这样的
整个桌面我也就能知道键盘在哪了！！！
但是，收获很大！
在最后产品做出来的阶段无比的欢欣和喜悦，慢慢的欣慰和成就感。
再来一次我还会选择软工吧，虽然真的好累。也喜欢从软工开始开发之旅，从寒假就开始我会继续学习和开发下去。这或许就是软工的意义吧——引路人。最后写这段话就当以此为记，既是对软工的一个总结，亦是新的开始和给自己的纪念吧！（所以才会打字打到食指疼，感触的东西太多了）。