一个 SAP 开发工程师十余年的技术写作之路回顾

这是 Jerry 2021 年的第 31 篇文章，也是汪子熙公众号总共第 307 篇原创文章。

本文目录

• 汪子熙公众号的风格定位

• 为什么我会开始在微信公众号上书写技术文章

• 我的写作素材从哪里来

• 坚持了长达十余年的技术写作，我最大的三个收获

Jerry 从 2018 年正式开始在微信公众号平台写作，至今已经整整三年半了。到 2021 年 4 月 30 日为止，总共输出了 306 篇原创文章，获得了 10000 个粉丝。

虽然我深知，这一万个粉丝朋友，在整个数以亿计的微信用户群里，只是极其小众的一个群体，不过我开启公众号技术文章写作的初衷，绝非是“在 XXX 时间段内，粉丝数达到 XXX 个”。因此，对于公众号的粉丝数，以及每篇文章的阅读量，点赞个数，我也采取很佛系的态度去对待，一切顺其自然。

当今这个自媒体时代，每天都有新的微信公众号涌现。然而能够被大家记住，经常保持关注和阅读的，只有一小部分。这一小部分公众号无疑都有各自鲜明的特色。

申请这个公众号之初，我就对其有着清晰的定位，并且坚持到了现在，那就是：严谨，专业。

为了做到严谨，这 306 篇原创文章，篇篇书写的过程我都是字斟句酌，在发布之前自己也会重复读几遍，确认思路是否清晰，行文逻辑有无问题，文章里描述的 SAP 知识点，力争做到 100% 正确。除此之外，我也会检查语句是否通顺，是否存在错别字。

为了做到内容的专业，我有三不写。

• 和 SAP 不相关的技术不写。

• 自己理解得似是而非，不够深入的 SAP 技术不写。

• 鸡汤文不写。

因为持续发表技术文章，我也被邀请加入了一些微信公号主群。认识了一些同仁，他/她们会琢磨和分析比较受欢迎的的文章类型，写作方式和标题命名方式等特征，然后模仿进行创作，也能获得不错的吸粉效果。然而采取这种方式打造出的文章，已经和我对本公众号的定位产生了较大的偏差，因此我没有选择去模仿，今后还是会一如既往坚持自己的写作风格。

几乎每天都有人在公众号后台联系我，询问我是否有兴趣进行商务合作，即在这个公众号上发一些课程的推广文章。然而我觉得这些课程(比如人工智能学习课程)的受众，和本公众号的粉丝相差很大，因此也没有接受此类合作的请求。

为什么我会开始在微信公众号上书写技术文章

这要从我 2009 年还在做 SAP Business ByDesign 标准开发说起。当时我负责这个产品的 Form 和 Field Extensibility 话题，从 2007 入职开始 已经做了两年多了，也习惯把自己对二者的一些理解和技术分析，写到公司内网 wiki 上。另外我平时喜欢用 ABAP 写一些小工具，能让自己平时工作中少做些体力活。比如手动在 SAP GUI 里点击完成一个流程，需要十几步的操作，但是写一个 ABAP 报表，然后 F8 执行，一步即可完成。我把这些小工具的名称，所在系统和使用方法也写到了公司内网 wiki 上。坚持一段时间后，我会不时收到一些其他同事的邮件，有的是感谢我写的 wiki 帮助他/她们澄清了工作中的一些疑问，同时就 wiki 内容提出了新的咨询；有的则是觉得我写的小工具很实用，但是和他/她们的使用场景还有差距，询问我能不能再增强一下给他/她们团队使用。

下图是我在公司内网 wiki 写作的一个例子，写于 2010 年 11 月。

在公司内网 wiki 写作的习惯，我一直保留到了 2013 年，此时我已经从 SAP Business ByDesign 开发团队转到了 SAP CRM 团队。在一次员工和上级的例行谈话时，我不经意向我的老板，就是后来 SAP 成都研究院的吴院长(详见 我与SAP成都研究院吴院长的二三事 )，提到我写的 wiki， 在公司内部还是有挺多同事在看的。吴院长就说, "这很好啊。你可以试着在 SAP 社区上写，这样能让更多的人看见。" 我心想这提议不错， 加上我也挺乐意在工作中尝试新的方式方法，于是就开启了我在 SAP 社区上的写作之路。

从 2013 年到 2018 年，我总共在 SAP 社区上写了 631 篇英文博客，其中 SAP UI5 & Fiori 221 篇，SAP CRM 198 篇，ABAP 197 篇。

常年在 SAP 社区写作，我也获得了一千个社区粉丝的关注，其中大部分是老外。

因为我写的这些社区博客，以及我在社区上回答 SAP 从业者的问题，我也成为了 SAP 社区导师 和 SAP 社区的技术大使。

2017 年获得的 SAP Mentors Program Excellence & Dedication 的 一个 Award：

SAP Technology Ambassadors 的衣服：

到了 2017 年底，因为我自己持续关注了一些微信技术公众号，从中获益匪浅，所以萌生了自己也申请一个号并且使用中文进行技术输出的念头。于是就有了现在这个公众号。

我的写作素材从哪里来

这个公众号的绝大多数文章都取材于我的每日工作。当我在 SAP 标准产品开发团队从事产品交付工作时，这个岗位对开发人员的技术要求是 精而深，所以我有足够的时间和精力，进行技术积累。同时感谢 SAP 对员工以人为本的培养方式，使得我有机会先后在不同的 SAP 产品团队工作，能接触到不同类型，不同技术架构，不同编程语言实现的 SAP 标准产品。随便举一些例子：

我最近在 SAP Commerce Cloud 开发团队从事 Angular 前端开发时写的一些文章：

• SAP Commerce Cloud ( 电商云 ) 路由路径的自定义配置与开发

• 一小时内在本地搭建SAP Commerce Cloud(电商云)的前后台运行环境

• SAP 产品一脉相承的 UI 增强思路，在 SAP Commerce Cloud(电商云) UI 增强实现中的体现

我在 SAP Cloud for Customer 产品开发团队工作时，团队同事们和我写的文章：

• SAP Cloud for Customer Extensibility的设计与实现

• SAP成都研究院大卫哥：SAP C4C中国本地化之微信小程序集成

• SAP成都研究院飞机哥: SAP C4C中国本地化之微信聊天机器人的集成

• SAP成都研究院廖婧：SAP C4C社交媒体集成概述

• 浅谈SAP C4S自动化

• SAP成都C4C小李探花：浅谈Fiori Design Guidelines

SAP 成都研究院 S4CRM 开发团队的同事们和我写的文章：

• Hello World, S/4HANA for Customer Management 1.0

• S/4HANA Service Management和SAP Field Service Management的集成

• SAP S4CRM 1811 服务订单API介绍

• SAP S4CRM vs C4C, 诸葛亮和周瑜?

分享我在 SAP CRM Fiori 开发团队时所学知识的文章：

• SAP Fiori应用的三种部署方式

• 雪妖现世：给SAP Fiori Launchpad增添雪花纷飞的效果

• SAP Fiori Launchpad Tile，UI5应用，和PFCG Role的对应关系

2018 年到 2020 年 4 月底这三年，我在 SAP 成都研究院数字创新空间团队工作，基于 SAP C/4HANA 产品线做一些概念验证和原型开发。如果说 SAP 标准产品交付团队对开发人员的要求是 精而深，那么做原型开发，概念验证，配合售前同事打单，从事这些工作的开发人员，就得做到 广而博，即在最短的时间内，用当下业界流行的技术，完成能够进行演示的原型。

这三年里，我的团队同事们和我也将完成的很多原型开发，以文章和视频的方式分享了出来，比如：

• Hyperledger Fabric on SAP Cloud Platform

• SAP云平台，区块链，超级账本和智能合约

• 打通C/4HANA和S/4HANA的一个原型开发：智能服务创新案例

• SAP成都研究院数字创新空间沟通S/4HANA和C/4HANA的智能服务演示视频和Coresystems分享预告

• 在SAP UI中使用纯JavaScript显示产品主数据的3D模型视图

• 如何在SAP UI5应用里添加使用摄像头拍照的功能

以及 SAP 成都研究院的同事们和我的职场之路分享：

• SAP成都研究院Sunshine: 我的C4C实习感受和保研之路

• SAP成都研究院35岁以上的开发人员都去哪儿了?

• “最不合格”的SAP应聘者: 从大学生到SAP成都研究院开发工程师

• SAP成都研究院马洪波：提升学习力，增强竞争力，收获一生乐趣

• 从程序猿到SAP产品经理，我是如何转型的？（上篇）

• 从程序猿到SAP产品经理，我是如何转型的？（下篇）

• 我与SAP成都研究院吴院长的二三事

• 我是怎么和SAP结缘的 - Jerry的SAP校园招聘之路

• 那些年伴我一起成长的SAP装备

由于篇幅限制，本文罗列出来的只是冰山一角。全部的 306 篇原创文章，可以从下面的链接获得：

• SAP成都研究院小伙伴们2018～2019两年间的179篇原创文章合集

• 一个SAP成都研究院开发工程师 2020 年的所有文章列表

当然我也试图在技术文章中添加一些趣味性，让它们显得不那么枯燥：

• 一段让人瑟瑟发抖的ABAP代码

• 昨日万圣节ABAP怪兽级代码谜团，公布答案啦

• ABAP vs Java， 蛙泳 vs 自由泳

• 浅谈前后端分离思想对自由泳练习的指导意义

• 我用ABAP做过的那些无聊的事情

• 金庸的武侠世界和SAP的江湖

• 使用代码列出金庸小说中使用过的所有成语

• 关于SAP ABAP字符变量和字符串变量字符个数的一个知识点，和一个血案

坚持了长达十年的技术写作，我最大的三个收获

收获颇多，这里只说三点。

1. 梳理和完善了自己的知识体系。

技术人员有时候会遇到一种情况，认为自己掌握了一个知识点，但当试图将其用语言或者文字讲解给别人听时，发现事实并不像自己想象得那样。自己认为已经透彻理解的知识点，其实却领悟得似是而非。

我在技术写作时也偶尔会遇到这种情形，然后只能中断写作过程，重新查阅 SAP 帮助文档，阅读源代码，单步调试，思考，直至我有足够的自信，已经 100% 理解了该知识点，然后才敢继续往下写。

在经历过多个 SAP 产品的标准开发工作后，通过写作，我能够有意识地去分析这些不同产品的一些共性，比如 SAP 产品在发版之前都必须确保满足的可扩展性 (Extensibility) 这一非功能性需求，于是有了这篇文章：

SAP产品增强技术回顾

很多 SAP 产品都允许 Key User 进行字段增强，比如 SAP CRM，SAP Cloud for Customer 和 SAP S/4HANA. 这些不同产品的字段增强方式的 UI 虽然有差异，但设计思路却有相通之处：

• SAP产品的Field Extensibility

• SAP Cloud for Customer Extensibility的设计与实现

• SAP 产品一脉相承的 UI 增强思路，在 SAP Commerce Cloud(电商云) UI 增强实现中的体现

SAP 不同类型的 CRM 解决方案的横向比较：

• SAP的这三款CRM解决方案，您能区分清楚么

• SAP S4CRM vs C4C, 诸葛亮和周瑜?

一些 SAP 不同产品中某一特性的横向比较：

• SAP 几款产品的 UI 设计 和 Salesforce UI 开发比较：SAP UI和Salesforce UI开发漫谈

• SAP 不同产品的 UI 搜索分页的不同技术实现：SAP UI 搜索分页技术

• SAP 不同产品里 OData 的不同技术实现：SAP OData编程指南

• SAP 不同产品里 API 开发的不同技术实现：SAP API开发方法大全

以上都是知识体系梳理的例子。知识体系的完善，我的理解是：将看似割裂独立的一个个知识点，串成一个网状或者树状结构。

知识体系形成和完善后，再进入新领域学习时，就能灵活运用自己已有的知识和经验，做到举一反三了。

知乎上安晓辉老师有一篇文章：那些很厉害的人是怎么构建知识体系的，值得一读。

https://zhuanlan.zhihu.com/p/84216804

安晓辉老师对于知识体系的观点我非常认同：

知识体系是结构化的，知识点之间彼此关联，有无数回路，四通八达。这样的好处是，我们遇到一个问题，就会触发某个知识点，我们捕捉到这个知识点，就可以沿着知识体系的无数关联和回路，快速找到相关的其他知识的点，组合起来，形成针对所遇到问题的解决方案，就表现出专业水准，就当得起“领域专家”之称。

2. 扩大了自己的交际圈，认识了很多朋友。

三年半的写作，让我结识了很多 SAP 中国研究院其他部门的同事，以及 SAP 生态圈的客户和合作伙伴们。不少也是圈内深受从业人员尊敬和认可的成名人士，三人行必有我师焉，我从这些朋友身上也学到了很多。

我自己还创建了一个技术交流群，里面汇聚了来自五湖四海国内外的 SAP 从业者们，群内的技术交流氛围浓厚，里面讨论的话题也给我提供了源源不断的写作素材。

3. 在持续写作过程中，找到了自己的短板和不足

每逢写作过程中卡壳的时候，我就意识到，自己对该领域的理解还存在问题。技术写作让我能发现自己的技术短板，从而明确将来努力的方向。

在写作过程中，要回复读者在文章内的留言，和粉丝互动，不可避免就需要和人进行互动。有一种说法认为，好的程序员逻辑思维能力强，沉浸于代码的海洋中游刃有余，但是往往不擅长和人打交道。而我通过技术写作建立起来了一个人脉圈，我需要和圈内不同背景的朋友打交道：SAP 同事，客户，合作伙伴的开发顾问，合作伙伴的管理人员，SAP 自由职业者，学生等等。我很珍惜这种能够与 SAP 生态圈内各种类型的从业者交流的机会，以此弥补我和人交流沟通方面的不足。

以上就是本公众号关注者达到一万之际，我对过去十余年来技术写作之路的一个复盘。我也希望自己的身体状况，能支持我将技术输出继续进行下去。

感谢大家一路的支持和陪伴。