《构建之法》课程总结

这个作业属于哪个课程	<课程链接>
这个作业要求在哪里	<作业要求链接>
团队名称	六扇门
这个作业的目标	对这学期的学习做一个总结
Github地址	https://github.com/slothph

彭皓 201731062323

阅读作业博客链接：https://www.cnblogs.com/slothph/p/11503162.html

问题一：

前期的准备更加完善（需求分析的全面等），还是实践经验的丰富加速了代码的编写？

答：两者皆有，但经过这一学期课程的学习，让我更加注重前期需求分析的全面性，并不是说一定要前期把需求定死，毕竟需求永远在变化，而是说考虑需求时要更为全面，对各项功能难点进行评估并整理出各功能的优先级，在遇上技术难点时，如何妥善处理，前后端对接时的格式要求等。这些在需求分析阶段明确定义并严格执行的话，即使出现需求变更的情况，也能减少部分时间损失，加速代码编写。

问题二：

如何判定舒适区、学习区、恐慌区，如何选择适合自己的学习区

答：当初是我有点钻牛角尖了，从学习时，自身的感受来划分这三个区域即可，界限因人而异。以我为例，我的学习区就是不能看天书，有新的需要学习的内容，看过之后能够思考为什么，动手操作几下，记录下笔记防止以后遗忘的一系列知识都在我的学习区内。

问题三：

代码复审和软件测试的异同。

答：复审发生在测试之前，代码复审后能一定程度上减少测试时间。代码复审是程序员在编写完代码后，看代码是否在代码规范的框架内正确的解决了问题。其中最重要的两个字是——规范。每个人有每个人的习惯，也许这个功能实现很成功，但是别人难以读懂，这对合作开发来说是一个障碍。另一方面，代码复审可以在初期就发现一些缺陷并进行改正、优化，还能起到教育作用。软件测试也能检测错误并督促改正，但教育、传授经验方面作用就比不上了。

问题四：

项目经理（PM）的作用，管理出身，还是计算机出身更为合适呢？

答：原先以为PM不编代码、测试、设计，只是动动嘴而已，这学期看着组长掉的头发才知道那是真的辛苦。项目开始时就需要以全局的眼光看透整个流程，然后进行安排，要对项目的内容极为熟悉，组内成员遇到问题还需要自己撸起袖子往上顶，各方面进行协调，是小组内的核心之一。PM的存在，使得项目的成本、耗时、质量在一定范围内达到最好。在我看来，软件项目的PM还是懂点计算机相关知识的更好，不然沟通协调难度太高，容易产生矛盾。

问题五：

小作坊、大公司之间的创意差别，团队中的人数多少合适，越多越好么？

答：书上说，IT历史上，许多的成功产品都是小作坊开始的；不得不承认，在创意还是点子，还没有被发现其闪光点的时候，小作坊能将其孵化出来，让人眼前一新，但更多是由于技术、经济等原因胎死腹中。不能说大公司没创意，只不过求稳让某些方面看起来平庸了，创意并不是小作坊所独有的，大公司会逐渐形成自己的特色并加以创新。团队人数在软件方面并不是越多越好，人多了反而增添交流成本，适中即可，重点是全面，要各个方面都有人能撑场子即可。

　　是否产生了新的问题？请提出。

　　暂时没有。

经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。

真的是学了很多，博客的编写，giithub的使用，原型工具的涉猎，vs的各种功能体验，敏捷开发的实施等等。掌握的方法嘛，做中学。看着高大上的一些东西，操作起来，也确实是高大上，但操作过后才会不断地遇到问题，并尝试解决，加深脑海中的印象。

有什么深刻的体会，对自己一学期学习过程的总结。

多元且丰富，让我神器感受到了软件工程不止是写代码的，而是需要“十八般武艺”样样精通，软件和工程一样重要，感谢这次课程让我体会到了软件工程中的艰辛，也确确实实学到了许多的知识，了解了软件开发中的各项流程，受益匪浅。

 

标签：总结,复审,代码,学期,学习,课程,构建,小作坊,PM
来源： https://www.cnblogs.com/slothph/p/12036748.html