标签：code 图形 新版本 没有 还需 人工智 避免 不能 原理
| 类别 | 具体技能和面试问题 | 现在回答 | 毕业找工作时 |
|---|---|---|---|
| 语言 | 最拿手的计算机语言之一，代码量多少？ | php，10000左右 | |
| 语言 | 最拿手的计算机语言之二，代码量有多少 | js+html+css，3000左右 | |
| 软件实现 | （代码阅读能力，实现，单元测试）你有没有在别的代码的基础上改进，你是怎么读懂别人的代码，你采取什么办法保证你的新功能不会影响原来的功能？你在开发中碰到最复杂的bug是什么，你是如何解决的？这个bug出现的原因是什么，你将来应该怎么样去避免bug出现？ | 1.有改进别人的代码，在一些实现方式或者想法上会有不同，会做改变 2.一个合格的码农都会做好注释，所以很容易看的懂 3.功能方面肯定尊重原来的核心，会做一些优化而已 4.最复杂的bug是apache配置出错，因为自己这方面很薄弱，所以排错很累 5.多总结自己的错误，尽量避免 | |
| 软件测试 | （测试方法，测试工具，测试实践，代码覆盖率）你是如何测试你自己写的代码？你何如测试别人写的代码？你掌握了多少种测试工具和方法?你写过测试工具吗?你如何对一个网站进行压力测试和技能测试？你如何测试一个软件的人机界面（UX/UI）？ | 测试方法就是每一次写了一部分功能就测试一些，而且测试所有的情况，一个模块写完也要测试一次。做好总结。关于ui界面浏览器可以模拟各种不同的访问载体，而且会在不同浏览器测试，尽量做好兼容性问题。 | |
| 效能分析 | （效能分析，效能改进）你写过的最复杂的代码是什么？你是如何测试量和改进他的效能的，用了什么工具，如何分析？ | 最复杂的现在写的软件工程项目。因为他结合了ui界面设计，js,ajax对php后台的交互，并且还要在云服务器上发布运行，比较系统全面。测试是不同人以不同方式不同时间对程序进行测试，测试他的压力承受力 | |
| 需求分析 | （需求分析，典型用户，场景，创新）你做过多少有实际用户的项目，用户量是多少？你的项目有什么创新的地方? | 以前没做过，只做了现在的团队项目；创新就创新在没人做过我们的产品，而我们的产品又非常有用，符合广大师生的需求，且现在已经可以使用了。 | |
| 行业洞察力 | 你最感兴趣的领域是什么？这个领域过去十年有什么创新？你分析过这个领域前十的产品吗？请分析一下他们的优劣，你要进入这个领域，如何创新？ | 最感兴趣的是人工智能和大数据，要想进入这些领域，首先需要各方面的基础知识，基础不通何谈创新，所以现在需要做的是学习相关知识 | |
| 项目管理 | 你参加过项目管理吗？如何决定各个任务的优先顺序？如果项目不能及时完成，你要怎么办？ | 没参与过；哪个重要哪个先做；不能及时完成就加班加点补救 | |
| 软件设计 | 你做过架构设计，模块化设计，接口设计么？请说明一下你为何是这样设计，你比较过什么不同的设计方式，你的设计取得了什么结果? | 做过；这样做可以减少代码量，还可以增加代码可读性 | |
| 质量意识 | （代码复审/代码规范/代码质量）你是怎么做代码复审的，你加入我们团队后，能帮我们提高代码质量么，请具体说明怎么提高？ | 1.优化数据访问速度 2.提高代码复用性 3.以用户的角度提供更好的用户体验 | |
| 工具/社区 | Software Tools(performance too l,version control,work item,TFS)你在各种开发平台（web,linux,PC,mobile,macheine learning）都使用过什么样的工具，自己写过什么工具来改进工作效率？给社区贡献过什么工具和代码？GitHub有分享代码么?你写的技术博客坚持了多久，读者最多的是哪一篇？ | eclipse、netbeans ,sublime,；大多数都是博客作业，只是几篇是自己的总结性博客 | |
| 团队协作 | Work with others（协同工作，提供反馈，说服别人请描述你在项目中如何说服同伴采用你提出的更好的解决方案，或者你如何听取别人的意见，改进了自己的方案？你如何说服懒惰的同伴加紧工作，实现团队的目标？ | 一个团队肯定都有不同的想法，我们会经常开会讨论项目的实施方向。我们会采取投票的方式来确定方案。对于‘懒惰’的同学，我会给予更对的鼓励，让他对这个项目产生更大的兴趣 | |
| 理论素养 | 你上过什么数学，计算机或者其他理论课，请举具体的例子，说明你学的理论知识如何帮助你解决实际问题。 | 高等数学、离散数学等各种数学类课程、C语言、计算机组成原理、Java、数据结构等；想高数离散这种课程更多的是锻炼我们的逻辑能力，设计成更好的算法，计算机相关基础知识是让我们了解这些程序的原理更好的掌握，语言类的东西就是让我们更好的实现自己想要实现的东西。 | |
| 自我管理 | 全年级你专业排名多少？你从刚入学（大学一年级）到现在排名有变化么？如何解释你的排名的变化？ | 排名相对于入学是有退步的，我觉得主要原因是自己想要把时间用在对自己更有用的方面，所以成绩会下降，不知道这种做法是否正确。 |
| 编号 | 问题 | 回答 |
|---|---|---|
| 1 | 当你看到不靠谱的设计、糟糕的代码、过时的文档和测试用例的时候，不要想 “既然别人的代码已经这样了，我的代码也可以随便一点啦。” | 不但主动做，还会影响同事一起做好 |
| 2 | 主动解决问题。当看到不靠谱的设计，糟糕的代码的时候，不要想“可能别人会来管这个事情” ，或者“我下个月发一个邮件让大家讨论一下”。要主动地把问题给解决了 | 不但主动做，还会影响同事一起做好 |
| 3 | 经常给自己充电，身体训练是运动员生活的一部分，学习是软件工程师职业的伴侣。每半年就要了解和学习一些新的相关技术。通过定期分享（面对面的分享，写技术博客等）来确保自己真正掌握了新技术。 | 一直主动这样做 |
| 4 | DRY （Don‘t Repeat Yourself）——别重复。在一个系统中，每一个知识点都应该有一个无异议的、正规的表现形式 | 这要讲场合 |
| 5 | 消除不相关模块之间的影响，在设计模块的时候，要让它们目标明确并单一，能独立存在，没有不明确的外部依赖。 | 想做，但是不知道怎么衡量效果 |
| 6 | 通过快速原型来学习，快速原型的目的是学习，它的价值不在于代码，而在于你通过快速原型学到了什么。 | 不但主动做，还会影响同事一起做好 |
| 7 | 设计要接近问题领域，在设计的时候，要接近你目标用户的语言和环境。 | 大概同意，但是怎么接近用户呢？ |
| 8 | 估计任务所花费的时间，避免意外。在开始工作的时候，要做出时间和潜在影响的估计，并通告相关人士，避免最后关头意外发生。工作中要告知可能的时间变化，事后要总结。 | 不但主动做，还会影响同事一起做好 |
| 9 | 图形界面的工具有它的长处，但是不要忘了命令行工具也可以发挥很高的效率，特别是可以用脚本构建各种组合命令的时候。 | 正在学习命令行工具 |
| 10 | 有很多代码编辑器，请把其中一个用得非常熟练。让编辑器可以实现自己的定制，可以用脚本驱动，用起来得心应手。 | 没有任何定制 |
| 11 | 理解常用的设计模式，并知道择机而用。设计模式不错，更重要的是知道它的目的是什么，什么时候用，什么时候不用。 | 每写100行程序，我就尽量用一个模式。 |
| 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 | （带领团队）团队中往往会有矛盾产生，作为领头人，怎么办？ | 不但有明确和一致的处理原则，而且对于影响团队士气的任何事情追究到底 |
程序=数据结构+算法
软件=程序+软件工程
程序（算法、数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量。
——第1章 概论
可以说，软件工程是我们大学所学软件课程的一个汇总，不仅对编程的知识需要精通外，算法和数据结构同样占据很大的作用。因为算法是选修课程的原因，我并没有选修这们课程。而对于数据结构也并不是非常精通，那么这样对这门课程的学习影响是不是很大呢？是否需要自己去恶补这些内容呢？
回答：在Alpha阶段的过程中，刚好我负责的部分涉及到需要考虑算法的地方，在这过程中确实体会到了好的算法和数据结构在一定程度上影响了整个软件的质量，不过这是基于程序部分的，整体来说用的还是相对比较少的，一个软件的质量好坏与否很大一部分因素还关乎到软件工程，在前期的需求分析，还有用户体验，用户界面设计等都在很大程度上决定了软件的质量。
结对编程让两个人所写的代码不断的处于“复审”的过程，程序员们能够不断地审核，提高设计和编码质量，可以及时发现并解决问题，避免把问题拖到后面的阶段去。
所谓结对编程就是两个人合作，这样可以提高工作效率。但是我的疑惑是，对于我们在校生来说，每个同学的水平参差不齐，并且每个同学所精通的编程语言都不一样。想要找到一个“志同道合”的队友实属不易。如果这样去解决问题，极有可能出现名为结对，实则一个人劳动一个人看戏的局面，这实在有违老师们的初衷。请问有什么方法可以有效解决这个问题呢？
回答：因为一个完整的项目是有许多的认为去做的，所以一个团队的分配非常考究。不同的同学做了自己的强项，他非常愉快，对于整个项目也非常有益。
文学化编程( Literate Programming)
程序员在写程序的时候,要理解在文档中的需求,同时还要在程序里写相关的注释,这些不同目的的“写作”各有价值,但是一旦需求或程序发生变化,这些不同的文档很难保持同步。更不用说程序员最常见的毛病“我以后会加上注释的……” Donald Knuth在20世纪70年代末开始尝试并提倡 Literate Programming的思想并在自己的软件项目中身体力行。这一方法和常见的“写程序,时不时加上一些注释释”相反,它是“写文档,时不时有些代码”。 它使用了宏来进行抽象和信息隐藏。
注释的使用时评价一个程序员好坏的重要指标，而对于有些程序员不写注释或者写出一些没办法理解的注释着实让人头疼。但是，对于文中所说写文档时不时写些代码不是很理解。一个程序的书写需要一定的创作周期，能够按时展示出你的作品仍然是一个最重要的事情。如果把时间全部用在了书写文档上，是不是也会影响创作的效率呢？我的理解是合理的注释是可取的，但不能作为工作的主体，不知道自己是不是太片面，望解惑。
回答：如果是自己做项目的话，基本都知道自己的各种想法，所以随便写一下注释就可以了，但是一个团队，如果你写的东西别人都看不懂，那么会浪费更多的时间。那么写好一个注释就至关重要了，并不是浪费时间哦。
统计数据表明，70%的创新者说，他们最成功的创新，是在他们拿手领域之外发现的。
对于这个统计结果，真的让我不敢相信。超越领域的创新真的会让一些内行人汗颜。我不是很清楚出现这个现象的原因。我的拙见是出事一个领域的人总会有一些固有思维，认为1就是1，2就是2.而其他行业的人不会有这种局限。但是这个结果同样让我产生了一个想法。是不是360行，行行有联系呢。一个领域的东西运用到另外一个领域，这是不是也算一种创新呢？
回答：在编程中，一个功能可能用js,php都可以达到目的，但是对于软件质量和实现难易程度确实不同的。所以，能够创新是需要强大的只是储备的。
另一份任务是，要在么一个任务记载我们完成这个这份任务还需要多长时间
看到这句话，我的心里满是狐疑。对于我自己来说，“还需要多长时间”是一个难题。因为一个模块或者功能的编写总是能够遇到这样或者那样的bug，排除bug所用时间是一个未知数。我总是不知道成功和意外谁先来。我想知道怎样才能精确的算出自己还需要多长时间呢 ？
回答：原来的想法是非常肤浅的，自己写的项目是很容易预想出所需时间的。因为你如果真的都掌握这些知识了，那么写出的时间都会有一个自己的预期。
用户问卷调查
这种方法是向用户提供事先设计好的问题，让用户回答。有时候用户在浏览某个网站时，一个弹窗会弹出来，打断用户的思路，不客气地要求用户回答几个问题。用户在问答这类问题是，是否会心不在焉，乱点一气。
软件团队有各种形式，适用于不同的人员和需求。基于直觉形成的团队模式未必是最合适的。
如果要开展一个全新的项目，到底该怎么选择“合适”的团队模式呢？课本中仅仅是介绍了各种模式，但并未教我们到底该如何选择。
经验公式：实际时间花费主要取决于两个因素——对某件事的估计时间X，以及他做过类似开发工作的次数N。
Y=X±X÷N //注：Y是实际时间花费。
从上述的经验公式可以看出，如果我们之前名没有做过类似的开发工作，那N就是为0，最终的结果实际时间就是无穷。也就是结果是未知的，这不就是算了等于没算吗？对于一个我们没有接触过的开发工作，这个经验公式还适用吗？
用户体验设计的一个重要目的就是要降低用户的认知阻力，即用户对于软件界面的认知和实际结果的差异。
既然用户体验设计的目的就是为了用户，那是不是可以理解为要根据大众的想法来设计？但我们平时使用的一些软件，比如知乎，这些公司对于用户体验设计应该都是很在行的，但为什么在用户体验这一方面会越做越烂呢？ 我的问题是，是什么原因导致了这种情况的发生。每次出新版本，每次都会受到用户的大量吐槽，为何会一直在错的路上一直走下去呢。如果在内容和功能上，加入了可以获利的东西尚可理解，毕竟一个公司都是需要收入的。那么UI越做越丑，怎么就不会改回去呢。
《现代软件工程》采用的“做中学”的教学方法和面向实战、超大量的项目实践给学生带来了明显的帮助,不但让基础好能力强的学生如虎添翼，基础一般的学生更是从中获益......
根据我的实践，合理的理论和实际结合能很好的提高学生水平，尤其在于理工类科目 。但是我觉得超大量的项目实践会让大部分普通的学生感到厌烦，从而丧失学习的乐趣，我认为学习要人有成就感，如果我们在编程的过程中能感受到解决问题的快感，有助于提高学生自信心。那请问作者是怎么看这个“超大量”这个说法的呢？
标签：code 图形 新版本 没有 还需 人工智 避免 不能 原理
原文地址：https://www.cnblogs.com/lsl321/p/9061419.html
