标签：解决 yourself 关于 重要 版本管理 部分 协同 ali 原因
(1)
| 类别 | 具体技能和面试问题 | 现在回答 |
|---|---|---|
| 语言 | 最拿手的计算机语言之一，代码量多少？ | C语言 几百行 |
| 软件实现 | 你有没有在别的代码的基础上改进，你是怎么读懂别人的代码，你采取什么办法保证你的新功能不会影响原来的功能？你在开发中碰到最复杂的bug是什么，你是如何解决的？这个bug出现的原因是什么，你将来应该怎么样去避免bug出现？ | 为了读懂别人的代码，我会尽量与代码的原作者联系，请他对代码做出尽可能详尽的说明；最复杂的bug：把程序写错了，导致冒泡排序无法正确执行，百度一下冒泡排序的算法，读下去记住它；多学一些算法相关的内容避免低级错误的发生 |
| 软件测试 | 你是如何测试你自己写的代码？你何如测试别人写的代码？你掌握了多少种测试工具和方法?你写过测试工具吗?你如何对一个网站进行压力测试和技能测试？你如何测试一个软件的人机界面？ | 通过实际运行编写好的程序以测试代码，通过编写测试函数并执行以测试代码；没写过测试工具，网站压力测试没接触过；邀请用户使用软件，在实际的使用过程中完成软件人机界面的测试 |
| 效率分析 | 效能分析，效能改进，你写过的最复杂的代码是什么？你是如何测试量和改进他的效能的，用了什么工具，如何分析？ | C语言学生成绩管理系统，期末考的时候写在纸上，无法分析 |
| 需求分析 | 你做过多少有实际用户的项目，用户量是多少？你的项目有什么创新的地方? | 没做过 |
| 团队协作 | Work with others（协同工作，提供反馈，说服别人请描述你在项目中如何说服同伴采用你提出的更好的解决方案，或者你如何听取别人的意见，改进了自己的方案？你如何说服懒惰的同伴加紧工作，实现团队的目标？ | 实践出真知，在相互之间的比较中决定自己还是他人最优；说服同伴点到为止，同伴不听就放弃 |
| 理论素养 | 你上过什么数学，计算机或者其他理论课，请举具体的例子，说明你学的理论知识如何帮助你解决实际问题。 | 学过数据结构（最小生成树，迪杰斯特拉算法），高等数学，计算机组成原理、离散数学等，主要还是初步了解编程同时锻炼逻辑思维，为编程实践提供基础 |
(2)
| 编号 | 问题 | 回答 |
|---|---|---|
| 1 | 当你看到不靠谱的设计、糟糕的代码、过时的文档和测试用例的时候，不要想 “既然别人的代码已经这样了，我的代码也可以随便一点啦。” | 一直主动这样做 |
| 2 | 主动解决问题。当看到不靠谱的设计，糟糕的代码的时候，不要想“可能别人会来管这个事情” ，或者“我下个月发一个邮件让大家讨论一下”。要主动地把问题给解决了 | 一直主动这样做 |
| 3 | 经常给自己充电，身体训练是运动员生活的一部分，学习是软件工程师职业的伴侣。每半年就要了解和学习一些新的相关技术。通过定期分享（面对面的分享，写技术博客等）来确保自己真正掌握了新技术。 | 一直主动这样做 |
| 4 | DRY （Don‘t Repeat Yourself）——别重复。在一个系统中，每一个知识点都应该有一个无异议的、正规的表现形式 | 一直主动这样做 |
| 5 | 消除不相关模块之间的影响，在设计模块的时候，要让它们目标明确并单一，能独立存在，没有不明确的外部依赖。 | 一直主动这样做 |
| 6 | 通过快速原型来学习，快速原型的目的是学习，它的价值不在于代码，而在于你通过快速原型学到了什么。 | 一直主动这样做 |
| 7 | 设计要接近问题领域，在设计的时候，要接近你目标用户的语言和环境。 | 不但主动做， 还会影响同事一起做好 |
| 8 | 估计任务所花费的时间，避免意外。在开始工作的时候，要做出时间和潜在影响的估计，并通告相关人士，避免最后关头意外发生。工作中要告知可能的时间变化，事后要总结。 | 一直主动这样做 |
| 9 | 图形界面的工具有它的长处，但是不要忘了命令行工具也可以发挥很高的效率，特别是可以用脚本构建各种组合命令的时候。 | 一直主动这样做 |
| 10 | 有很多代码编辑器，请把其中一个用得非常熟练。让编辑器可以实现自己的定制，可以用脚本驱动，用起来得心应手。 | 做得不太到位 |
| 11 | 理解常用的设计模式，并知道择机而用。设计模式不错，更重要的是知道它的目的是什么，什么时候用，什么时候不用。 | 做得不太到位 |
| 12 | 代码版本管理工具是你代码的保障，重要的代码一定要有代码版本管理。 | 做得不太到位(偏向于使用码云完成代码管理) |
| 13 | 在debug的时候，不要惊慌，想想导致问题的原因可能在哪里。一步一步地找到原因。要在实践中运用工具，善于分析日志（log），从中找到bug。同时，在自己的代码里面加 log. | 做得不太到位 |
| 14 | 重要的接口要用形式化的“合同”来规定。用文档和断言、自动化测试等工具来保证代码的确按照合同来做事，不多也不少。使用断言 (assertion) 或者其他技术来验证代码中的假设，你认为不可能发生的事情在现实世界中往往会发生。 | 做得不太到位 |
| 15 | 只在异常的情况下才使用异常 (Exception), 不加判断地过多使用异常，会降低代码的效率和可维护性。记住不要用异常来传递正常的信息。 | 一直主动这样做 |
| 16 | 善始善终。如果某个函数申请了空间或其他资源，这个函数负责释放这些资源 | 一直主动这样做 |
| 17 | 当你的软件有多种技术结合在一起的时候，要采用松耦合的配置模式，而不是要把所有代码都混到一起。 | 一直主动这样做 |
| 18 | 把常用模块的功能打造成独立的服务，通过良好的界面 (API) 来调用不同的服务。 | 一直主动这样做 |
| 19 | 在设计中考虑对并行的支持，这样你的API 设计会比较容易扩展。 | 做得不太到位 |
| 20 | 在设计中把展现模块 (View) 和实体模块 (Model) 分开，这样你的设计会更有灵活性。 | 做得不太到位 |
| 21 | 重视算法的效率，在开始写之前就要估计好算法的效率是哪一个数量级上的（big-O）。 | 做得不太到位 |
| 22 | 在实际的运行场景中测试你的算法，不要停留在数学分析层面。有时候一个小小的实际因素 (是否支持大小写敏感的排序，数据是否支持多语言)会导致算法效率的巨大变化。 | 一直主动这样做 |
| 23 | 经常重构代码，同时注意要解决问题的根源。 | 一直主动这样做 |
| 24 | 在开始设计的时候就要考虑如何测试 ，如果代码出了问题，有log 来辅助debug 么? 尽早测试，经常测试，争取实现自动化测试，争取每一个构建的版本都能有某些自动测试。 | 做得不太到位 |
| 25 | 代码生成工具可以生成一堆一堆的代码，在正式使用它们之前，要确保你能理解它们，并且必要的时候能debug 这些代码。 | 一直主动这样做 |
| 26 | 和一个实际的用户一起使用软件，获得第一手反馈。 | 做得不太到位 |
| 27 | 在自动测试的时候，要有意引地入bug，来保证自动测试的确能捕获这些错误 | 一直主动这样做 |
| 28 | 如果测试没有做完，那么开发也没有做完。 | 一直主动这样做 |
| 29 | 适当地追求代码覆盖率：每一行的代码都覆盖了，但是程序未必正确。要确保程序覆盖了不同的程序状态和各种组合条件 | 一直主动这样做 |
| 30 | 如果团队成员碰到了一个有普遍意义的bug, 应该建立一个测试用例抓住以后将会出现的类似的bug。 | 一直主动这样做 |
| 31 | 测试：多走一步，多考虑一层。如果程序运行了一星期不退出，如果用户的屏幕分辨率再提高一个档次，这个程序会出什么可能的错误? | 一直主动这样做 |
| 32 | （带领团队）了解用户的期望值，稍稍超出用户的期望值，让用户有惊喜 | 一直主动这样做 |
| 33 | （带领团队） 不要停留在被动地收集需求，要挖掘需求。真正的需求可能被过时的假设、对用户的误解或其他因素所遮挡。 | 一直主动这样做 |
| 34 | （带领团队）把所有的术语和项目相关的名词、缩写等都放在一个地方。 | 一直主动这样做 |
| 35 | （带领团队）不要依赖于某个人的手动操作，而是要把这些操作都做成有相关权限的人士都能运行的脚本。这样就不会出现因为某人休假而项目被卡住的情况。 | 做得不太到位 |
| 36 | （带领团队）要让重用变得更容易。一个软件团队要创造一种环境，让大家有轻松的心态来尝试各种想法 （例如，模块的重用，效能的提升，等）。 | 一直主动这样做 |
| 37 | （带领团队）在每一次迭代之后，都要总结经验，让下一次迭代的进度安排更可靠，质量更高。 | 一直主动这样做 |
| 38 | （带领团队）团队中往往会有矛盾产生，作为领头人，怎么办？ | 积极与组员沟通，努力协调矛盾；但是还是要承认一点，这方面我做得不太到位 |
Q1:关于结对编程
1.现在已经是大三下了，我们每天上完课以后剩余的时间不一定非常充足，而且即使有充足的时间，由于每个人将来目标的差异投入到软工课程的时间也是参差不齐的；我的疑问是：没有那么充足的时间，如何保证结对编程的质量？
时间就像海绵里的水，挤一挤总是会有的；每天尽量多花一些时间到编程上，一段时间后对自己的提升是十分显著的2.根据以往的课程设计经验，我发现比较早完成答辩的往往是哪些有dalao的小组，技术水平在结对编程里真的无关紧要吗？
技术水平只有想学习去学习才会提高，不学习的话技术水平无论如何也不会变化；在结对编程的过程中，两个人互相帮助，是相互提升的绝妙办法Q2：关于需求分析
我的疑问是：杀手功能是不是有可能随着市场的变迁，用户使用习惯的改变变得不那么必要，以至沦为外围功能（就像以前的小灵通 寻呼机）；在这种情况下软件开发者要怎么应对，要直接放弃整个软件吗？
市场竞争千变万化，人们的需求也在与时俱进，作为新兴产业的软件行业对市场需求的掌握要求也十分高Q3：关于用户体验
我的疑问是：当各种用户的用户体验之间产生冲突时，该如何处理，为每一种不同的用户体验开发不同的功能？这样做成本允许吗？还是向大多数用户让步，只要开发满足大多数用户的功能就好
尽量满足最大多数用户的需求，在开发者满足了最大多数用户的需求之后还有余力时再对剩余的用户需求进行弥补Q4：关于软件质量保障
我的疑问是：运维可以算作是软件工程质量标准的重要一环吗?
毫无疑问，就好像家用电器具的售后服务一样，良好的后续维护对一款软件的口碑至关重要，停止维护=软件死亡同时，大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。
问题1 对于第十六章 p354-355的内容有疑惑：在开发者自身看起来很棒的创意（卫星覆盖地球提供通信），为什么就是失败了呢，开发者自身是否已经进行了足够的用户需求分析呢？
问题2 第八章的疑惑：获取到了用户的需求之后，我们要如何确定哪些需求是首要的，哪些是没那么重要的，甚至在获取到许多自相矛盾的用户需求时？
问题3 我们在软件开发的过程中是否一定要严格按照书本上给出的众多软件工程开发模型一步一步向前推进？
问题4 书p35-36 大学生和工程师对比，具体编码时间减少了，测试 需求分析 的部分变多了，大学生和工程师的编程水平差了很多吗？如果不多，工程师如何保证用更少时间完成更好的程序？
问题5 关于“小强地狱”：被打入“小强地狱”的程序员还能及时赶上软件的开发进程吗？软件的开发进程会不会因为有人被打入“小强地狱”而遭到耽搁？
标签：解决 yourself 关于 重要 版本管理 部分 协同 ali 原因
原文地址：https://www.cnblogs.com/wufuckshuo/p/9058303.html
