软工网络15个人作业4——alpha阶段个人总结
alpha阶段个人总结
一、个人总结
| 类别 | 具体技能和面试问题 | 现在的回答（大三） |
|---|---|---|
| 语言 | 拿手的计算机语言 | java和C语言，一万左右的代码量 |
| 软件实现 | 有没有在别人的代码基础上进行改进, 你是怎么读懂别人的代码, 你采取什么方法来保证你的新功能不影响原来的功能, 遇到的bug是什么， 怎么解决， bug出现的原因 |
有,前段时间的结对编程就是在原有的代码上进行编程的， 通过他的注释等帮助阅读，主要是源代码比较规范阅读起来比较容易， 编写边测试啊，如果有影响就调整，不过编写过程中都避过了对旧功能的影响, 会遇到很多bug比如什么按钮没有反应之类的， 调试再阅读代码发现问题然后改正， 手滑、逻辑思考错误 |
| 软件测试 | 你是如何测试代码的？ 你掌握了多少种测试工具和方法？ 你写过测试工具么？ |
主要是用工具进行测试， 一般都是用到的时候百度查找一下工具，然后根据说明进行测试， 没有写过测试工具 |
| 效能分析 | 你写过最复杂的代码是什么？ 你是如何测量和改进它的效能的，用了什么工具，如何分析的？ |
编写算法的代码比较复杂 没做过测量和分析 |
| 需求分析 | 你做过多少个有实际用户的项目，用户最多有多少？ 你的项目有什么创新的地方？ |
目前软件工程的项目是我做的第一个有实际用户的项目，上一次统计有50个人左右的用户 把连连看游戏和背单词结合起来 |
| 行业洞察力 | 你最感兴趣的领域是什么？ 这个领域过去10年经历了哪些创新？ 你要进入这个领域，应该如何创新？ |
人工智能领域， 越来越聪明了，前段时间AlphaGo战胜柯洁真的是人工智能一大进步， 对这个领域了解还是比较少的，现在还没有想到什么创新点 |
| 软件设计 | 你做过架构设计，模块化设计，接口设计么？ 请说明一下你为何是这样设计，你比较过什么不同的设计方式，你的设计取得了什么结果？ |
在做java项目的时候做过接口设计， 这种设计方法可以方便开发人员进行改动儿不用改变太多代码，而且有利于分工合作 |
| 质量意识 | 你是怎么做代码复审的，你加入我们团队后，能帮助我们提高代码质量么，请具体说怎么提高？ | 主要根据代码规范说明书来做复审。会更加严格书写代码规范说明书的，然后严格按照说明书进行编码 |
| 工具/社区 | 你在各种开发平台都是用过什么样的工具， 自己写过什么工具来改进工作效率？ 你写的技术博客坚持了多久，读者最多的是哪一篇？ |
eclipes,devc++,vc,vsNetBeans、微信开发平台, 没有自己写过工具， 没有坚持多久，主要是老师作业要求用博客园写，博客园中读者最高的一篇是《201521123002《Java程序设计》第10周学习总结》 |
| 团队协作 | Work with 请描述你在项目中如何说服同伴采用你提出的更好的解决方案， 或者你如何听取了别人的意见，改进了自己的方案？ 你如何说服懒惰的同伴加紧工作，实现团队的目标？ |
通过对比的方法讲清楚我的解决方案的优点说服对方， 就是根据他们提出的方案的优点来改进 首先自己要动起来，每天规定一个时间开始收任务，然后催他 |
| 理论素养 | 你上过什么数学，计算机或其他理论课，明你学到的理论知识如何帮助你解决实际问题。 | 高等数学、线性代数，c语言，数据结构，计算机组成原理等，数学类和计算机类的知识其实是互通的，尤其在编写算法的时候就会发现除了要学号编程数学也很关键 |
二、回答问题
问题二：第4章 第90页，结对编程里如何正确地给予反馈中提到了反馈的三个层次，最外层：行为和后果、中间层：习惯和动机、最内层：本质和固有属性。攻击性从最外层到内层递增，文中写到
“三明治似的反馈让人更容易接受，先来一片面包，做好铺垫：强调双方的共同点，从团队的愿景讲起，再把放上肉，着重[行为和后果]这一层面的反馈，不要贸然进入到[习惯和动机]、[本质]，然后再来一片面包呼应开头，鼓励对方吧工作做好”
那么我们在做反馈的时候如何才能避免内层的反馈以至于伤到对方？当矛盾发生时又该怎么冷静的做最外层的反馈呢？冷静的时候人们会很容易分析问题，但是当真正面对问题的时候就会发现实践和理论很难做到统一。但这又和性格有关系，一般来说善于倾听性格较为温和的人在面对矛盾的时候回很容易调整自己，而比较自我一点的人他们会急于去解释，会强调自己这边的观点那么有的时候前一个矛盾还没解决，又生起另一个矛盾。所以如果针对性格比较不那么温和的人时如何回答我提出的问题呢？
回答：经历过alpha阶段的团队协作，我发现沟通真的是非常重要的。它可以让人理解彼此的想法解除不必要的误会。以前问如何冷静的做反馈沟通，但是实际上不用那么小心翼翼的，矛盾其实是无法避免的。我们应该大胆的做沟通，并根据对方的表现来调整说话的方式。不用再还没沟通之前就想太多如何避免矛盾防止矛盾。我们首先要信任彼此，然后积极的沟通这样才不会彼此积怨到最后爆发更大的矛盾
问题四：第四章 第84页
“每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间”
因为结对编程可以有这么多好处，所以大家很愿意去结对编程。但是书中没有就如何选择同伴展开讨论，比如两个人在一起一定会有磨合阶段，这个时候选择的同伴的不同在面对磨合的时候会有不同的处理方式，有的会很好的度过，有的可能就会闹掰，所以最开始的时候对同伴的选择还是很重要的，那么以我的经验还不能够很好的回答这个问题，所以选择同伴什么样才会比较适合呢？
回答：我觉得选择同伴还是比较总要的，如果在项目进行中同伴一直积极性不高是很影响整个项目的进度的。我通过这是alpha阶段，我觉得首先同伴是要对这个项目是有共同兴趣的，其次要有责任心答应完成的任务一定要按时完成不可以拖拉，最后我觉得才是一定的编程经历，因为在满足前两项的基础上他就会主动去学习去做好这个项目。
问题五：第17章 第392页
书中谈到在一个团队中定义的信任时这样写到：
"我信任大家做事的出发点都是为了团队的共同目标，每个人的水平、经历性格特点都不同，我不是完美的，当我犯错误，或者展现我性格中不成熟地方的时候，我信任我的同事会帮助我，但不会指责我的动机，或其他内在的属性"
很美好是吧，这样的定义。但是其实在团队建立的初期的时候这种信任时很难达到的，大家互不认识，对方是什么情况其实一点也不了解。而且在后期其实这种信任也是有点理想化。那么如何去靠近这种理想化的状态呢？
回答：经历过alpha阶段我觉得大家不认识或者不了解其实是没有关系的，大家可以搞团建啊彼此互相了解一下就认识了，所以认不认识并不重要。信任彼此这种其实是不用可以去达到的，大家可以彼此质疑这其实是一种很自然的现象，最重要的是沟通，大家通过沟通来了解彼此的缺点或者项目遇到的问题，大大方方自自然然的提出来，当大家在这个团队里能够畅所欲言时，那么这种情况这种氛围下大家就越能彼此信任越能达到理想状态。
三、再提问题
- 我在书中109页看到这样一段文字
软件团队尚未成熟，不懂得如何独立地进行需求分析，不懂得如何对行政领导有技巧地说“不”，也不知道如何说服利益相关者同意并支持正确的项目方向。既然不能驱动团队成员，那只能靠外力来驱动了。
问题一
我有一个问题，这段文字是用来讲述老板驱动的流程这种模式存在的原因之一，我疑惑的地方在于，老板在这里扮演的应该是一个商业角色，团队是负责开发的角色，如果有这样的模式存在，那么让一个外行的老板来驱动一个团队，那么这样出来的产品是能够符合客户需求的吗？我没有过这方面的经验无法得到自己的想法，所以我觉得这个问题只有有商业经历的人才能回答出来。
问题二
我的第二个问题还是关于这段文字，文字中写到“对行政领导有技巧的说不”，我不理解的地方在于一个团队为什么要和行政领导说不，团队不是只是负责开发的吗？为什么会和行政领导打交道，而且说不说“不”会影响项目的开发吗？同样的我在开发项目的时候没有遇到要和行政领导打交道的情况，我没有什么这方面的经验，所以对这个问题没有什么想法。
- 我在书中看到这样一段文字
用户体验的要素之一:从用户的角度考虑问题
问题三
我有一个问题，开发人员只有把产品开发完成后，推广给用户使用后才能得到真正的用户体验的反馈，为了避免需要很大的改动，开发团队如何在项目开发过程中尽量的贴近用户的需求呢?经历过alpha阶段的开发，我们在这方面主要还是通过参考平常使用过的App的一些优点来贴近达到好的用户体验，或者是我们这些开发人员的设想。但是在发布后我们还是得到了很多用户不满意的反馈。所以我还是很困惑那些专业的开发人员在开发过程中是如何去贴近好的用户体验的。
问题四
我有一个问题，文字说要从用户的角度考虑问题，那么用户的所有需求是否都要满足？开发人员可不可以想用户之未想？开发人员的想法和用户的想法在开发项目中应该占怎么样的比重？我们团队在alpha阶段主要还是把开发人员的设想放在用户的想法前面的，因为我们无法在开发过程中得到确切的用户的想法的反馈，只有我们这几个开发人员的对用户想法的推测。所以对于以上的问题，我们还是无法权衡那种是比较好的。
- 我在书中看到这样一段文字
所有软件公司都希望在修正所有的缺陷之后才发布软件。但是，第一，什么叫“缺陷”？如果只是一些无关大局的问题，用户可以绕过去的，我们非得马上解决么？第二，什么叫“改正”？如果修正方案中又有“缺陷”怎么办？做商用软件的人都在为此苦恼，只有优秀的软件公司能找到一个平衡点，及时发布能够解决用户问题的软件，并且能及时修改软件中的问题——注意，这两个“及时”并不一定是同一时间。
问题五
我有一个问题，如果在发布前发现了重大的缺陷，应该怎么处理呢？毕竟商用软件有各方利益存在，时间安排都是要考虑规划清楚地。在alpha阶段我们团队比较顺利的发布了产品，但是我们这个产品毕竟不是商用产品，需要负责任的对象比较少压力比较小，所以如果一个商用团队面临重大缺陷的话，他们一般的处理方法是什么，如何避免造成惨重的损失。
