作业九：总结

一：对前期提出问题的回答

1.所有编程语言之间有什么联系，为什么不可以一种语言在所有软件中都通用？

答：每种不同的语言有不同的应用范围，所以不可以一种语言通用所有的东西，对于不同的应用需要使用不同的语言进行编程，这样在程序的运行及编写的过程中会更方便，更简洁。

2.我们在之前的编程中那些可以运行出结果的不规范（不完整）程序，对以后实际项目的整个程序会有影响吗？

答：我们之前做的编程中，那些不规范的代码对实际项目的程序不会造成很大的影响。但是在我们以后的编写代码的过程中要注意一些问题，就是代码规范。只有代码规范的去编写，在你后期的测试及检查中才可以更快的发现存在的问题，这样方便你在第一时间去解决问题。而不会在检查问题的时候，因为代码的不规范，造成花费大量的时间去差错，会很大的节省整个项目制作过程的时间。也会让你的代码在别人看来更加简洁完整，在别人查看的时候也会更加方便。

我们目前需要注意的一些编写代码的规范有：

注释：注释是对于那些容易忘记作用的代码添加简短的介绍性内容。请使用 C 样式的注释“/* */”和标准 C++ 注释“//”。类、方法、函数请使用 phpdoc 格式的注释，在函数及方法的注释中至少要有 @param 和 @return 标签。

书写规范：缩进与换行：每个缩进的单位约定是一个TAB(4个空白字符宽度)，需每个参与项目的开发人员在编辑器中进行强制设定，以防在编写代码时遗忘而造成格式上的不规范。并且所有换行采用 UNIX 格式，既只有 \n 换行。

命名原则：变量、对象、函数名一律为小写格式，单词之间一般使用下划线 “_” 进行分割。

常量：常量应该总是全部使用大写字母命名，少数特别必要的情况下，可使用划线来分隔单词。

变量初始化：任何变量在进行累加、直接显示或存储前必需进行初使化。

包含调用：包含调用程序文件时，请全部使用 require_once，以避免可能的重复包含问题。

SQL语句：所有 SQL 语句中，除了表名、字段名称以外，全部语句和函数均需大写，应当杜绝小写方式或大小写混杂的写法。例如 select * from members; 是不符合规范的写法。

数据库 SQL 语句中，除字符串外所有数据都不得加单引号，但是在进行 SQL 查询之前都必须经过 intval 等相关函数处理；所有字符串都必须加单引号，以避免可能的注入漏洞和SQL错误。

3.当制作出一个软件之后，在推广的过程中有什么更好的方法吗（课外问题）？

答：目前的软件推广还是有很多途径的，比如在空间和博客进行宣传推广，在论坛和贴吧去进行发帖，让大家去了解你的产品及软件。但是在推广的过程中要注意的一些问题就是，在发帖的同时你要明确的告诉大家你的软件是做什么的，有什么功能，在使用的时候需要注意的一些问题。这样大家才会对你的产品及软件感兴趣，这样他们才愿意去尝试或者使用你的软件，当你的产品的实力或者使用效率好的时候，使用者自然会在他的朋友圈里帮你推广，省去了很大一部分推广的时间，还会让你的软件口碑更好一些。当然如果在经济条件允许的情况下，你可以通过媒体的方式去进行推广，这样的效果会比之前的方法更快，当然在推广的同时别忘了提高自己产品的综合实力，这样使用者才会愿意长久的去使用你的软件。当你在推广的过程中已经做的不错的情况下，要持续的提高你软件的功能，这样才不会让使用者觉得厌烦或者选择更新颖的软件去使用。

4.软件的好与坏的直接联系是“用户的体验”，当自己制作出的软件觉得好用或者不错的时候，用户体验觉得不好，是否该放弃（课外问题）？

答：当出现这种制作团队都觉得不错的项目时，而用户体验觉得不好。这时需要做的是产品的市场价值评估，当你们制作的这个软件市场价值很高的时候，你们可以选择继续完善自己的软件，增加一些新的功能，完善之前功能的一些“用户体验”不好的地方，提升产品的综合实力，这样更新出来的新产品就会被大众所认可，也会被更多人使用，因为市场价值高，所以在完善之后会有更多人愿意去使用。但是如果市场价值不高或者很低的时候，这时候就要考虑放弃这个软件的完善与开发，选择一个新的方向去制作，这样你们的产品才会被大众所接受，而且市场价值高一些的产品在推广的时候也会更方便，不至于没有用户愿意去尝试你的软件。

5.制作团队中如果出现分歧情况，那么该怎么处理团队中针对软件的不同意见（课外问题）？

答：如果制作团队中出现意见分歧的情况，要看具体是什么情况导致大家出现分歧。如果是制作方向上的分歧，那么大家需要坐下来一起来商量，找一个市场价值高一些的方向及产品去制作及开发，这样方便后期的推广。如果已经定下来制作的方向，在项目制作时功能情况的分歧，那么大家就应该一起商量一下，可以根据和要制作软件在目前现有的类似软件中的功能进行对比，哪些功能在使用的时候更方便简洁，哪些功能在实际使用的时候使用的人数比较多。根据这些实际的情况来制定具体项目的功能，可以考虑实行投票制，少数服从多数。如果项目的功能和方向都没有问题，分歧的意见在代码的编写上，那么就要找一些专业知识能力过硬的老师或者专业人士来进行询问，到底那种编写方法更好，这些专业的人会给你们团队更好的建议。

二：总结本学期软件工程课程的体会

      我觉得我在这一学期收获的东西还是很丰富的，让我很深刻的认识到了软件工程这门课程的重要，这门课程是可以让我们学习一辈子的东西，因为在我看来软件工程不只是一门课程，它是来教会我们如何去分析项目的开发需要的东西及环境，让我们去处理在项目制作及运营中的一些问题。因为之前有过跟我们自己的团队去制作及运营一个项目的经历，所以在学习这门课程的时候深有体会。一个项目从最开始的制定方向，具体构思，开发过程，实际运营这中间有很多的不容易，一个项目或者说产品的产生都经历了很多的不容易。

      在这学期的软件工程课上，我们从最开始的一个人去制作自己的四则运算到后来的两人一组的结对编程在到最后的团队项目，让每个人都成长了，学会了团队合作，学会了复查别人的代码，知道了要对代码进行规范的编写。谢谢冯华平老师教会我们这些，这学期的软件工程让我收获很多。

三：对课程的建议

在上次的博客中，您说让我们组长给组员进行评价及给出相应的分数，我觉得这点不是特别好，对于其中的给组员进行评价，我觉得没有问题，因为大家毕竟经过了这一次长时间的一起合作及团队项目制作的过程。但是在给分的这点上并不是特别好，因为每个人的基础不一样，对应的工作不一样，所以没办法合理的给出其在项目制作过程中的分数，建议取消组长给分的环节。