北森项目经历

开发流程

2 个月为一个周期：

需求宣讲 => 需求分析 => 需求反讲 => 方案设计 => 方案评审 => 开发 => 需求提测 => 测试 => 上线

假勤管理系统

假勤管理系统
负责北森假勤系统的日常维护和需求开发：定位并解决线上问题，独立完成迭代任务分解和技术方案设计。根据产品经理调研结果，结合交互设计师要求，分析客户在使用中的痛点，主导对排班管理和考勤文员工作台等重要产品进行优化，完成列表中列展开收起等功能，为客户提供极致的使用体验，获得客户好评。

我在简历中写了以上内容，面试官可能会问我哪些问题？我应该怎样回答？

系统介绍

假勤系统主要用于企业内部考勤打卡、排班管理、加班、请假、出差、公休、支援等管理，帮助 HR 和员工高效处理日常考勤相关的事务。假勤系统是北森 iTalent 平台的最重要的模块之一，是客户使用频率最高的模块之一，客户对功能稳定性和交互体验性的要求都很高。

具体职责

• 日常维护：处理线上 bug，确保系统稳定
• 需求开发：独立完成需求分析、任务拆解、技术方案设计和实现。比如主导了对排班管理和考勤文员工作台的优化

如何快速熟悉并处理业务

我一般会分三个模块熟悉业务：

第一，先通过产品文档、需求说明、问产品经理/业务同事、自己用 Demo 系统操作，理解系统的目标用户和核心流程，建立对业务场景的感知；
第二，结合代码和接口文档去对照业务逻辑，尤其关注入口模块、数据流和核心状态管理；
第三，尽快通过修复小 Bug 或开发小功能进入实践，把理解落地并和产品经理、测试确认，确保自己的理解和业务真实需求一致。

最后，我会把关键的业务流程和模块总结下来，方便自己和团队后续复用。这样一般用一周就能进入业务节奏。

任务拆解、技术方案设计

• 先和产品、设计确认需求边界和验收标准，确保完全理解需求目标
• 然后从前端角度把需求拆成页面、组件、数据流和接口调用等模块
• 再把每个模块细化成可执行的开发任务和更细粒度的子任务
• 然后通过自测 demo 来评估技术可行性，是否依赖第三方、是否有风险、对现有功能的影响
• 最后保证每个任务的粒度适中、时间可控（单任务不超过 8 小时）

排班管理

排班管理主要是给团队管理者使用的，给劳动力进行班次的查看与设置，主要是进行了一些界面样式的优化，包括展示哪些班次信息、怎样展示开始时间和结束时间、颜色的调整、hover 时高亮显示、用户设置的记忆（筛选条件、列表的间隔）等。

考勤文员工作台-列展开收起

列的折叠收起是给考勤文员工作台中的列表新增的功能。考勤文员工作台是给 HR、考勤专员、团队管理者使用的，可以从日、月两个时间维度查看员工的考勤数据，在月视图列表，行是员工的姓名，列是各种维度的考勤状态。在此前，列完全按照 1 号列到 31 号列的顺序平铺展示考勤数据，无法展开收起，导致列数很多（天数就 30 多列，整体有 40-50 列），且这些日期列默认排序在总列数中间，操作时想看首尾列需要频繁滚动列表到最前最后，使用体验不佳。

S（Situation）场景
在考勤文员工作台中，月视图的考勤数据表格有 40-50 列，其中日期列有 31 列，是平铺展示，导致用户操作时需要频繁横向滚动，效率低下，体验很差。

产品经理调研发现此问题后，和设计师讨论，最终确定了新的展示和交互形式：每次都默认将这 31 列先合并为 1 列，此时该列不展示数据，只显示这里是某月的日历日期列，然后在该列的右侧显示一个展开按钮，点击展开按钮后，列再按照 1 号列到 31 号列的顺序平铺展示考勤数据。平铺展示后，日期末列都有收起按钮，而且当在日期列的中间看不到日期末列时，收起按钮需“附着”在列表的最右侧，方便用户随时收起这些日期列。算上左侧和左侧的冻结列，这个方案被称为“三折叠”。

T（Task）任务
产品和设计希望我实现一个可折叠收起的日期列展示方式：默认收起，仅展示一个日期列提示，点击展开后再显示 31 列完整数据，并且收起按钮要始终方便用户点击。

针对这种特殊的交互场景，采取了在渲染日期列时，同时渲染展开收起按钮的方案，不改动基础列表组件。展开收起的设置也放在列表之外，默认收起日期列。当收起时，给列表组件传元数据时，前端进行过滤，把除了 1 号列的日期列都设置为隐藏，同时 1 号列只展示提示文案（不会渲染具体数据），且在右侧添加展开按钮；当展开时，日期列都正常展示，日期末列在其左侧添加收起按钮，因为列表组件是虚拟列表，如果没有末列，无法以粘性定位方式始终展示末列的收起按钮，所以只能实时监听横向滚动位置，如果未滚动到末列，则在列表的最右侧再添加一个同样的收起按钮，这两个收起按钮交替显示。此外，因为要求按钮始终在列表的最中间，而且列表组件是虚拟列表，所以还要实时监听竖向滚动位置，判断当前行是中间的行再显示按钮，否则隐藏当前行按钮。同时还注意，每次点击完按钮后，要处理按钮的隐藏和显示，防止出现多个按钮。

A（Action）行动
我没有直接改动底层列表组件，而是在外层通过控制元数据渲染来实现列的隐藏与展开，保证了兼容性和可维护性。
处理了虚拟列表带来的问题，比如末列收起按钮无法固定在最右侧，我通过监听横向滚动，在最右侧额外渲染一个收起按钮来解决。
为了保证按钮始终出现在可见区域的中间，我还实现了竖向滚动监听，让收起按钮只在中间行显示，避免多按钮冲突。

R（Result）结果
最终实现了交互体验优化，用户可以快速展开和收起日期列，大幅减少了横向滚动的操作成本。该功能上线后，收到了客户的表扬信。

排查线上问题

• 先确定影响：该问题影响用户使用哪些业务，影响哪些使用，确定重要性
• 再排查解决思考 bug 的解决方案：先从自己代码入手，再深入下挖底层代码
• 最后找到原因后，跟产品确认，是不是问题，怎样解决，何时解决，要不要 fix

测试同学在线上环境使用时，发现时间选择组件只能选时无法选分，认为是异常便提出了疑问。随后经过排除代码以及跟产品确认，发现这是产品设定的要求。

鸿蒙 NEXT 北森 App

鸿蒙 NEXT 北森 App
在移动端开发人员紧缺的情况下，从 0 开始快速学习鸿蒙 NEXT 系统移动端 App 的开发，参与北森 iTalent App 鸿蒙 NEXT 系统的签到模块，包括蓝牙签到、WiFi 签到、GPS 签到、弱网签到等功能，配合完成了北森 iTalent 作为首批适配华为鸿蒙 NEXT 系统 App 的目标。

我在简历中写了以上内容，面试官可能会问我哪些问题？我应该怎样回答？

简单介绍

这是去年 7 月接到的开发任务，要求 9 月底，共 3 个月完成 App 开发。因为本来不是移动端方向，对移动端不是特别擅长，所以我在这个项目主要是一个普通的开发人员的角色，后期还承担了少量的测试任务。此项目是以现有的 Android 和 iOS 系统的产品形态（包括功能和交互）为标准来开发。

当时前端负责这个 App 的有我和另外四位同事，一位 leader，一位 Android 开发，一位 iOS 开发，一位高级前端开发。高级前端开发做底层性的工作，包括开发 jsbridge、封装基础请求类、一些基础组件等。两位移动端开发根据各端的代码来解释打卡签到业务，我们一起配合来完成签到模块功能。其余别的模块都是直接 H5 嵌套，没有用原生实现。没有专门的后端开发人员，直接使用现有接口。测试同学使用现有的测试用例。但由于是首批适配，测试同学对鸿蒙环境也不熟，我还协助测试同事搭建测试环境和理解功能，最后按时完成了整体流程。

其中，签到的方式有 WiFi 签到、GPS 签到、蓝牙签到等，以及弱网签到兜底等功能。WiFi 签到基于公司 HR 在后台设置的 WiFi 的 ssid 信息、mac 地址和 ip 地址跟当前已连接 WiFi 进行对比匹配；GPS 签到基于公司 HR 在后台设置的签到地点经纬度跟当前定位位置经纬度进行对比匹配；蓝牙签到基于公司 HR 在后台设置的蓝牙 beacon 协议的 major 和 minor 值跟附近的蓝牙设备进行对比匹配；弱网签到是指，在签到时如果北森服务器出现宕机无法签到成功，会在 App 本地数据库保存签到信息以及向备用的阿里云服务器签到，之后，阿里云服务器会定时向北森服务器推送数据，App 也会在每次被打开时向北森服务器进行签到，直到签到成功。

网络信息用 ArkTS @ohos.net.connection 模块；WiFi 信息用 ArkTS @ohos.wifiManager 模块和用 ohos.permission.GET_WIFI_PEERS_MAC 权限；位置信息用 ArkTS @ohos.geoLocationManager 模块；蓝牙信息用 ArkTS @ohos.bluetooth.connection 模块；App 本地保存签到信息用 ArkTS @ohos.data.relationalStore 关系型数据库（基于 SQLite 组件、使用 SQL 语句）。

如何快速上手

首先是环境的搭建。下载鸿蒙官方的 DevEco Studio 编辑器和配置相关开发环境，以及使用华为官方提供的 mate X5 和 mate 60 测试样机。

之后阅读华为开发者官网的 ArkTS 语言指南、ArkUI 框架等核心文档，发现和 Web 前端的语法基本无差后便放弃了通读，集中精力查看如果使用官方组件和查看已有的项目代码，之后便开始直接投入开发，遇到问题现学先用以提高效率，重点研究对应的 API 调用和权限申请流程。ArkTS 和 TS 基本无差、ArkUI 和 CSS 基本无差，最大的差别就是用 ArkUI 设置样式时需要以链式调用的方式来设置。以及也都是用 Charles 代理进行抓包，所以总的来说和 Web 开发没有太大的区别。

先写一些页面以熟悉开发，然后开始开发签到功能，最后还帮助测试同学完成了一些模块测试。

签到方式选择

根据公司 HR 在后台设置的可签到方式来签到。

Wi-Fi 签到：通过扫描周围的 Wi-Fi 热点 SSID 列表进行定位。精度尚可（通常 10-20 米），室内效果好于 GPS。缺点是需要用户开启 Wi-Fi 扫描，并且在 Wi-Fi 热点稀少的地区效果差。

GPS 签到：精度最高（可达米级），适用于户外或范围极大的园区。缺点是耗电高，在室内或高楼林立区域信号差，首次定位慢（TTFF）。

蓝牙签到：精度高（1-5 米），功耗极低，非常适合办公室门口等小范围精准签到。缺点是需要提前部署蓝牙信标硬件，且有效范围很小。

弱网签到：这其实是一种降级方案，而非一种独立的签到方式。当上述所有方式都因网络问题无法及时将数据上报服务器时，我们会先将签到数据加密后存入本地数据库，并启动一个后台任务，在网络恢复后自动进行重试上报，保证数据的最终一致性。

在实际应用中，通常优先尝试 Wi-Fi 和 GPS，在办公场所则优先使用蓝牙，最后辅以弱网兜底。

蓝牙签到思路

蓝牙签到的核心是设备发现、匹配和距离感应。具体的流程是：

• 权限申请：首先在 module.json5 中声明必要蓝牙相关的权限
• 初始化与适配：检查设备是否支持蓝牙，并打开蓝牙适配器
• 设备发现与过滤：开始蓝牙扫描，并在回调中通过设备的或名称过滤出公司签到信标(Beacon)
• 连接与信号强度检测：发现目标设备后，不需要建立传统的 GATT 连接，而是持续监听其广播包中的 RSSI（信号强度） 值
• 距离判断与签到：我们根据 RSSI 值估算大致距离。当信号强度持续一段时间稳定在阈值范围内（表明用户在近距离），则结合当前员工信息和时间戳，调用签到 API 完成打卡
• 性能优化：为了省电，在签到成功后或页面不可见时，我们会及时停止扫描

整个过程中，权限处理、设备过滤规则和距离判断的阈值设定是几个需要仔细调试的关键点。

遇到的问题

遇到问题，先是根据报错信息和错误代码查询官方指南排查，然后去论坛查看是否有同样的问题已经有了解决方案，最后给官方提工单需求帮助。没有特别困难的问题。遇到的问题有：

• 不支持蓝牙 beacon 协议，无法获取 major 和 minor 值，无法进行核心签到模块的实现
• 数据库无法一条语句增加多个列
• 无法使用 charles 代理进行抓包（将 wifi 断开 ，然后在输入 wifi 密码的界面同时填写代理信息）

最大的挑战

一个印象深刻的挑战是蓝牙签到有时候扫描不到设备。

问题排查：经过日志分析，发现不是代码问题，查阅了大量资料，最终在华为开发者官方论坛发现，这是一个功耗优化策略：在手机熄屏一段时间后，会限制后台蓝牙扫描的频次。

解决方案：我们无法改变系统策略，于是从业务逻辑上做了优化。我们在页面上添加了明确的用户引导：“请保持屏幕常亮以完成签到”，并设置了一个 60 秒的超时定时器。如果超时仍未扫到设备，则提示用户‘签到失败，请重试’并自动停止扫描，避免无谓的电量消耗。同时，我们也将此问题反馈给了华为官方，并关注其后续系统的更新。

总结

参与北森 App 的鸿蒙 NEXT 首批适配，对我来说是一次非常宝贵的经历。接触了一些移动端的开发，也快速掌握了鸿蒙开发的技能，更锻炼了我面对新技术、紧 deadline 和复杂需求时的快速学习、问题解决和项目推进能力。我也非常看好 HarmonyOS NEXT 的生态前景，很期待能将这方面的经验应用到未来可能的项目中。

对外开放平台

对外开放平台
负责北森 PaaS 平台与外部的生态体系建设，包括外部第三方系统与北森系统的数据的交互和应用的集成、支持公司各业务线相关产品需求。如对接招商、工商、 民生等银行，支持薪酬团队的银企直联的发薪功能；对接钉钉、飞书、企业微信等 IM 平台，支持招聘团队的内推功能在软件各端（Windows、Mac、iOS、Android）通过 H5 登录；优化开放平台的接口文档等，保障业务的稳定运行。

我在简历中写了以上内容，面试官可能会问我哪些问题？我应该怎样回答？

招聘登录

之前招聘业务在企微是招聘自行对接的企微，底层使用了集成中心的部分封装能力。本次招聘的内推和与企微的集成，统筹到集成中心，以减少成本和降低风险。

遇到多端 H5 登录适配的挑战。采取的方案是：

• 使用统一的 企业微信 OAuth2 接入流程协议对接三方平台登录
• 前端根据 UA 来判断不同的客户端，PC 端和移动端使用不同样式组件来渲染
• 自测时重点覆盖 Windows、Mac、iOS、Android 多端，使用 Charles 代理调试

针对多语言，不用端的语言代码不同进行兼容、整理出文档给产品经理。

银企直联

给薪酬团队提供组件，客户直接使用我们提供的组件上传银行的相关信息。不同银行有不同的流程，基于薪酬团队传入银行代码，组件渲染对应的组件流程。

招商银行的薪福通需要请求生成秘钥、绑定经办人银行编号、连通性检测；工商银行绑定证书文件和密码、连通性检测。

没有使用特别的加密方式，只有针对文件上传时，对文件进行 base64 的处理，防止丢失文件内容。具体与银行的加密传输逻辑由后端处理。

此外，涉及到跨团队合作，沟通成本高。与通常的迭代一般与本团队成员沟通不一样，这里不仅需要与本团队成员沟通，还需要与薪酬团队的前端、产品、测试和设计沟通，需要用更多的时间来同步和对齐，保证产品设计的一致性。而且迭代周期不一样，联调成本高。开发时只能和本团队的后端使用 mock 数据联调，等到薪酬团队开始对接组件时，平台正处于非研发阶段，需要合理利用时间，甚至用个人的时间联调和解决 bug。虽然困难重重，但是在适当的指导和努力下，最终还是完美地完成了开发任务，保证了组件开发的质量和顺利的对接。

接口文档

后台设置：支持拖拽文档和文件夹。

前台页面：新的 UI 展示，文件夹共支持 3 层。

应用配置中心

应用配置中心
负责应用配置中心的前端开发，包括页面功能、交互逻辑、视觉要求、稳定性保障等。规范协同迭代流程，推动项目正常上线。翻新元数据（如字段、表单、列表等）的配置页面，重构页面代码，改进了页面易用性，更方便扩展标准元数据和新建自定义元数据，满足企业的个性化配置，极大提高了使用效率。

我在简历中写了以上内容，面试官可能会问我哪些问题？我应该怎样回答？

之前的应用配置中心页面交互视觉落后，交互体验繁杂。产品要求基于现有功能不变整体翻新页面。

要翻新列表、搜索、视图、详情页等元数据，回顾了已翻新的字段、表单、功能按钮页面的代码结构，发现这几种元数据的页面结构和功能基本相同，但之前是分开写的代码，存在着代码大量重复、浪费资源等弊端，如果依然不变，会加剧后期维护成本高等问题。

针对页面和功能都高度形似的情况，我采取使用公共类组件，使用继承的方式重构页面的设计方案：将公共逻辑提取出来，各元数据页面的特殊逻辑在自己的子类组件中处理。通过这样的方式不仅有效解决和避免上述问题，而且开发起来思路清晰、省时省力，还可以让代码整体更加简洁可读。最终，不仅开发用时少，开发质量也超出预期，迭代的 bug 量达到 0.8/人/天，起到了事半功倍的效果。