1. 什么是设计模式？
    设计模式是指在软件开发中，经过验证的，用于解决在特定环境下、重复出现的、特定问题的解决方案。
2. 说出你所知道的设计模式？
    简单工厂，外观模式，适配器模式，单例模式，工厂方法模式，抽象工厂模式，生成器模式，原型模式，中介者模式，代理模式，观察者模式，命令模式，迭代器模式，组合模式，模板方法模式，策略模式，状态模式，备忘录模式，享元模式，解释器模式，装饰模式，职责链模式，桥接模式，访问者模式。
3. 接口是用来干什么的？
    通常用接口来定义实现类的外观，也就是实现类的行为定义，用来约束实现类的行为。
4. 使用接口的好处
    由于外部调用和内部实现被接口隔离开了，那么只要接口不变，内部实现的变化就不会影响到外部应用，从而使得系统更灵活，具有更好的扩展性和可维护性
5. 什么是OOP？OOP有什么特性?使用OOP用什么好处？
    oop 是面向对象编程,面向对象编程是一种计算机编程架构,OOP 的一条基本原则是计算机程序是由单个能够起到子程序作用的单元或对象组、合而成。好处是易用性、质量高、效率高，易扩展。
6. 为什么类要高内聚低耦合？
    目的是使程序模块的可重用性、移植性大大增强。
7. 类的核心特性有哪些？
    封装、继承和多态。
8. 说一下http状态码 200，403，404，500分别是什么意思？
    200，请求成功；403，服务器接收到请求但拒绝执行；404，没有到被请求资源；500，服务器内部错误。
9. 什么是MVC框架？nginx和网关怎么配合使用
    MVC开始是存在于桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。
10. 简单说下数据库优化的思路。
    SQL语句优化；索引优化；数据库结构优化；服务器优化。
11. 什么事存储过程？
    存储过程是用户自定义一系列 SQL 语句的集合,以一个名称存储并作为一个单元处理。
12. 是否了解微服务构架模式？请简单描述一下。
（1）将应用程序分解成一套较小的互连服务。
（2）一个服务通常实现了一组不同的特性或功能，每一个微服务都是一个迷你应用。
（3）一些微服务会暴露一个供其他微服务或应用客户端消费的 API。另一些其他微服务可能实现了一个 web UI。
13. 微服务构架模式的优缺点？
优点：（1）它解决了复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务。虽然功能数量不变，但是应用程序已经被分解成可管理的块或者服务。使用微服务架构模式，
个体服务能被更快地开发，并更容易理解与维护。
（2）这种架构使得每个服务都可以由一个团队独立专注开发。开发者可以自由选择任何符合服务 API 契约的技术。
（3）微服务架构模式可以实现每一个微服务独立部署。微服务架构模式使得每个服务能够独立扩展。您可以仅部署满足每个服务的容量和可用性约束的实例数目。
缺点：（1）由于微服务是一个分布式系统， 这种方式使得整体变得复杂。开发者需要选择和实现基于消息或者 RPC 的进程间通信机制。此外，由于目标请求可能很慢或者不可用，他们必须要编写代码来处理局部故障。
（2）测试微服务应用程序也很复杂。往往需要启动所有相互依赖的微服务。
（3）跨越多服务变更也很繁琐，在微服务中您需要仔细规划和协调出现的变更至每个服务。例如，您需要更新服务 C，然后更新服务 B，最后更新服务 A。幸运的是，大多数时间变更只会影响一个服务。
（4）要成功部署微服务应用程序，需要求开发人员能高度控制部署方式和高度自动化。
14. 举一个微服务构架的例子？
例如，以我们的出租车为例，一个是乘客的应用，一个是司机的应用。这使得它更容易地为特定的用户、司机、设备或者专门的用例部署不同的场景。
每个后端服务暴露一个 REST API，大部分服务消费的 API 由其他服务提供。例如， Driver Management 使用了 Notification 服务器来通知一个可用司机一个可选路程。 UI 服务调用了其他服务来渲染页面。服务也可以使用异步、基于消息的通信。一些 REST API 也暴露给移动端应用以供司机和乘客使用。然而，应用不能直接访问后端服务。相反，他们之间的通信是由一个称为 API 网关（API Gateway）的中介负责。 API 网关负责负载均衡、缓存、访问控制、 API 计量和监控， 可以通过使用 NGINX来实现。
15. 何为代码重构？说说自己的理解。
代码重构即对软件内部结构的一种调整，在不改变软件可观察行为的前提下，提高代码可理解性，降低其修改成本。
16. 代码重构的目的？
（1）重构改进软件设计。
（2）重构使软件更容易理解。
（3）重构帮助到bug。
（4）重构提高编程速度。
17. 何时才是代码重构的最佳时机？
（1）三次法则：第一次做一个功能，只管去做；第二次做类似的事情感到反感，但无论如何还是可以去做；第三次再做类似的事情，你就应该开始进行代码重构。
（2）添加功能时重构：原来的代码设计无法很好的支持我新添加的功能。
（3）修补错误时重构：原来的代码出现bug，重构可以轻松解决。
（4）复审代码时重构：审查之前代码，发现过时的编码和架构，新的架构和代码可以更好更简单的完成之前的功能。
18. 重构的困难点在哪里？
（1）数据库
（2）修改接口
（3）难以通过重构完成的设计改动。
19. 什么时候不应该重构？
（1）重构会导致现有代码无法正常运作。
（2）项目已经临近最后期限，没有时间重构。
20. 是否了解敏捷开发的原则？并简单解释一下。
（1）递增，而不是连续的：交付的工作软件是一小部分一小部分递增的，可以并行开发，不必等到一个阶段完全完成后才开始另一个。
（2）避免不必要的开销：尽可能多地减少项目计划和文档。
（3）协作：整个开发团队必须是相互信任并相互协作的。
（4）说真话：为了保证真正的敏捷，团队探讨的与项目相关的一切都要是真实的。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。