一、团队介绍
壹宝技术团队的规模日渐强大，按职责划分为 研发、测试、运维三个小团队。
1.1 研发
开发团队是技术团队中最大的一个团体，分为 前端团队和 后端团队
1.2.1 前端
前端团队分为 Web 端和 客户端：
- 其中 Web 端组长是
朱鹏程，组员有王吉、庄前前、郑东旭、徐良成、杨硕 - 客户端暂时有且仅有一人：
王众
1.2.2 后端
后端团队分为 A 组和 B 组：
- 其中 A 组组长是
金聪，组员有冯源和任东阳； - B 组组长
林剑，组员有吕兆栓、李晓宇、刘文义。
1.2 测试
测试团队中，胡雷为组长，其组员有 贺玉菊、张凯丽和 余铮卓
1.3 运维
运维团队是整个技术团队的脊柱。其工作职责贯穿每一个技术团队成员的工作内容，暂时有且仅有一人：郭君。
二、壹宝应用系统
在既往的工作过程中，技术团队为壹宝沉淀了很多有价值功能，这其中大家耳熟能详的有：自定义页面、服务报告、健康任务、IM聊天等。而这些功能都分布在不同的系统中，不同的系统之间又有着千丝万缕的关联。下面让我们给大家介绍一下壹宝现在所拥有的系统，按职能划分为两大类：
2.1 运营平台
壹宝 YIBAO（预约服务、支付订单、查看报告、完成健康任务等）儿童患友之家（预约服务、支付订单、查看报告、完成健康任务等）17 健康（看病攻略、我的治疗、个人中心、预约服务等）
2.2 服务平台
上患者（添加患者、和患者进行在线沟通、给患者添加就诊记录等）随访中心（在线沟通、创建单次服务、添加就诊记录等）运营管理后台（服务管理、文章管理、订单管理、服务实施等）
2.3 数据平台（筹备中）
数据中心（日志统计）数据仓库（项目库、主题库）
三、我们的工作
3.1 协作工具
Confluence（文档管理）禅道（项目管理）GitLab（代码版本控制）SonarQube（代码质量管理）Jenkins（项目部署）壹宝大学（团队学习）Seja（接口文档）- …
3.2 工作流程
技术团队一般的工作流程如图所示：
以上是一个完整的产品迭代计划，大家各司其职确保项目如期上线。
开发任务
项目计划
| 项目名称 | 产品负责人 | 设计负责人 | 业务负责人 | 产品内审 | 开发评审 | 设计评审 | 技术负责人 | 测试用例评审 | 提测时间 | 上线时间 |
|---|---|---|---|---|---|---|---|---|---|---|
| 数据抽取 | 吕能 | 茄子 | 周嘉旻 | 0906 | 0910 | 0916 | 林剑 | 0919 | 0925 | 1010 |
测试用例
接口文档
代码实现
3.3 工作内容
技术团队的工作内容大抵分为两大类：日常维护 和 需求迭代。其中日常维护主要是解决线上出现的一些问题，如线上 Bug 修复、线上功能小优化、线上文案修改等针对线上进行的一些开发工作；而需求迭代则是对「需求」来进行的项目级开发工作，通常涉及到比较大的业务新增或改动、需要多端配合等，如服务实施、数据抽取、17健康等。
下面主要介绍一下这两大类工作内容的一些特性和其典型案例，让大家对技术团队的工作内容有一个更具体的认知和了解。
3.3.1 日常维护
日常维护主要体现在「维护」两个字上（并不是日常），所谓「日常维护」就是平日工作过程中，线上可能会出现一些异常问题或者不合时宜的功能、文案，这时候就需要有人去把这个问题解决掉，而对线上问题的修改通常叫做「维护」。
我们来举两个日常维护的例子：
日常1：190806日常【患者端】— 患者报道年龄选择优化
业务背景：（顺带）
患者报道年龄填写操作很复杂（尤其是成年患者），操作费时间，需要优化（目前是选择年月日）
产品解决方案：（王众）
- 出生日期的滚轮选择的默认年份修改；
- 耳鼻喉公众号 默认日期保持为今日不变；
- 甲状腺公众号 默认日期修改为 1980-06-15 ；（取中间值，方便甲状腺患者选择）
日常维护工作内容
- 明确职责范围：前端 Web 端
- 具体到开发人员： C 端开发，杨硕
- 开发（杨硕）-> 测试（张凯丽）-> 上线（杨硕）-> 回归（张凯丽）-> 验证（王众、顺带）
日常2：190822日常【多平台】— 顾问下班后系统自动回复过滤系统消息
业务背景：（顺带）
顾问下班后，患者发送系统消息给顾问，也会给患者发送一条自动回复消息，没有必要。
产品解决方案：（黄珏）
顾问下班后的系统回复消息“你好，我已收到你的问题…”，该消息发送前 需要判断 患者发送的消息是否是系统自动推送的消息，如果是系统推送的消息，无需发送该自动回复消息;
系统需要对哪些消息类型是由系统发送的进行标记区分，对于之前的消息哪些是系统发送的，已标记在 消息推送-im消息卡片 是否系统发送
日常维护工作内容
- 明确职责范围：服务端B组
- 具体到开发人员： IM通信相关，林剑
- 开发（林剑）-> 测试（张凯丽）-> 上线（林剑）-> 回归（张凯丽）-> 验证（黄珏、顺带）
以上就是技术团队维护过的两个日常维护需求，大家可以看到一些它们的特性，如：线上问题、问题修复规模小、开发人员涉及少等。符合这些特性的都可以称之为日常维护。
然而，理想丰满现实很骨干，在大部分情况下，上述的这些日常维护并不会单独进行维护开发，而是由产品经理将其汇总，待其数量和工作内容足够多的时候才会提交至开发团队一并开发，其主要原因有二：
- 开发团队整体正在开发「需求迭代」级代码，「需求迭代」的开发内容通常涉及到很多的业务逻辑和技术实现（尤其是新增业务逻辑），一旦打断其开发节奏再回过头来开发需要浪费相当大的时间和精力；
- 「需求迭代」通常都是紧急的、战略级的，时间倒排，在考虑优先级的情况下，一般优先级的日常维护需求需要在需求迭代开发完成之后才能进入开发。
3.3.2 需求迭代
考虑到公司现状，我们公司还处于创业阶段，创业意味着创造、创新和探索。因此在这过程中会产出一些规模比较大的、业务涉及比较广且深的产品需求，这些需求的特性就是「大」：业务大、功能大、产品大，因此就会涉及到多团队多端多人同时进入开发工作，因此优先级相对也是最高的。
这边列举一个壹宝史上最大的「需求迭代」—『重构』！
小声BB：仔细想想算了，重构太大了，讲到明年也讲不完，还是来个相对简单且独立的
登录吧 o(￣︶￣)o
在这里以 登录为例来向大家介绍一下技术团队在开发过程中的一些实现逻辑。
3.4 工作举例 - 登录
概述
「登录」是指进入操作系统或者应用程序的过程。大家在日常生活中会经常遇到，不管是 APP 还是 Web 网站都需要「登录」来 验证操作人的合法性。
- 在我们公司的内部系统中同样存在「登录」功能，在重构前期因为时间关系，一开始是在前端写死账号密码的方式达到验证目的，而后在今年一月份由产品经理产出一套相对完善的产品方案再进行迭代。
功能说明
「登录」有很多种不同的产品形式，包括但不限于：
- 账号密码登录
- 手机验证码登录
- 第三方平台登录（微信、支付宝等）
就拿最简单的账号密码登录来说，从前端交互上来看，「登录」仅仅是用户填写账号密码后点击按钮的一个操作过程而已。
然而其背后牵扯到一系列关联因素，比如账号、菜单、权限等。这些因素决定了登录成功后用户能看到哪些内容，能进行哪些操作。也就是说「登录」一般并不会单独存在，而是和其他因素相辅相成。
简单实现
下图展示了一个简单的登录逻辑图：
从「用户登录」到「登录成功」中间经历了几步合法性校验。最终生成 token 返回给前端，之后每次用户操作时前端会携带 token 访问后端接口，后端收到请求后会验证 token 是否有效，验证通过后返回前端相应数据。
此外，还涉及菜单、权限的判断及展示，这里不展开。
扩展
防止人为暴力破解
虽然我们在上面已经实现了「登录」功能，但是安全方面却还不够。如果有人发起恶意攻击，不断的换密码尝试登录，放任不管的话很可能会被破解。
常见的预防手段包括但不限于以下几种：
- 增加验证码（图片 or 短信）
- 限制密码输入次数，达到一定量后锁定账号，一定时间后自动解锁
- 限制内网访问
互斥登录 or 多端登录
互斥登录就好比我们的随访中心和上患者，只要有一端登录了，另一端就会被踢出。- 而
多端登录就好比微信在手机端跟电脑端可以同时登录，需要额外判断一些逻辑。
单点登录
单点登录 是目前比较流行的企业业务整合的解决方案之一。它是指在多个系统中用户只需要登录一次就可以访问所有互相信任的系统。
试想一下，如果未来我们公司内部有几十个应用系统，每个系统都需要单独登录，那会让人崩溃的。所幸我们现在系统少，且业务人员职能相对独立，同一人操作不同应用系统的可能性比较低。
一种比较简单的解决方案是将所有应用系统分配到同一个顶级域名下，如我们的 120yibao.com。用户登录后将上面提到的 token 放入 cookie 中，cookie 的路径设置为顶级域名下，这样该顶级域名下的所有子域名都能读取到 cookie 中的 token，从而实现单点登录。
3.5 工作成果
去年 10 月份开始我们逐步进入重构，截止到今年 5 月份重构正式上线，在此期间我们根据业务系统 四个端拆分为 十个前端项目及 六个后端应用支撑。