个人作业收官——软件工程实践总结
1、总结
初始---终焉
学习到的能力的预期&&总结
- 加深下对c#服务器编码的理解。 --- 虽然只是加深了对移动端小规模的服务器的理解，但个人还是挺满意的。
- 争取能从头好好学习一下c#语言。 --- 期中的时候买了一本一千多页的c#高级编程，只看了一百多页，不过有跟着进行代码练习。。。任重道远。
- 若团队打算采用Java编写服务器，希望也能学好java吧。 --- 在我的强烈要求下我们还是采用了asp.net web api 啊哈哈哈。
- 希望自己成为一个合格的程序猿。 --- 渐渐地发现码农和程序猿的区别。码农是只要实现功能再苦再累也会机械化地敲完。而程序猿是考虑如何让自己的代码更有层次，如何让自己写起代码更轻松。同样任重道远。
对项目课程的期望&&总结
- 虽然不是PM，但也希望能更好地整体把握整个项目，不过可能精力不足，说到底还是希望PM能够梳理好整个团队。 --- 我们组的PM虽然有时候会犯糊涂，但还是很靠谱的，不过希望他能够自信些，强硬些，这样对整个团队的发展都是利大于弊的。
- 希望能学到更为规范的项目搭建过程。 --- 从之前的需求分析、原型设计到之后的编码规范、环境选择以及最后的两次冲刺中，我深深地感受到了很多东西是代码之外的，同时也是同样甚至更重要的。
- 希望能写好文档。 --- 额，除了一开始有写接口文档和最后的测试文档之外，我就没写过多少文档，也没有进行深度的学习也没感觉有什么锻炼。不过，文档很重要！只是我不喜欢写QAQ
- 希望能学好怎么使用Github。 --- 项目一开始因为我们服务器是我一个人包办的，所以并没有用github。不过后来因为老师要求，整蛊了两三个小时把vs连接github弄懂了。然后现在看着上面的github记录，感到深深的满足感，我也算能基本使用github了，哈哈哈。
对项目的愿景规划&&总结
- 先定好题目，一个好题目是一切的起点。 --- 我最近一直在思考一个问题，是选择重要还是努力重要，我现在更倾向于前者。（当然不能因为这个理由而轻视努力，只有选对了，努力了，才能有所成就）选题目就是选择，只有选好了，之后的努力才有价值。我觉得我们的题目选得不错，只不过努力差了点，有些点没做出来。
- 规范好团队的编码规范，使得代码易读。 --- 这一点我们团队做的还是挺好的！
- 做好产品原型。 --- 产品原型很重要！我们产品原型中有一个跳转逻辑有点问题，导致后来android开发的童鞋都不明白之间的参数传递以及跳转逻辑，耗费了一些时间。
- 希望大家编码时能够多交流。 --- 这点，我因为是一个人开发服务器，而且其他组员用java，我用c#。并没有多做交流
- 希望能克服一个又一个的八阿哥。 --- 克服不了也要克服，实在过不去，就用绕的！
- 希望能做出自己真正想做的东西。 --- 立项还不错，技术差了些。
假如你所知道的是一个圆，那么你以为你不知道的是圆的边线，你真正不知道的是圆外的所有！
提升这种东西，提升之前我的直径为1，以为自己所不知道的也就一个派，现在我的直径为2，才知道我不知道的是两个派，以及两个派外的无垠。
- 学习了 Asp.Net Web Api框架以及其所蕴含的MVC思想。
- 学习了 WPF 框架以及其所蕴含的MVVM思想。
- 学习了 在Android以及Web Api 中实现 Http 通信，传输文字，图片和文件。
- 学习了 云服务器的部署，VS的Web Deploy发布，VS的Github的使用。
- 学习了 Postman的使用。
- 深入学习了 C#。
- 浅浅地学习了 Android开发。
- 学习并经历了 一个产品从一个idea到成型的大致过程。
- 代码量大概 C# 3500行 XMAL 200行 js 200行 java 500行（xjb估的）。
2、人月神话
经验总结
- 敲代码之前得先多想想，不然到后面你会发现自己xjb写了一堆没什么用的代码。
- 一知半解的时候直接上手感觉会学得更快。当然要做东西的话，不能在试验的代码上直接扩展，要参照上一条。
- 沟通很重要。以没时间为由对沟通不上心，到最后时间将会惩罚你们。
- 冲刺的时候，锻炼很重要，每次敲到烦的时候我就去踢球，踢完球一身轻松，效率蹭蹭上。
- 当遇到技术难点的时候，不要一味地上网去找解决方法，然后copy代码来尝试，而应试着更了解技术难题的细节，并针对这些细节一一进行学习与思考。
实例分析
- 在实现Android端与Web Api的图片传输的时候我尝试了很多种方法，但是由于没有系统学习过Http通信，当时一下子要处理双端的通信，一下子就蒙蔽了。然后开始百度，开始谷歌。一开始是直接找代码，然后疯狂贴代码改代码进行测试。。。后来花了两天没什么进度，反倒是让我对整个通信过程有了更深的理解。然后我花了半天，把Http通信的基础以及双端的主要函数学习了解了一下。花了半个下午去踢球，洗完澡坐在电脑前一会忽然发现Android可以模拟Http报文并以Multipart/Form-data方法进行传输，可以同时传输文件和文字，然后Web Api用MultipartFileData 类进行接收。于是就过辣。
3、告诸往而知来者
以告来者
- 就像老师所希望的那样，下一次希望学弟学妹们在开发过程中能得到更多潜在客户的意见，从而做出真正让客户满意的作品。
- 团队的pm在协调好团队的同时，也应该强硬点积极点，这影响到团队中的氛围。
- Github在团队协作方面确实好用，建议在开始项目之前抽时间学习Github。
- 然后其实代码量没有那么多，做好规划，不会是多大的负担，最怕就是拖延症。比如我，什么熬夜通宵都是为之前还债罢了。为什么会觉得熬夜比较有效率，因为你内心有对白天荒废的愧疚感！
- 开始代码前，每个组员都应该完全熟悉掌握产品原型。
诫己
- 效率！效率！熬夜对身体不好！PS.嘴上这么说，你还不是熬夜在写这篇文章？
- 做好时间规划，不管是敲代码还是学习，比如你现在要挂了你知道吗？再不读书，再逛Steam，再喜加一，你药丸！
- 不要轻易放弃，放弃等于药丸，内心低落也要逼一逼自己还债。还有一个礼拜就到连环七门考了，开心吗？
4、606
关于606NotConnected这个名字
- 团队名很明确，是关于6班的6位小伙伴之间的故事
- Http 的606状态码对应的是 Not Acceptable 不能被接受的。。。额这个名字貌似不好。而Not Connected确实也可以表达出606状态码的一些特性，同时也希望小伙伴们在编码时能沉下心做到与外界Not Connected（额，好吧这是我掰的）
关于团队
- 萌芽阶段：大家都是老熟人也没什么拘谨的，只是确实有些没经验的小伙伴会不敢于表达自己的意见。还记得开学初的几次开会，看上去有模有样的，但其实还是在轻松愉快的“展望”中过去了，恕我直言，效率有点底下。不过现在想想也是萌萌的。
- 磨合阶段：整个项目下来，编码压力最大的是我们的Android客户端的“主程”(以下简称为我舍友)，不仅要大量编码，同时还要带动一些没有基础的同学一起编码，然后经常帮他们擦屁股。什么？你问我？我一个人负责服务器端，再写点Android的通信文件轻松自在，小规模编码人多真不一定是好事。然后，在Alpha阶段的最后一天晚上，还有很多问题(Alpha版本演示的时候我们貌似闪退了三次？)，我舍友都要抓狂了，整个心态爆炸的感觉，边敲代码还边抱怨其他人拿过来的东西不满足要求，还要改。然后，我就安慰他别着急，并坐在他旁边看他编码，心平气和地，时间就到了四点半，然后睡三个小时上战场！磨合阶段，大冲突没有，小摩擦也很少，大概我们组的童鞋都比较内向吧。老实说我们团队在磨合期的处理并不妥当，牺牲了部分人，比如我舍友，他虽然没和其他人起冲突，但是他确实因这磨合期而感觉到痛苦与疲惫。
- 规范阶段: 开始Beta阶段后，大家貌似找到了一种节奏，原本随和的PM也开始有了自信也更有力地监督着团队的项目进度。所以我们Beta阶段貌似没有熬过夜。因为有了Alpha版本的雏形，大家也有了明确的目标。什么第一版界面太丑？改！UI设计不好？换！大概是这种节奏，这种行动力挺高的节奏。
- 创造阶段：不是很理解将注意力集中到如何创造是什么样的感觉。不过，高度自治貌似没有做到，有时候还学要PM在尾巴后催促，大概是没有到达这个阶段吧。
5、EXM? English Disquisition？
PS.Sorry,My English is not better,so I maybe can't complete it great.
PS.考试将近我个人真的没太多精力去通读这么长篇的英文论文，所以我选择机翻。。。
Code quality analysis in open source software development
- 粗略地看完整篇的机翻，我忽然发现貌似只有最后两段与衡量自己的代码质量有关？
- 本篇论文前半段都是对开源代码以及开源组件进行的抽样质量调查，而后公开结果，说所抽样的开源结构化代码质量高于反对开源的人的预期，但也低于普遍的工业化代码的质量。然后就在讨论如何提高开源代码质量？
- 怎么说呢，开源已经是大趋势，连固执如微软，近年不嘛也把.Net开源了嘛。什么Windows开源？梦里想想就好。前两年我第一次接触Unity的时候，很多人拿它和Cocos2d相比，直言它不开源是最大的劣势，然后最近我忽然发现Unity Pro版貌似开放源代码了（只不过要收费就是了）。而且我们在开发的时候也从开源社区中找到了Picasso这个开源组件，大大地帮助了我们开发，我不能不说开源真的很重要。只是若商用项目大量使用开源组件，也是一个很大的隐患，所以这篇论文才一直在探索如何提高开源代码的质量。
- 个人认为，以做项目为生的程序猿应该懂得站在巨人的肩膀上，做到干净利落地实现功能。所以对于项目的开发，开源项目真的是必须的。
- 个人感觉自己的代码还是挺规范的，除了几个地方备注少了点。然后代码结构这个问题，因为我是根据框架来做的，并没有太多自己的设计，要说有就是写了几个方法类，所以感觉还是差了些火候，特别是前些天复习了设计模式之后，才发现其中一些想法之巧妙。
6、进行时而非完成时
- 第一点。老实说，临近期末真的没办法进行推广，而且之前被试用用户吐槽这并不是用户级别的App，我们也意识到我们这款App的不足，短期也不会进行发布到商店的尝试。
- 第二点。第二点的证明我觉得我们在两次冲刺阶段的十七篇博客就可作为数据证明。http://www.cnblogs.com/606notconnected/p/6044648.html
- 第三点。个人觉得自己写的服务器端因为是一个接口一个接口写的，拓展维护什么都很方便。这是github的地址: https://github.com/606notconnected
7、公主沉睡了，屠龙的勇士还在燃烧
我们的公主已然沉睡，屠龙的勇士到最后救出了公主，却没能让她睁开眼。
开学初的博客里的自我介绍我就说了，我是一个玩心很重的人，什么都想去尝试。
但是，很多时候一颗安定的心比一颗躁动的心来得更为重要，所以我没能做出一款真正用户级的app，所以公主依然沉睡。
我之所以选择就读计算机系，是因为我有一颗想做游戏的心。
当初年轻，不懂得路途的艰苦，只有一腔热血。现在了解得越来越多，但也改变不了我的信念。
我不是一个严格意义上的程序猿，因为我对数字不敏感，我更想做一个艺术型的程序猿。拿着数位板画着图，打着打击垫谱着曲，敲着键盘码着代码、写着剧情，闲时看着动漫，听着小曲，踢踢球，玩玩游戏，和基友吹吹逼，这是我的理想生活。（什么女朋友？心疼自己1s） 当然，毕竟是理想呀。
我希望我不是为了工作而生活，我是为了生活而工作。我希望我未来的工作是我真正感兴趣的。足球？已经没有多少可能性了。动漫？并不是艺术生。游戏？不是当主播的料，嗯，我要成为游戏开发者。
游戏是门艺术。
只是国内的游戏公司有几家是静下心做游戏的呢？感觉以后有经验了，也要混迹于小作坊了，哈哈，生而自由。希望以后大家能看到一款游戏的开发成员名单时，惊奇地说道：雾草？这是我软工课上的同学？
哈哈，屠龙的勇士还在燃烧！至于龙屠了吗？谁管呀。
