浅谈需求分析和架构设计

quote

Goal is not always meant to be reached, it often serves simplyas something to aim at. 

Bruce Lee

脱离业务的架构就是耍流氓。架构师必须要深入理解需求、参与需求、看透需求背后的业务本质。

需求分析

从下面公司的产品研发图,可以明确需求分析所处位置。

从一道面试题开始

你作为前端负责人,来开发一个 h5 页,某个抽奖功能的运营活动,如上图。 假定 PM 和后端 RD 都是实习生,技术和业务都不熟练。你要从 0 开发这个页面,你会要求 server 端给你哪些接口和能力?

多数人的答案

  • 所有人都能想到,需要一个抽奖接口。否则,他就不是一个合格的程序员了。
  • 很少一部分人能想到,需要一个用户信息接口,否则都不知道奖品给谁,总得登录一下。或者直接输入手机号抽奖也行,但需求没说这里有手机号。
  • 还有,加入刚刚抽了奖,再重新进入界面,是否要禁用抽奖?是否要限制每个人抽奖一次?—— 这些需求没说,但这些很重要,这些可都需要后端支持。

我预期的答案

  • 获取用户信息(同时判断是否登录)
  • 如果登录,判断该用户是否已经抽奖,以判断他是否还能继续抽奖。
  • 抽奖接口

    • 可能还需要调用登录接口
    • 当然也可以直接输入手机号抽奖,需明确需求
  • 埋点统计

    • pv
    • 自定义事件
  • 微信分享

下面是整体思路的手稿

由此想到的

这个面试题不是考察知识点和技术能力的,完全就是在考察你对一个业务的理解能力。由此你就可以看出,程序员对于需求和业务理解能力有多么重要!直接会影响到你的 API 接口设计,进而影响到你的开发。有些时候,PM 和 RD 比较靠谱,他们能考虑清楚整个流程,你也就顺利的完成了,这很幸运。但大部分情况下,你都会遇到一些不靠谱的人,或者太忙没空理你的人。这个时候就要靠你去承担起来,而你有没有这种能力呢?

架构设计

任何看似复杂的设计,都是让整个系统变的更简单

“很多程序员学了大量的算法和计算机基础,然而在工作中却派不上用场。这是非常正常的,因为这些内容是为了在科学领域做研究准备的。而在业务领域,大多是如何把现有业务在软件中模拟出来的问题,并没有太高深的数学问题。并且现在的计算机硬件,比如 CPU、内存、存储都很便宜,也不需要斤斤计较的去抠空间和时间复杂度。这些都导致所学不能致用。反而如何能够高效的把业务用软件表达出来,并能够随着业务的增长,让软件也快速长大,则变成了一个更重要的问题。这一点可能是当前计算机软件教育需要思考的问题。” —— 《聊聊架构》

确定需要创建的项目

  • 先不看细节,看整体,这一步就是确定项目的范围。确定范围是做任何事情的第一步。
  • 范围确定好了,剩下的事情,即便有问题,也属于“人民内部矛盾”。该购买第三方服务,还是该自研,或者该放弃,就看实际情况了。

必须十分清楚各个项目之间的关系

注意数据结构的设计

  • 规范一致性
  • 提效开发,更易于维护
  • 留有可扩展空间

但是千万不要扣细节,以及拿现在的代码实例和接下来前端开发的代码进行对比!!!否则你就是自讨苦吃。

写技术方案设计文档

写设计文档是浪费时间吗?

  • 如果你真的想明白了,最多浪费你 1-2h 时间,不会导致项目延期。
  • 如果你写不出来,说明你没想明白,正好暴露了问题。

技巧

  • 随性一些,解释一下你要如何做,即可。
  • 可以先尝试写一部分代码,捋一捋思路,再来写文档。

文档目录

  • 需求背景:把需求文档贴上
  • 范围:整体设计,没有细节
  • 模块设计

    • 模块拆分和关系图
    • 各个模块的功能解释
    • 特殊模块说明:组件库、统计服务
  • 核心数据结构设计
  • 扩展性保证

    • 扩展组件
    • 扩展编辑器功能,如锁定、隐藏
    • 扩展页面信息,如增加多语言
    • 扩展其他功能,如大数据分析和计算等
  • 研发提效

    • 脚手架:创建发布
    • 组件平台
  • 运维保障

    • 线上服务和运维服务
    • 安全
    • 监控和报警
    • 服务扩展性:基于云服务,可以随时扩展机器和配置

评论没有加载,检查你的局域网

Cannot load comments. Check you network.

eat();

sleep();

code();

repeat();