极客时间对于推广渠道会有返利优惠,比如山月在极客时间买了一门课,再把课程分享给好友购买,这时极客时间会向山月返利20元左右。
而我现在做了一个返利平台,你可以在上边通过山月的链接购买课程,此时极客时间会向我返利。为了共同学习,而你可以添加我的微信 (shanyue94),我将把极客时间给我的返利发一个红包全部返给你

date: 2019-08-20 19:00


# 如何能够快速了解新业务

最近接触新业务较多,关于了解新业务有一点感想,总结如下

  1. 比了解新业务代码更重要的是要了解新业务,比了解新业务更重要的是业务意识
  2. 如果是业务开发,毕业前三年更应该关注于技术以及技术细节,三到五年技术业务并重,五年以后业务为主

以下是关于如何快速熟悉新业务的一些经验之谈

本文链接: https://shanyue.tech/post/business-get-started (opens new window)

# 工具

工欲善其事,必先利其器。

# Chrome 多用户模式

方便多个 (大于两个) 用户切换 (管理员/用户/各种角色)

# 业务数据库权限 (生产环境)

最好能够拥有线上数据库权限,拥有最真实的数据,人往往会对不合理假数据本能排斥。

数据库是了解业务最快的方式

# 日志系统 (或者 APM)

在需要了解某个业务细节时,可以利用日志系统

  1. 在前端进行页面交互,找出关键请求
  2. 找出关键请求的 requestId (sessionId/transactionId/logId/trackId 等各种名字)
  3. 根据 requestId 在日志系统(或者 APM) 中找到对应的 SQL/redis-command/requests (主要是 SQL)

至于如何在全链路设置 requestId,可以参考我的这篇文章: 使用 requestId 标记全链路日志 (opens new window)

如果没有 requestId 怎么办?

那只能仔细去看代码了

# 代码仓库

孙子兵法云: 上兵伐谋,其次伐交,其次伐兵,其下攻城。

在熟悉新业务时,最上者点来点去熟悉系统,其次与他人交流,其次点页面查 SQL,最下看代码。

代码以服务器端代码为主,快速浏览以下文件:

  1. router: 用以定位业务细节的具体逻辑
  2. 业务逻辑层: 根据 router 点进来后的具体业务逻辑,由于层层嵌套,可能需要点上几十次。 了解代码的具体组织结构,当有需要时再去深入了解
  3. constant: 了解业务中各种资源的类型,状态,状态机,以及与数据库字段的对应 (数据库可能存储为 enum, 也有可能是 int)。其中代表的数据比这些数据在编码中怎么用更为重要,当然两者紧密相连

关于 constant,最好使用 enum 而非数字维护,参考我的这篇文章: 从数据库到前端,使用 enum 代替 constant number (opens new window)

# 了解业务

# 了解业务类型

你现在负责的业务的用户是谁?

  • 有可能是面向各个离散的无相互关联的C端用户
  • 也有可能是服务于各大企业 (组织/机构) 的 B 端用户。
  • 也有可能是服务于广大公司内同事,比如给运维使用的运维平台,给销售使用的 CRM,给 QA 的测试平台,还有 MIS,OA 等等此类
  • 还有可能是用户服务,订单服务,数据服务,商品服务等

不同的业务类型就有不同的工作重心,比如 toB 庄重,toC 活泼,对内能看就行...

你现在负责的业务如何来钱

这也是一个关键问题

# 了解系统

了解该业务所涉及到的核心系统,与业务类型相关。我简单分为两类

  • 前台系统:面向用户,toC 面向广大用户,toB 面向企业与企业员工,toB 面向使用者
  • 后台系统:面向管理员,就是常说的后台管理系统

# 熟悉系统主要流程并实操

了解用户的高频操作,主要途径点点点和不懂就问。有些高频操作,需要后台管理员以及各个角色配合, 这时可以在多用户的 Chrome 中进行操作

  • 比如知乎的提问,答题,评论,点赞到后台的帖子管理封禁等
  • OA 系统的流程发起,以及各个角色的审批
  • CRM 的商机,订单,工单操作

# 了解系统边界

由于微服务的流行,新业务的所有数据有可能来自于基础服务。在熟悉业务过程中,有必要了解哪些数据自己维护,哪些维护在公有服务

  • 用户数据由业务内维护还是用户服务
  • 订单数据由业务内维护还是订单服务
  • 诸如此类

# 了解边界系统

即以上所述的用户服务系统或者订单服务系统。了解常用的表,有必要时可以申请数据库权限

# 了解用户以及权限 (用户/管理员/角色/企业)

了解业务内有什么权限,以及每个权限组成的角色。

可以模糊分为以下几个表,需要重点关注

  1. permission: 权限表
  2. role: 角色表
  3. user: 用户表
  4. organization: 企业/机构表

另外还需要了解用户登录以及注册过程,有没有第三方登录,以及 toB 方的自家用户系统的接入

# 了解数据

比如何查 SQL 更重要的是数据本身,有必要时可以记住,比如

  1. 大客户 id 以及 name
  2. 深度用户的 id 以及 name
  3. 主要资源/内容的 id
  4. 主要资源/内容的 status/type (参照 enum/constant 文件)

以下是常见的一些数据以及 SQL 操作,主要针对一些常量与主要业务

-- 了解用户量,必要时可以记住...
select count(*) from users wehre is_deleted = false

-- 了解某项业务的字段
\d business
select * from business order by id limit 1

-- 了解目前为止该业务有多少量数据
select count(*) from business

-- 了解某项业务的各个状态,以及分布
select status, count(*) from business group by status order by count desc

-- 了解某项业务的各个类型,以及分布
select type, count(*) from business group by type order by count desc

# 数据系统

如果对系统接入了 GA/神策/GrowingIO 等数据统计系统,进入系统了解并记住重要数据,了解用户对系统的使用深度以及常见业务的使用情况。

如果没有接入数据系统怎么办? 参考上一条,手动查 SQL

关于山月

我的项目:
我的微信:shanyue94,欢迎交流
Last Updated: 7/21/2019, 11:25:08 AM