Java企业级面试题总结-3

*需求分析

你如何对需求原型进行理解和拆分

产品策划、产品功能调研、绘制流程图和原型图、搜集产品部门内部意见、UI设计、研发评审、测试评审、研发阶段、测试阶段、上线

说说你对功能性需求的理解

用户需求

是从某一类用户的视角看他使用这个软件的需求。比如，作为用户你用淘宝，找东西，拍货，付款，你有怎样的需求。作为卖家，你用淘宝怎么收款，发货，管理订单。这就是一个个的 use case 或者 user story。 所以写 user story ， 开头第一句就是 As a xxx. 这都是从个人视角去看需求的。

业务需求

你整理完不同视角的需求，就要一个更高层面，更全局话的角度看需求。就要把这些需求串联起来。特别是把全局的流程梳理出来。从个人角度，是看不到全局的流程的。但是要想把业务梳理清楚，特别是数据流。就需要这种全局视角下的梳理。我们才清楚 use case/user story 是在什么场景下。 特别是有时候，不同的用户的需求可能存在冲突。通过这种全局性的业务需求梳理，可以去发现潜在冲突，并平衡需求。

功能需求

就是把具体的用户需求，变成软件的功能要求。比如客户要把交通事故照片通过 APP 发给保险公司。这是用户需求。 那么功能需求就是在这个模块下，要具有提交报险事故照片功能，上传现场照片。如果再具体下去，就是界面交互图。现在互联网公司一提产品管理，需求设计，基本就是 UX。需求过于碎片化。

说说你对非功能性需求的理解

非功能性需求是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求。包括安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性。

你针对产品提出哪些交互和改进意见

过度追求精准

死板遵循设计法则

过度假设用户行为

你如何理解用户痛点

我们平常在做产品的时候，我们用户提出一个需求，他们想要一个直播功能，在用户提出这个需求的时候我们分析的是用户为什么想要直播这个功能，我们分析的正是用户的痛点。那么什么是痛点，痛点就是我们用户急切想要做的事。

​ 比如我们产品做的是一个电商平台，我们通过几次渠道运营或者营销推广以后，吸引进来的用户大多都会搜索母婴相关的产品，但因为平台没有母婴相关的产品，吸引进来的用户大多都因此流失，其实我们吸引进来的大多用户都希望在本平台能买到母婴产品，但我们平台却没有相关的产品，这就是我们用户的痛点，所以我们赶快要上新跟母婴相关的产品。

​ 再比如我们做的是健身方面的产品，在我们的产品里面有活动、动作库、健身计划、健身操、健身饮食五个模块，但我们70%以上的用户每当打开APP的时候都会点开动作库模块，但我们的动作库模块却放在了不太方便用户操作的地方，发现这个情况以后，我们分析到我们用户使用我们APP的痛点其实就是想学习健身动作，那我们就要将动作库这个模块当做为我们产品的重点来打造，对里面的内容也需要做更优质的优化。

设计能力

说说你在项目中使用过的 UML 图

你如何考虑组件化

组件化就是基于可重用的目的，将一个大的软件系统按照分离关注点的形式，拆分成多个独立的组件，主要目的就是 减少耦合。

一个独立的组件可以是一个软件包、WEB 服务、WEB 资源或者是封装了一些函数的模块。这样，独立出来的组件可以单独维护和升级而不会影响到其他的组件。

你如何考虑服务化

集中式与分布式

要谈微服务，那么必须建立在分布式的基础上，对于一个集中式系统也无需谈微服务。

集中式

集中式系统用一句话概括就是：一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行。

集中式系统的最大的特点就是部署结构非常简单，底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署，也就不用考虑各节点之间的分布式协作问题。但是，由于采用单机部署。很可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。

分布式

分布式就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。

拿电商网站来说，我们一般把一个电商网站横向拆分成商品模块、订单模块、购物车模块、消息模块、支付模块等。然后我们把不同的模块部署到不同的机器上，各个模块之间通过远程服务调用(RPC)等方式进行通信。以一个分布式的系统对外提供服务。

服务化

提到分布式，一个不得不提的词就是服务化，服务化架构使搭建分布式系统成为了可能。

传统的软件开发面临着很多的问题，比如： 代码重复率高、代码庞大难以维护、无法快速迭代、测试成本高、可伸缩性差、可靠性差、模块间高度依赖。为了解决上面这些问题，我们一般采用拆分、解耦、分层、独立等方式来解决。有了服务化架构，我们就可以在很大程度上解决这些问题。

服务化是一种粗粒度、松耦合的以服务为中心的架构，服务之间通过定义明确的协议和接口进行通信。

这里说到的“服务”，本质上来说，就是指“RPC”。单纯的RPC功能实现，其实很简单，无非就是client发起调用，中间某个组件（甚至就是client本身）拦截调用信息，序列化后将信息传输到server端，server端收到调用请求后反序列化，根据请求详细发起实际调用后返回响应传输回给client端。这样的RPC很常见，比如常见的存储过程调用就是一例。但是在一个复杂的业务环境，如何管理和协同这些大量的RPC才是最麻烦的事情。所以，一般提到的“服务化”更多指的是对RPC的管理。服务化一般关注服务注册，服务协调，服务可用性，服务通讯协议和内容交换等。

说说概要设计

概要设计是一个设计师根据用户交互过程和用户需求来形成交互框架和视觉框架的过程&