软工实践课程总结

尽量让这篇总结照顾大局，但废话太多也写了八千多字。不像是总结啊喂！ _(:з」∠)_ 。
基本上按照老师给的结构来：【软件工程实践总结作业——个人作业】。

目录：

• 一、回望开学初对于软件工程课程的想象，回望博客开篇时对于这门课和这学期的期望

  • 对比现在的我和开学初博客开篇的课程目标和期待
  • 实践给我带来的提升
    • 学习和使用的新工具
    • 学习和掌握的新语言、新平台
    • 学习和掌握的新方法
    • 其他的提升

• 二、写下属于自己的人月神话——项目实践中的经验总结+实例/例证结合的分析

  • PM方面
  • 编码方面

• 三、建议或者想说的话

  • 对下一届实践的建议
  • 对于开学初的自己
  • 对于大一的自己
  • 对于开学初的老师

• 四、对未来的期许

• 五、我们的团队（爆照啦~）

软件工程的实践项目的自我目标》 ，拿几条出来说：

第一条：能够较快地做出提升自己生活质量的APP。这一点不太好说，但是肯定比以前快了。这一学期做项目学到了不少面向对象的知识。

第二条：写的代码有良好的扩展性和健壮性。良好算不上，但有一定的扩展性。自从了解了反射和泛型，感觉能在减少代码量的同时增加适用的广度。我不会告诉你，其实我是因为懒得写重复的代码才去学的这些知识 _(:з」∠)_

第三条：熟悉与多人合作的流程，任务的分配和代码的规范化。看到这点，不得不提GitHub的团队合作使用，使我收益颇丰。除此之外，从原来的不知道如何细分任务，提升到把一项任务分割到较小的粒度（当然，有时候还会有意识地防止粒度过小）。作为团队PM，这方面肯定要训练得比较多。此外，我去了解了Google的JAVA编码规范以及Android特有的编码规范，在此基础上做出一份我们团队编码规范，为代码的规范化迈出第一步。

不过对于项目的愿景规划，没做好。其实我一开始只想默默当个程序员的角色，开开心心地敲代码和钻研技术。然而当了PM，愿景规划就没执行了。不过想想，做PM的好处就是，技术的成长对整体的提升不是线性的。在这种时候去提升其他方面对自身的成长更有帮助，这次担任PM一职就为将来的提升打下了一定的基础。
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 ，还可以。
福大成绩查询 小玩具就稍微熟悉了一小部分，主要还是面向过程的做法（我现在都无法直视那些代码，想着什么时候去重构一下 _(:з」∠)_ ）。这次是学习了各种面向对象的知识。

除此之外，还接触了新语言（PHP）。主要是看队友学PHP时花了太多时间看视频，还做练习，学了好几天写不出一个API。我特地花了两个多小时时间大致学了一遍PHP，写个API给他参考。当然，由于用到的PHP知识不多，也没什么可骄傲的……（= =好吧，我承认对此我还是有点得意）
人月神话 这部分举了实际的例子。

教程 供他们参考。开发过程比较顺利，连快要考试的时候都照常开站立式会议。
而到了Beta版本的时候，我参与编码的程度比Alpha版本多很多。渐渐地，站立式会议前的准备越来越少。有几次是要开会了，我还在敲代码，停不下来……没有做好PM工作，对团队有多大的负面影响呢？

1. 会议的时间变得更长了。没有清晰的议题，浪费时间；
2. 项目的主要进度变慢。我居然同意让一个队员去做某个不是很重要的功能，而这个功能花了他将近两天的时间；
3. 对项目的把握程度降低了。我甚至不知道接下去该让队友干嘛了！还要问队友“你现在在做哪部分，接下去你要做什么”。队友有时候也不知道自己该干嘛，这时没有安排任务给他们，他们就放松下来了；
4. 由上一条而导致的，大家的积极性降低了。身为项目的领导者，不能给其他人指出一条明确的道路，简直是糟糕。

如果这样继续下去，对于项目来说是很危险的。这个时候有个可行的做法，就是让队友尽可能指出当前项目还有哪些未完成的地方。然后带着这些去把整个项目的代码看一遍，可以重新把握住项目的进展。这点在 Beta团队总结 里也有提到。

• 一定要时刻提醒自己是PM，PM的本职工作不是编码，要把本职工作做好，而不是过多的参与编码。

  PM做开发和测试之外的所有事情 —— 《构建之法》

  那么作为新手PM，具体要做好哪些事呢？

  1. 一定要做好需求分析！一定要做好需求分析！一定要做好需求分析！

     重要的事情说三遍！

     如何开发一款吸引人的软件？自己觉得这款软件很牛逼就行了吗？这显然是不够的。无法满足用户的需求，没有市场，就难以生存。

     不要说人要有个性啊，也不要说一味满足别人的需求是不正确的啊。你要想清楚你的目标是什么。做出一款大家都喜欢且有实际用途的软件，还是一款用来自娱自乐的软件，甚至做完就扔掉的软件？

     我们的实际做法：
     首先了解别人需要什么，是最关键的。
     在了解的过程中要做好记录。可以用笔记录，但是推荐在初期尽量使用录音设备。像我们团队是做教师的报课系统，在教务处描述需求的时候，我们就录音了。这对我们后来分析需求的时候很有帮助。因为当时做笔记也不是很清楚，还有客户在描述的时候，前后会有矛盾。如果不仔细琢磨，很容易误解。
     记录下来之后就要去分析。
     用思维导图也好，画程序的主要流程图也好，尽量把客户的需求描述转换成图，并且让客户能够看懂。最好做个原型，并且做完后演示一遍给客户看。其实软件工程里的做法是使用【用例图】（即Use Case），不过当时没有学到这个，就自己想了上面那两种图。
     关于这部分的心得，我另外写在一篇博客上了：【软件工程心得】与真实客户交流

  2. 给团队一条清晰的路线，至少短期内要清晰。这点在上面有提到了。团队成员对该项目的信心，很大程度上取决于PM给的路线是否清晰。具体来说要做哪一些呢？

     • 理清项目应该实现哪些功能，对这些功能分类。哪些功能是核心功能（那些能满足用户主要需求的功能）？哪些是看起来很重要，但不是核心的功能？哪些是可有可无的功能？要先把核心功能做完！要先把核心功能做完！要先把核心功能做完！Alpha版本的时候，我看我们班另外一组，在快到版本演示的时候，还在为一个不重要的搜索功能止步不前！与此同时，他们核心功能并没完成多少。我跟他们强调了几遍，要先做核心功能。后来他们在Beta版本的时候，终于意识到了这点，进度立马快了很多。而我们团队呢？一开始我就筛选好了，并让队友做的基本都是最主要的功能。很经常发生的一幕就是，队友跟我说“xxx很难完成”、“这个功能不错”，我一想，不是主要功能，直接跟他们说不做。最可怕的是Alpha版本，被我砍了无数的功能……

     • 理清功能是第一步。接下来就是细化它们。让它们变成一个个小到让人觉得可以完成的任务。什么叫“觉得可以完成的任务”呢？就是知道去哪里找相关知识，不用去查阅书籍教程多余的部分。或者以他当前的知识，花点时间就能完成。当然，要做到这点，可能需要对所用到的编程语言有一定的了解。不过一开始可以不用细化到特别接近代码实现。去看看《构建之法》的Work Breakdown Structure吧！

     • 细化完任务，要到GitHub上发布Issue。如果不发Issue，队友可能会忘记要做什么。在发布Issue的时候，要大致描述应该做哪些，尽管你可能在开会的时候就告诉他们了。但是在开会的时候，你告诉他们的是很详细的信息。在实际开发中，他们还是需要参考你给的Issue。不要写太简单太笼统，也不必太详细。

  3. 对团队合作有帮助的工具要多学。学好GitHub的团队合作流程，能为团队省掉不少时间。

  4. 既然是团队合作，那么交流的时候难免发生意见冲突的情况，这时PM要hold住全场。关于这方面，可以看《构建之法》第二版的4.6.1节。书上这些做法是很不错的，但依我目前的极度缺乏的人生经验，没有体会到它们的精髓，这是实话。

     我通过观察发现：人与人之间在交流的时候出现冲突的一种原因，很可能是基本假设不同。这里说的基本假设，指的是知识储备，以及建立在知识储备上的认识。
     对此，我在跟队友交流的时候，特意注意了这一点。举个例子：有个登陆的操作，根据传入的账号和密码，来判断是否让他登陆成功。你会怎么做？

     法一：先把这张表里的所有用户查询出来。然后在查询结果里，使用for循环依次遍历所有行，在循环时取出某一行的数据跟传入的账号密码相比较。如果都相等，则返回登陆成功；如果遍历完之后还没有相等，则返回登陆失败。

     法二：在查询数据库的时候，使用where参数，把账号密码传进去让数据库查询，并返回结果。如果结果行数大于0，则表示查询到了，登陆成功。如果结果的行数不大于0，则表示没有查询到，登陆失败。

     对方选择法一，认为法一更合适。理由是他看一个有开发经验的同学这么做，而我则是没有相关的开发经验。

     而我选择法二，因为我认为让数据库去查询会比查询全部然后遍历来得有效率。

     通过上面两段，可以看出，这两者只是在表面阐述了各自的想法。争论的时候情绪已经上来了。

     后来我想着，在浅层知识相争是不行的。于是静下心来问他：你是不是认为在数据库查询的时候，也是这样一行一行遍历地查询？他说是。这样就找到问题的根源了，只需要了解数据库的查询过程就能解决问题。

     至于谁的方案更好，查找相关资料或者用实际验证来说话就行了。这样算是解决了争论上的问题了吧。

团队博客目录

这是我们刚组完队的合照：

以下是Beta版本之后的合照：

最上面那个就是我啦

个人照：

（逃