这是 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开发方法大全
以上都是知识体系梳理的例子。知识体系的完善，我的理解是：将看似割裂独立的一个个知识点，串成一个网状或者树状结构。
知识体系形成和完善后，再进入新领域学习时，就能灵活运用自己已有的知识和经验，做到举一反三了。
知乎上安晓辉老师有一篇文章：那些很厉害的人是怎么构建知识体系的，值得一读。
安晓辉老师对于知识体系的观点我非常认同：
知识体系是结构化的，知识点之间彼此关联，有无数回路，四通八达。这样的好处是，我们遇到一个问题，就会触发某个知识点，我们捕捉到这个知识点，就可以沿着知识体系的无数关联和回路，快速找到相关的其他知识的点，组合起来，形成针对所遇到问题的解决方案，就表现出专业水准，就当得起“领域专家”之称。
2. 扩大了自己的交际圈，认识了很多朋友。
三年半的写作，让我结识了很多 SAP 中国研究院其他部门的同事，以及 SAP 生态圈的客户和合作伙伴们。不少也是圈内深受从业人员尊敬和认可的成名人士，三人行必有我师焉，我从这些朋友身上也学到了很多。
我自己还创建了一个技术交流群，里面汇聚了来自五湖四海国内外的 SAP 从业者们，群内的技术交流氛围浓厚，里面讨论的话题也给我提供了源源不断的写作素材。
3. 在持续写作过程中，找到了自己的短板和不足
每逢写作过程中卡壳的时候，我就意识到，自己对该领域的理解还存在问题。技术写作让我能发现自己的技术短板，从而明确将来努力的方向。
在写作过程中，要回复读者在文章内的留言，和粉丝互动，不可避免就需要和人进行互动。有一种说法认为，好的程序员逻辑思维能力强，沉浸于代码的海洋中游刃有余，但是往往不擅长和人打交道。而我通过技术写作建立起来了一个人脉圈，我需要和圈内不同背景的朋友打交道：SAP 同事，客户，合作伙伴的开发顾问，合作伙伴的管理人员，SAP 自由职业者，学生等等。我很珍惜这种能够与 SAP 生态圈内各种类型的从业者交流的机会，以此弥补我和人交流沟通方面的不足。
以上就是本公众号关注者达到一万之际，我对过去十余年来技术写作之路的一个复盘。我也希望自己的身体状况，能支持我将技术输出继续进行下去。
感谢大家一路的支持和陪伴。
