背景 - 内驱力
之前三年多的工作、主要围绕 antd / antd-mobile 组件库的建设进行，大多数时间都是投入在组件库本身的编写上，中间穿插一些业务支持、主要目的也是为了实际推动这两个组件库的业务落地试炼。同时这三年里部门的 basement 研发平台、凤蝶活动页制作平台、antv 系列的图表可视化库、umi 和 bigfish 应用脚手架 等也都发展成熟并广泛应用起来，但遗憾的是个人因为一直专注于 UI 方面、这些完全都没有正式使用过，也没有很注重对这些优秀产品发展过程的跟进和学习。之前专注于一个点的“闭关修炼”形成了一方面的深度优势、但更多陷入了工作细节、跳出来思考的习惯也少了很多，逐渐意识到这是很危险的信号。另外以前可能对“专注”这个词有什么误解，“专注”确实会让你形成优势、但专注久了优势也会变成劣势！ 所以，是不是也类似长久专注于一方面的公司、大都要面临转型升级？传统公司的转型升级比如可以加快数字化建设/线上渠道拓展，但个人的转型升级觉得不能是类似从前端转到后端/大数据/算法等其他技术岗从头再学一遍 (现在是知识大爆炸时代、每个人有限的时间和精力几乎是做不到的，而且如果都学到的是浅层次的东西、也是得不偿失)，而应该更贴近所处领域的本质性东西和趋势，比如怎么去拓展新业务、怎么提高研发效率降低成本，而这些大多都是老问题、但肯定需要新思路、需要想了又想。所以，回到支持公司业务的实际场景中、做新的思考，通过多认识各种不同技能的朋友、借助每个人的沉淀和思考、形成团队力量，一起去克服难题。
业务理解
我们所在平台技术大部门，接触的比较多的是技术产品，包括前后端、大数据、云平台、安全产品等。技术性产品的一大特点是输入输出等规则相对比较明确，另外只要有某一方面的技术经验、一般也能比较容易地迁移到其他技术类的产品或平台上。所以这类技术产品、大多看看文档就很容易弄懂了，不过有趣的现象是，产品本身功能虽然简单、但能做出这个产品很不简单。
这次参与了个金融领域的业务，与之前做过的纯技术产品不同的是这个产品涉及到的业务问题、其实全都聚焦到了金融领域，所以只有真正理解了金融领域的知识和问题、才能理解这个产品。产品的主要参与者也几乎都是银行等金融机构出身的专业人士，这时候作为没有相关经验的纯技术支持者，就显得比较被动、也时常会有处在云里雾里的感觉。由于只是负责页面工作、虽然不理解业务对完成工作影响也不大，但有些理解肯定会更容易多方沟通、也可能有更好更针对性的优化方式，另外有个充足动力，毕竟日常离不开钱~ 那就尝试理解下吧 😁
对存款 现汇等支付交易、基金股票等产品的签约和认证、持有资产的涨跌盈亏这些日常相关的还是有些实际感触 (背后原理和操作方式是不太知道的~)。但这次业务主要涉及金融风险方面、可能相对常见金融产品更深入了一些，所以除了问身边专业同学外也看了两本相关的书《流动性之谜：困扰与治理》《企业资金管理》。这样对身边同学每天讨论的 “期限、敞口 头寸、表内/表外、即期 远期 掉期” 等等名词不再很陌生了，但其实也只是了解大概，毕竟书里还有各种数学公式、业务中用的各种模型是看不懂的。也看到了更多一些东西，比如银行的贷款安排、创造的货币怎么成倍增长，会计事务所涉及的账务审核、公司的财务报表、市值计算等，还有比如 “开动印钞机，只能供应经济体中的现钞通货，而这部分货币在整个经济货币中所占的比例只有约5%~10%” 这种让不懂金融的人感觉出乎意料的知识点！🙃
跨界典范和界限：今年杭州云栖大会上阿里云讲到协助攀钢、中策橡胶等发掘数据价值，把人放在车间里几个月去实地写代码，这也不是说程序员就能掌握了炼钢/做轮胎的技能；想想即便是跟阿里电商比较近的线下零售、家电智能控制等领域、几个月时间也难以学到精髓。各个行业的知识点很多且不同、最终落到解决问题思维方式的借鉴上会更有价值，再结合自己的视角和能力去共同解决问题。
对跨领域业务的理解程度肯定达不到相关专业人士高度、第一步先能满足看得懂并解决问题即可，重点也应该要放在做成什么、解决了多少问题。
业务问题
业务的问题其实在整个流程的各个环节都存在，像常见的需求变化及返工等等，这里主要说前端相关的问题，并列出问题现象和解决办法与思考。
1) 后端/外包同学的前端代码质量问题：
- 代码中使用
eval/self = this等不推荐用法，用 es6 箭头函数的意识不强，该用 forEach 的却用成 map，该三个 = 的却用两个，函数参数随意 re assign 等等。 - (react 技术栈)组件内部 state 和 dva 的 state 分配不合理，改变 state 对象而不是新建，在 render 里写大量类似
this.xx = props.zz ? ‘a’ : ’b’不合理代码，也有不少低性能的代码写法问题。 - 使用
过时或不推荐的第三方组件或框架，单个文件过大、缺少模块化意识，不同文件有大量重复代码、缺少抽象业务组件的意识。
2) 我们的 工具/平台 等问题：
- bigfish / basement 功能太过丰富、架构也不太完善，带来比较大的学习成本。
- react / dva 相关技术栈存在一定的学习难度，后端同学大多没时间和意愿深入学习。
- 我们的 UI / 图表 等组件代码示例、与业务脚手架没有无缝结合，有些不能直接拷贝代码，造成使用成本和问题。
- 业务同学反馈，近期全栈培训比较少、希望定期有培训。
3) 支持策略与解决办法：
- 整个项目代码优化重构，遵守严格统一的代码规范，不通过代码规范检测的代码不允许提交。
- 收集共性问题或性能难题，拿典型业务场景、给出示例的规范代码。
- 尝试代码质量扫描工具(jsinspect / pmd / sonar)，对不推荐或过时的依赖项提示，控制台里错误上报，重复代码检测等。
- 抽取出几个通用的业务组件，思考推动 bigfish / basement 架构优化、业务组件规范、类似 Postman 的接口测试平台、Web IDE、远程协作编辑、内部开源共建、跨BU的统一规范，等等有利于解决更大范围问题的讨论。
4) 对我们部门的启示：
- 专业前端觉得不确定或麻烦的地方、在不专业的后端开发和外包面前必定问题更大，复杂问题给出详细和尽量简单的解决示例。
- 更主动地带全栈和外包，帮助 review 代码、给出改进建议。对他们做定期的 “研发流程、技术学习指引、代码规范” 等基本方面的强调培训，保证顺利上手和代码质量的底线。
- 持续探索降低 前端技术学习成本 的方法、比如通过 WebIDE 提供更智能化定制化的代码提示。
总结
作为资源方以平级团队合作的方式、去到业务需求方那里，共同目的是解决公司的业务问题；所以老板也提到要做好“业务合伙人”、做出让人贴心的感觉。说实话、一开始的理解也只是想方设法把事情做好、把业务方服务好就行了，但过程中听到业务方同学在讨论他们与另一个团队合作的问题时说“团队的合作，带的出去、也要带回来东西，人出去了、没带回来东西、还不如直接调过去给他们干活。” 感到很共鸣，原来大家都是这么想的，就像原来我们支持业务的一个重要目的就是完善我们自己做的组件库。支持业务的过程，做好支持是最基本的，更重要的是给团队带回来了什么东西，对自己团队发展有什么好处。
当然业务支持、与安安静静做平台做工具对比起来还有些明显的不同，不妨从以下业务同学部分聊天中感受下~
逻辑上是通的 有价值不否认 但证明链路很长。
他做这个事情对 xxx 的价值说清楚了，业务不在我们这边、怎么把 xx 变成我们的业务、像 xx 一样。
不是我们牵头、边界不清楚、xx是 owner，不知道需求是什么。
什么时候该硬、该对谁硬，该盯住谁去协同、抓大放下。
PD 不懂系统、结果是功能堆砌，作为技术 owner 怎么能避免不被做资源。
没有业务场景、没有抓手，想手伸到业务方、但伸不进去，领地意识强。
程序员常用的 markdown 文档、可能在互联网从业者中有 60% 都不知道，只知道 office …
世界上只有一个人永远正确，毛主席 而他已经死了。项目室里个个都是人才、我超喜欢你们。
业务新同学说：看到周报里 合作 赋能 共建 共创 共赢 聚焦，天花乱坠 个个都是大文豪。