一個 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開發方法大全

以上都是知識體系梳理的例子。知識體系的完善，個人理解是：將看似割裂獨立的一個個知識點，串成一個網狀或者樹狀結構。

知識體系造成和完善後，再進入新領域學習時，就能靈活運用本身已有的知識和經驗，作到觸類旁通了。

知乎上安曉輝老師有一篇文章：那些很厲害的人是怎麼構建知識體系的，值得一讀。

安曉輝老師對於知識體系的觀點我很是認同：

知識體系是結構化的，知識點之間彼此關聯，有無數迴路，四通八達。這樣的好處是，咱們遇到一個問題，就會觸發某個知識點，咱們捕捉到這個知識點，就能夠沿着知識體系的無數關聯和迴路，快速找到相關的其餘知識的點，組合起來，造成針對所遇到問題的解決方案，就表現出專業水準，就當得起「領域專家」之稱。

2. 擴大了本身的交際圈，認識了不少朋友。

三年半的寫做，讓我結識了不少 SAP 中國研究院其餘部門的同事，以及 SAP 生態圈的客戶和合做夥伴們。很多也是圈內深受從業人員尊敬和承認的成名人士，三人行必有我師焉，我從這些朋友身上也學到了不少。

我本身還建立了一個技術交流羣，裏面匯聚了來自五湖四海國內外的 SAP 從業者們，羣內的技術交流氛圍濃厚，裏面討論的話題也給我提供了源源不斷的寫做素材。

3. 在持續寫做過程當中，找到了本身的短板和不足

每逢寫做過程當中卡殼的時候，我就意識到，本身對該領域的理解還存在問題。技術寫做讓我能發現本身的技術短板，從而明確未來努力的方向。

在寫做過程當中，要回復讀者在文章內的留言，和粉絲互動，不可避免就須要和人進行互動。有一種說法認爲，好的程序員邏輯思惟能力強，沉浸於代碼的海洋中游刃有餘，可是每每不擅長和人打交道。而我經過技術寫做創建起來了一我的脈圈，我須要和圈內不一樣背景的朋友打交道：SAP 同事，客戶，合做夥伴的開發顧問，合做夥伴的管理人員，SAP 自由職業者，學生等等。我很珍惜這種可以與 SAP 生態圈內各類類型的從業者交流的機會，以此彌補我和人交流溝通方面的不足。

以上就是本公衆號關注者達到一萬之際，我對過去十餘年來技術寫做之路的一個覆盤。我也但願本身的身體情況，能支持我將技術輸出繼續進行下去。

感謝你們一路的支持和陪伴。

更多Jerry的原創文章，盡在："汪子熙":