一、回忆杀
- 了解或者掌握以前从未接触甚至是听闻的结对编程，git, as,markdown……
- 提升自己的文档书写能力，那么多篇博客以及文档不是白写的
- 提升编码能力，说起来都是泪~~~
- app的衍生到诞生
- 找到了一群逗比的队友
点我，看回忆杀
自身的提升
新的软件
- android studio
- Axure RP(但是后来感觉墨刀比较好用)
- processOn思维导图、类图甚至原型设计，在线网站！
- gitub /gitub for windowns
新的工具
- git! git! git! 那个黑框框让我又爱又恨，爱的是gitub真的很好用，恨的是丫的都是什么鬼，为什么仓库创建不了，为什么连接不上，为什么push不了，为什么别人电脑上可以我的电脑上不行，好像软工上“为什么”的60%都给了git~
- markdown编译器，get到了排版的重要性，推荐简书，都是用 markdown来写的，啧啧啧，美观
新语言、新平台
- java
- xml
- 博客园里真的有好多好东西，一些大牛总结出来的干货
- gitub上面许多开源项目供人下载参考学习
新方法
- 结对编程 大大提高了效率
其他提升
- 团队合作以及交流意识更强，如果说一开始就沟通好，就不会有那么多次的返工，导致做了很多的无用功
- 代码的命名规范，很重要！= =想到了队友相互之间吐槽命名
“你这个admin1，admin11，admin111，admin2，admin22都是什么鬼啊啊”
“咦~这是谁的命名啊，还用中文来命名，好low啊”
“啊啊啊啊啊，怎么会有那么多报错啊，命名好多不一样啊~~~~~”- 经过这次的软工后，个人的最大提升就是：多年来的暴躁症治好了！！！！---->各种软件的安装，卸载，在安装；系统的更新，重装
二、属于自己的人月神话
项目实践中的经验总结
- 文档的重要性
如果说文档完成了，那么该项目就完成了40%
需求分析文档
原型设计文档
测试文档
数据库设计文档……
- 每日记录
- 知识总结
将在项目开发过程中遇到的问题都记录下来，同时将相应的解决方法对应上去，总结起来，将来可是一笔很大的财富。
实例/例证结合的分析
- 如果说一开始，通过队友们各种“撕”，就把各个文档以及原型确定了，就不会有之后的界面多次返工！！！是多次返工！！！
- 在冲刺时期的每日记录，督促着我们每天都要做点事（撒点小谎），不然对于记忆力差的人，完全可以忘记昨天完成了什么，今天要从哪里开始，而且每天的明天预期，相当于明天的目标吧，可以提升明天的编码效率
三、对于后来人的期许
To 下一届实践的筒子们
- 偷偷告诉你们，栋哥的软工课并不像外界流传的那么"残暴"，看我们这些经历过的人不都好好活着呢么，而且还是意气风发地活着。其实栋哥的软工并不会比其他老师的实践课多多少任务，只是栋哥要求每一次的作业都以博客的形式来做，有种把作业给量化了的感觉，所以在外界看起来比较多而已。这种以博客做作业的形式其实还蛮不错的，现在看来，该博客已经注册三个月了，从当时的一天到三个月，hhh莫名有种养孩子的感觉，从最初的期许，到现在的总结，每一个阶段都有一篇博客作为记录，也会给自己满满的成就感，这是别的老师实践课上不能给予的
To 大一新生们
- 无论这个专业是不是你心中所属，如果说决定就在这个专业“混”下去了，那么请认真地对待你的专业课吧，尤其是C,C++，算法与数据结构，软工……！！！（学姐要敲黑板了）可能你对那些所谓的计算机语言无感，但是请尝试一下，试着去接触，试着去认真地打老师布置的每一次作业吧，或许某一天发现其实这些鬼语言并不是那么磨人，甚至是有些可爱(●'◡'●)，有些事，你不去尝试你又怎么会知道它是怎样的呢~！
四、实践阶段
萌芽阶段
在选课时，我毅然决然地选择了栋哥，到了需要组队的时候= =发现实践课上我们班就我一个，那就很尴尬了，就去找林姐姐（林锦）求组队！结果还没发出请求，牛姐就向我抛出了橄榄枝，问我要不要加入他们的队伍，他们队伍正好查一个人，于是就鬼使神差的加入了Transcend这个队伍
磨合阶段
商讨-确定-冲突-商讨-再次确定-再次冲突-再次商讨……鬼知道我们开了多少次会来商讨要做的产品类型和原型
从移动web到app，再从app到移动web，几个人不知道“撕”了几次，才最终确定下来
Ok，好不容易确定了要做app，那么项目主题呢，大家倒是挺统一的，做服务类的活动助手
关于原型，要走商务风，还是扁平化，亦或者是卡通风格，蓝白色，还是黑白灰色……
规范阶段
好不容易确定了我们的产品，也经过了前期的语言学习，大家就开始有条不紊的开展自己的进度，每天汇报自己完成的任务，好像那段时间，热度最高的就是我们小组的群吧
创造阶段
创造阶段 ->Alapha版本的后期
连着2-3天从下午到晚上，外加汇报前一个夜晚，完成了大部分的编码，以及项目对接和bug修复
其实一群人在一起编码的效率会更高
总结
对于一群几乎没有接触过项目的人来说，从三个月前的小白，到现在能够完成一个雏形的APP，真的是很大的一个提升，虽然说该app还会报各种莫名其妙的错，在外人看来就是所谓的“辣鸡软件”，但在我们看来就像宝贝，经过这次实践，以后的我应该不会再随意地去吐槽某款软件怎么那么难用，这种到处都是bug的app竟然还能上线……
另外，我要在这里谢谢我的组长，对于拖延症的我，竟然没有暴走，hh好脾气，给个赞。在我们懈怠编码时，在旁边给我们打气，并且督促着我们.
五、阅读笔记/代码质量
阅读笔记
Code quality analysis in open source software development
- 代码开源
我觉得代码的开源是帮助程序员进步的一大里程碑，接触了github后，发现了新大陆，里面有很多好多开源项目，可以clone下来在自己的pc上跑跑。不过有些项目会出现莫名其妙的错误导致不能用，如果要解决这些问题还有可能要花费更多的时间。- 代码规范性
规范的代码会提高编码效率，从结对编程到团队项目，由于编码的不规范，产生了很多bug，以至于不能够对接，代码命名不是自己想怎样就怎么，只有通过规范性才能够使得项目走的更远。
- 要不断提高重构技巧
节省时间，提高效率- 代码审查
gitub提交代码之前，一定要在自己的电脑上跑一下，确定无误后再push，否则队友拉下来各种报错= =这样的事我干了好多次，都是没有审查
代码质量
这个说起来就有点小尴尬了，如图所示
六、怎样证明你学会了软件工程？
研发出符合用户需求的软件
这个选题好像是我提出来的吧？= =给忘了，主要是之前在社团办活动时，签到统计人太过麻烦，需要花费很多时间在制作签到表上，为何要花费我们宝贵的时间在这些无聊的事情上呢，倒不如做一个软件来方便那些活动的举办方，尤其是负责签到方面的孩纸，这样活动完就不用为了签到表为暴走，可以愉快的开心去浪了
通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
"足够好"，这是在我们看来的。在这个过程中我们学会了很多工具，团队合作也在博客中有过记录，总的来说还是整合的问题。
通过数据展现软件是可以维护和继续发展的。
软件的开发只占过程中的30%，70%是维护。
项目链接
七、个人介绍
ly-李严
从懂事来就不断给自己挖坑，又不断填坑的少女 ：）
抱歉，这是一篇迟到的总结，又给自己挖了一个坑~~~