标签：补丁 got 思考 单元测试 需求 识别 北京地铁 大小 循环
一、在学期初我曾通过阅读教材发现了五个问题，现在我来对这些问题一一解答
1、问题：教材第二章讲在进行软件技术模块设计时，要越细越好，但是我在进行面向对象程序设计时，总是无法将某些模块分离开，导致某些方法代码行数过多，请问有没有更加具体一点的设计方法模板。
解答：这个问题老师也曾回复过我解决方法就是在设计的时候不妨也进行一些单元测试，这样有助于设计的展开，经过一个学期的学习与思考，我发现其实会发生这个问题主要是因为我编写代码的经验不足和思考问题不够全面导致，在个人项目和双人组队项目中我们的任务都是编写北京地铁的搜索路线工程，在刚开始的个人项目中，由于我在设计的时候完全没有经验，因此在实现代码的时候总是会出现一些在设计过程中没有考虑过的情况发生，比如说机场线的单向地铁，2号线的环形地铁会导致搜索死循环，和四惠到四惠东的一段路上有两段地铁等等，考虑上这些因素后，使得我的代码变得和设计上有很大出入，有些地方甚至不得不改变设计，增添很多方法。但是在第二次双人项目中，由于有了上次的实现经验，我们在设计阶段就考虑到了北京地铁这些特殊的情况，并分别采用了更加明确的方法用来解决问题，而不是临时“打补丁”，从而使代码的设计更规范。
2、问题：教材第二章在讲解使用代码分析工具时，注重讲解了代码分析工具的好处，而忽略了代码分析工具的额具体使用方法，我个人在使用过程中，发现不是很清楚很多参数的意思，请问能否提供一些具体的使用教程。
解答：在实际进行单元测试的时候，在单人项目和双人项目进行单元测试的时候，由于需要测试C#代码，我发现我使用的vs2015社区版不能够进行单元测试，要想使用vs的自带的测试工具只能使用vs2015专业版或者更老的vs版本，因此最终我使用的是vs2013社区版，测试方法见http://www.cnblogs.com/codeinet/p/4647394.html
3、问题：教材第四章讲goto语句在有助于理清代码逻辑的情况下，可以使用，但我在学习C语言时听说goto语句尽量不要使用，那会极大地增加代码调试难度，请问如何解释这一矛盾。
解答：这个问题我可能在编译技术那门课上找到了答案，编译器的实现过程中有一条就是首先讲源代码翻译成中间代码，再将中间代码翻译成汇编。我们所采用的中间代码即是四元式，我所使用的四元式中有一条指令为 j，即为无条件条状指令，与C语言中的goto类似，编译技术中很常见的一种源程序情况即为翻译while语句，每个while语句在翻译成四元式后结尾均会有一条j指令，用于跳转到循环开始，从C语言这种高级程序语言转化为同语义，但不同形式的四元式的时候，产生的j语句能够帮助我们更好的理清楚四元式的结构，帮助我们快速定位四元式中与while等语义的语句的位置，因此，我得出如下结论，在C语言这样的高级程序语言中goto语句确实会打破模块封闭性，增加调试代码难度，但是当goto这类无跳转语句用于理论上的代码分析（更加接近四元式这类低级语言）时候，更加有利于代码的定位和识别理解，因此两者不矛盾。
4、问题：教材第九章讲了PM的重要性，PM是负责做开发和测试之外的事情，而在实际完成这门课的项目工程的时候，请问是不是在我们的团队中并不需要PM这一角色？
解答：这个问题可能是我问的最没有技术含量的问题了，当初我对软件工程的理解太过狭隘，以为不过是一个领导带领一帮程序员写代码，但经过一学期的学习，我发现PM所需要做的事一点也不比我们少，他要及时了解每个团队成员的项目进度，编程过程中遇到的问题，以及这会对整个开发项目进度的影响，并实时动态做出调整，以保障项目在规定时间完成，还要不断向老师汇报工作进度，获取老师意见，和其他团队沟通获取需求，并规划这些事情对项目工作进度的影响。这些工作虽然繁琐，但对于整个项目至关重要，正是由于有PM的存在，我们这些开发人员才能安心，全心投入到工程里。所以PM不可缺少。
5、问题：教材第十二章将用户界面的重要性，那么在时间和精力有限的情况下，我们是应该舍弃一些扩展功能的开发而投入更多给界面还是着重去开发一些扩展的功能？
解答：一个良好的用户界面会给予用户极佳的用户体验，但更加炫酷的功能也是用户所期望的。但当时间不足以让两者均为最佳时，我们需要考虑这样一个问题，一些扩展的功能势必会引起界面的改动，这些改动可能是庞大的，甚至全新的界面，因此，在实现某些特定功能的时候，要考虑到界面团队能否在规定时间内完成这些需求上的改动，如若不能完成，则应放弃这一扩展功能的实现，否则即可考虑实现。
二、在学习完这学期的软件工程后，我又有了一些新的问题
1、在团队项目中，我充当的是后端代码的编写，这其中涉及到使用其他团队成员的方法，在调用之后，我需要进行测试以保证使用无误，有时发现问题后我还需要进行调试，对发现的问题进行定位，那么我在整个团队中的定位从一个代码整合者变为了调试者，于是有时我会对自己在整个团队中的定位有些困惑，请问我如何在团队中定义自己的角色？
2、在团队合作中，冲突是不可避免的，每个人对问题的理解有所不同但都有自己独到之处，我在团队中一般发生冲突的时候都会选择妥协，但在实施别人的计划之后有时还是觉得自己的想法可能会更加有效，此时应该怎么办？
三、软件工程中我所学到的知识点
1、需求
“客户永远是第一位的”：在需求方法，我深刻的感受到这一至理名言，一旦客户提出的需求有所改动，我们就需要更新甚至改变我们的开发进度，时时刻刻以满足客户的需求为准。
2、设计
“设计先于动手”：一个项目在没有完全理清楚结构之前直接动手是致命的，整个项目的实际情况和预期的出入，计划的调整甚至更改，可能直接导致整个项目在预期时间内完成不了。
3、实现
“减少或替换新技术的使用”：一项新技术的使用势必会导致从未解决过的问题的发生，这个问题可能导致整个工程进度的延期，在我们的项目中使用了java调用C#的技术，这项交叉编译的技术在我们当初设计的时候觉得根本不是难点，可就是这样一个不起眼的小问题，将我们的进度拖慢了2周时间，直接导致很多我们想要实现的功能没有实现。
4、测试
“完备的测试很关键”：一个团队中如果有一个人的代码有问题，则会影响到整个团队的工程发生问题，如果以整个工程为单位进行代码调试，任务量巨大而且效率极低，故每更新一个模块，每修改一行代码就应该进行完整的测试，这样发现问题后定位问题将会容易许多，不要觉得“我改这行代码没有问题”，你是这样理解这段代码的，但是其他人可能有不同的理解，从而有不同的使用方法，因此改动无论大小都应进行完备的测试。
5、发布
“注意发布版和实验版的不同”：发布版本首先要经历实验版本的测试，并且发布版的代码应该更加简洁，运行更加稳定，其运行过程中不应输出调试信息，代码中注释掉的代码也应该去除。
6、维护
“维护是一种责任”：所谓维护是指代码在发布稳定运行后依旧有人去定期关注其运行情况，保证无误，如若存在问题，及时纠正。维护是一个团队的责任，保障自己的程序能够正常运行，是对用户的负责任，也是自身的义务，责无旁贷。
标签：补丁 got 思考 单元测试 需求 识别 北京地铁 大小 循环
原文地址：http://www.cnblogs.com/nrm1/p/6257784.html
