软工实践课程总结
尽量让这篇总结照顾大局，但废话太多也写了八千多字。不像是总结啊喂！ _(:з」∠)_ 。
基本上按照老师给的结构来：【软件工程实践总结作业——个人作业】。
目录：
一、回望开学初对于软件工程课程的想象，回望博客开篇时对于这门课和这学期的期望
-
对比现在的我和开学初博客开篇的课程目标和期待。
看了看我的第一篇博客 《软件工程的实践项目的自我目标》 ，拿几条出来说：
第一条：能够较快地做出提升自己生活质量的APP。这一点不太好说，但是肯定比以前快了。这一学期做项目学到了不少面向对象的知识。
第二条：写的代码有良好的扩展性和健壮性。良好算不上，但有一定的扩展性。自从了解了反射和泛型，感觉能在减少代码量的同时增加适用的广度。我不会告诉你，其实我是因为懒得写重复的代码才去学的这些知识 _(:з」∠)_
第三条：熟悉与多人合作的流程，任务的分配和代码的规范化。看到这点，不得不提GitHub的团队合作使用，使我收益颇丰。除此之外，从原来的不知道如何细分任务，提升到把一项任务分割到较小的粒度（当然，有时候还会有意识地防止粒度过小）。作为团队PM，这方面肯定要训练得比较多。此外，我去了解了Google的JAVA编码规范以及Android特有的编码规范，在此基础上做出一份我们团队编码规范，为代码的规范化迈出第一步。
不过对于项目的愿景规划，没做好。其实我一开始只想默默当个程序员的角色，开开心心地敲代码和钻研技术。然而当了PM，愿景规划就没执行了。不过想想，做PM的好处就是，技术的成长对整体的提升不是线性的。在这种时候去提升其他方面对自身的成长更有帮助，这次担任PM一职就为将来的提升打下了一定的基础。
-
-
学习和使用的新工具
Git工具和GitHub！！以前就了解到GitHub是个很好的平台，现在终于用上了！而且我感觉我已经离不开它了。
关于git工具，我一开始使用GitHub for Windows，想着 “这个是GitHub自己做的工具，使用起来应该很方便” 。后来发现其实也没什么，我本来就不太喜欢用这样的图形化工具。这个版本的图形化用起来实在难受。不过它的命令行有一点不错：可以切换命令行的工具。它默认使用PowerShell，但是我觉得不太好。后来觉得既然不使用它的GUI，还不如换成msysgit（也就是 git for windows ）。
其实还有个原因，就是GitHub for Windows依赖于.net framework，导致老师让我在上机课上跟同学们分享Git和GitHub使用方式的时候，出现了尴尬的一幕：无法直接使用，要安装.net framework，可是装完电脑要重启，重启就被还原掉了。我在PPT里没有准备生成SSH的内容，又忘了这些步骤，不好意思现场查教程。其实这样做是对同学们不负责，没必要为了面子不去查。博客和Markdown。其实一开始让我用博客园，我是拒绝的，因为感觉CSDN更高大上。但不得不说，博客园真的不错，于是就决定以后都在这上面发博客了。我对博客文章的排版算是比较重视，因为如果内容的排版不行，看起来很难受。使用工具栏手工排版总感觉麻烦。现在好了，自从用了Markdown，再也不用担心博客排版的问题了~
WAMPSERVER。以前我就想搭建自己的服务器，但是不知道怎么搭建。直到这次我为了测试api而使用WAMPSERVER，才发现如果
仅仅是想在Windows上建一个服务器，竟然如此的简单。这个收获还是蛮大的，然而我在知道了这点之后，反而把我的阿里云服务器改成Linux系统 _(:з」∠)_花生壳。服务器搭建完毕，如果再来个域名就更棒了。只需8块钱就能有自己的域名，简直棒。每月有1G的流量可以用。虽然有时候会断掉，但总比没有强，毕竟只花了8块钱。
Google、赛风、Hosts。之所以这三者合在一起讲，是因为它们都跟翻♂墙有关。我经常需要去Google搜索技术相关的信息，用百度查不到什么特别有用的信息，现在我基本抛弃百度搜索了，主要搜索引擎改为 必应搜索 。不过让我找到赛风和Hosts还是因为我要看Android的官方文档，发现它们花了我不少功夫。期间试过使用VPN，也买了个便宜的。不舍得花太多钱买VPN，但便宜没好货，经常连不上，连上了也容易断。后来就没再用VPN了。
原型制作工具、流程图制作工具。这两种工具都是在需求分析的时候用的。
原型制作使用了在线的工具 墨刀 。功能一般，比较不错的地方是能将每个页面保存为图片下载下来，也可以生成原型的APK。
还有一款软件：axure，但是由于我们组负责制作原型的同学用的是墨刀，我就只用过一次这软件。
流程图制作使用了 Process On ，还可以。
-
学习和掌握的新语言、新平台
在Android上开发用到的JAVA语言，在我之前做的 福大成绩查询 小玩具就稍微熟悉了一小部分，主要还是面向过程的做法（我现在都无法直视那些代码，想着什么时候去重构一下 _(:з」∠)_ ）。这次是学习了各种面向对象的知识。
除此之外，还接触了新语言（PHP）。主要是看队友学PHP时花了太多时间看视频，还做练习，学了好几天写不出一个API。我特地花了两个多小时时间大致学了一遍PHP，写个API给他参考。当然，由于用到的PHP知识不多，也没什么可骄傲的……（= =好吧，我承认对此我还是有点得意）
-
学习和掌握的新方法
-
跟别人沟通的时候，如果意见不符，就去了解对方的基本假设，也就是对方的相关知识储备。我在下面 人月神话 这部分举了实际的例子。
-
细化目标。这应该是我从这门课中收获最多的一点。仅仅有一个模糊的目标是不够的，要通过一步步分解，将其转化为一个个可行的小目标。我之前使用“从目前的情况来计划未来”的方法，结果目标的粒度很大，而且仍然模糊。后来从《构建之法》中学到了Work Breakdown Structure，即从未来的目标倒推每一个时期应该完成哪些任务。并且从项目中实践这一方法作为练习。从结果来看，效果很好。
-
-
其他的提升
心态上。
由于一开始表现还算不错，得到了老师的关注。不过同时也感受到了巨大的压力（是真的巨大压力！差点哭出来那种！）。感觉自己“装逼”装得太过了，让老师对我有过高的期望，与此同时又没有能够匹配这份期望的实力。还记得那时整个人精神很差，受不了，就爬上床。躺在床上一步步剖析自己压力的根本来源，让自己重新找回了自信。这为我以后碰到类似压力大的情况提供了解决方案。
不得不提的是，那天晚上找栋哥聊天，他说 “老师，看见的是 一个学生 3年之后、5年之后。而不是这个学生现在。” 我那些不必要的压力就此消失，(づ￣ 3￣)づ感谢栋哥。
总之，尽最大努力去做好应该做的事。如果因为老师的期待，反而被压力所困住，那就离他们的期待更远啦。相信老师的眼光，也相信自己。思想上。
由于我总是追求完美，所以做一件事情的时候总是花很多时间准备。比如说，写一篇博客的时候，如果觉得内容还不完善，我就不会把它发表出来。这显然是不具备软件工程思想的表现。
在助教范老师（博客）不断强调“迭代”后，我逐渐开始改变想法。“有点内容了就先发出来”，为此踏出的第一步是 项目耗时估计的方法 这篇博客。很遗憾，我至今仍未对其进行迭代，我总是选择去做其他事情。But，这仍然有好处。为何？因为我会经常想起我还有一篇未写完的博客，我不会让他一直不完整下去。相较于为了等待完善最终不去完成，这种做法显然好了很多。
很感谢范老师，让“迭代”这个词深深地印在我的脑海里。
-
二、写下属于自己的人月神话——项目实践中的经验总结+实例/例证结合的分析
-
“一个优秀的PM，能把一个一般的团队带成优秀的团队；一个糟糕的PM，能把一个优秀的团队带成糟糕的团队。”
这不是我说的，但我能感受到。因为在Alpha版本的时候，身为PM的我，还算马马虎虎。我的编程经验比其他三个都多（其实也就做了两个小玩具：八数码游戏和上面提到的成绩查询，在我的GitHub上可以找到）。并且我能意识到自己是个PM，要做好编程以外的事。队友不懂得使用GitHub来进行团队合作，我就写篇 教程 供他们参考。开发过程比较顺利，连快要考试的时候都照常开站立式会议。
而到了Beta版本的时候，我参与编码的程度比Alpha版本多很多。渐渐地，站立式会议前的准备越来越少。有几次是要开会了，我还在敲代码，停不下来……没有做好PM工作，对团队有多大的负面影响呢？- 会议的时间变得更长了。没有清晰的议题，浪费时间；
- 项目的主要进度变慢。我居然同意让一个队员去做某个不是很重要的功能，而这个功能花了他将近两天的时间；
- 对项目的把握程度降低了。我甚至不知道接下去该让队友干嘛了！还要问队友“你现在在做哪部分，接下去你要做什么”。队友有时候也不知道自己该干嘛，这时没有安排任务给他们，他们就放松下来了；
- 由上一条而导致的，大家的积极性降低了。身为项目的领导者，不能给其他人指出一条明确的道路，简直是糟糕。
如果这样继续下去，对于项目来说是很危险的。这个时候有个可行的做法，就是让队友尽可能指出当前项目还有哪些未完成的地方。然后带着这些去把整个项目的代码看一遍，可以重新把握住项目的进展。这点在 Beta团队总结 里也有提到。
-
一定要时刻提醒自己是PM，PM的本职工作不是编码，要把本职工作做好，而不是过多的参与编码。
PM做开发和测试之外的所有事情 —— 《构建之法》
那么作为新手PM，具体要做好哪些事呢？
-
一定要做好需求分析！一定要做好需求分析！一定要做好需求分析！
重要的事情说三遍！
如何开发一款吸引人的软件？自己觉得这款软件很牛逼就行了吗？这显然是不够的。无法满足用户的需求，没有市场，就难以生存。
不要说人要有个性啊，也不要说一味满足别人的需求是不正确的啊。你要想清楚你的目标是什么。做出一款大家都喜欢且有实际用途的软件，还是一款用来自娱自乐的软件，甚至做完就扔掉的软件？
我们的实际做法：
首先了解别人需要什么，是最关键的。
在了解的过程中要做好记录。可以用笔记录，但是推荐在初期尽量使用录音设备。像我们团队是做教师的报课系统，在教务处描述需求的时候，我们就录音了。这对我们后来分析需求的时候很有帮助。因为当时做笔记也不是很清楚，还有客户在描述的时候，前后会有矛盾。如果不仔细琢磨，很容易误解。
记录下来之后就要去分析。
用思维导图也好，画程序的主要流程图也好，尽量把客户的需求描述转换成图，并且让客户能够看懂。最好做个原型，并且做完后演示一遍给客户看。其实软件工程里的做法是使用【用例图】（即Use Case），不过当时没有学到这个，就自己想了上面那两种图。
关于这部分的心得，我另外写在一篇博客上了：【软件工程心得】与真实客户交流 -
给团队一条清晰的路线，至少短期内要清晰。这点在上面有提到了。团队成员对该项目的信心，很大程度上取决于PM给的路线是否清晰。具体来说要做哪一些呢？
-
理清项目应该实现哪些功能，对这些功能分类。哪些功能是核心功能（那些能满足用户主要需求的功能）？哪些是看起来很重要，但不是核心的功能？哪些是可有可无的功能？要先把核心功能做完！要先把核心功能做完！要先把核心功能做完！Alpha版本的时候，我看我们班另外一组，在快到版本演示的时候，还在为一个不重要的搜索功能止步不前！与此同时，他们核心功能并没完成多少。我跟他们强调了几遍，要先做核心功能。后来他们在Beta版本的时候，终于意识到了这点，进度立马快了很多。而我们团队呢？一开始我就筛选好了，并让队友做的基本都是最主要的功能。很经常发生的一幕就是，队友跟我说“xxx很难完成”、“这个功能不错”，我一想，不是主要功能，直接跟他们说不做。最可怕的是Alpha版本，被我砍了无数的功能……
-
理清功能是第一步。接下来就是细化它们。让它们变成一个个小到让人觉得可以完成的任务。什么叫“觉得可以完成的任务”呢？就是知道去哪里找相关知识，不用去查阅书籍教程多余的部分。或者以他当前的知识，花点时间就能完成。当然，要做到这点，可能需要对所用到的编程语言有一定的了解。不过一开始可以不用细化到特别接近代码实现。去看看《构建之法》的Work Breakdown Structure吧！
-
细化完任务，要到GitHub上发布Issue。如果不发Issue，队友可能会忘记要做什么。在发布Issue的时候，要大致描述应该做哪些，尽管你可能在开会的时候就告诉他们了。但是在开会的时候，你告诉他们的是很详细的信息。在实际开发中，他们还是需要参考你给的Issue。不要写太简单太笼统，也不必太详细。
-
-
对团队合作有帮助的工具要多学。学好GitHub的团队合作流程，能为团队省掉不少时间。
-
既然是团队合作，那么交流的时候难免发生意见冲突的情况，这时PM要hold住全场。关于这方面，可以看《构建之法》第二版的4.6.1节。书上这些做法是很不错的，但依我目前的极度缺乏的人生经验，没有体会到它们的精髓，这是实话。
我通过观察发现：人与人之间在交流的时候出现冲突的一种原因，很可能是基本假设不同。这里说的基本假设，指的是知识储备，以及建立在知识储备上的认识。
对此，我在跟队友交流的时候，特意注意了这一点。举个例子：有个登陆的操作，根据传入的账号和密码，来判断是否让他登陆成功。你会怎么做？法一：先把这张表里的所有用户查询出来。然后在查询结果里，使用for循环依次遍历所有行，在循环时取出某一行的数据跟传入的账号密码相比较。如果都相等，则返回登陆成功；如果遍历完之后还没有相等，则返回登陆失败。
法二：在查询数据库的时候，使用where参数，把账号密码传进去让数据库查询，并返回结果。如果结果行数大于0，则表示查询到了，登陆成功。如果结果的行数不大于0，则表示没有查询到，登陆失败。
对方选择法一，认为法一更合适。理由是他看一个有开发经验的同学这么做，而我则是没有相关的开发经验。
而我选择法二，因为我认为让数据库去查询会比查询全部然后遍历来得有效率。
通过上面两段，可以看出，这两者只是在表面阐述了各自的想法。争论的时候情绪已经上来了。
后来我想着，在浅层知识相争是不行的。于是静下心来问他：你是不是认为在数据库查询的时候，也是这样一行一行遍历地查询？他说是。这样就找到问题的根源了，只需要了解数据库的查询过程就能解决问题。
至于谁的方案更好，查找相关资料或者用实际验证来说话就行了。这样算是解决了争论上的问题了吧。
-
-
谈谈编码方面。
- 当队友会对某一文件进行修改的时候，不要去重构这个文件的代码。我在编码的时候经常手贱，看到队友代码写得不够好，就想去重构它。有时候是全局修改变量名。这样也造成了许多冲突。还好我们团队都使用Git来管理代码，可以用合并工具来解决这些冲突。然而解决代码冲突还是浪费了很多时间，所以最好还是不要随意做这样的事情。如果想重构，只在某一个方法里重构。让其对外的行为不变即可，尽量不要改变整个文件的布局，特别是删除某个方法。
三、建议或者想说的话
- 对下一届实践安排的建议：
要在项目开始前，让PM去阅读《构建之法》。
不要让PM一开始就参与编码，让他好好学学项目管理。参与编码很容易陷入细节而忘了大局。PM要以项目大局为重。
告诉所有同学，编程差没关系，照样能拿高分。
这是【软件工程】实践课！这是【软件工程】实践课！这是【软件工程】实践课！
不是【高级程序语言】实践课！也不是【软件开发】实践课！
我发现很多同学都陷入编程中无法自拔，实际上学到的软件工程知识不多。
- 对开学初的自己：
《构建之法》是本好书，它对你将要开始的项目很有指导意义。趁着还不忙，赶紧看两遍压压惊。不要像我现在，还没有好好地把它看一遍。
- 对大一的自己：
照着高中定好的大学规划走就对了。虽然编程会差点，但是以目前的情况来看，总体还算不错。
-
对栋哥：
我竟然到大三才成为你的学生！！！不过能遇到，总算是幸运。 -
对范老师：
存在感极强的助教233
你给的很多资料都很棒！请务必继续带我们了解计算机这个行业。虽然有时候会冷场，但是同学们其实都有认真看的。 😃
四、对未来的你的期许
- 我希望未来的我，对计算机的研究要足够深。
- 不能止步于了解如何使用，要了解其原理。
- 要做更多的创造，好好使用编程技能提高自己的生活效率。
- 写一些高质量的博客。
五、我们的团队（爆照啦~）
团队博客目录： 团队博客目录
这是我们刚组完队的合照：
以下是Beta版本之后的合照：
最上面那个就是我啦
个人照：
（逃
