2006年成立的SAP成都研究院，位於天府軟件園B區。如今，因爲研究院發展的不斷壯大, 已經搬遷到天府軟件園E區了，因此，發生在圖片building各種充滿悲歡離合的故事，已經成爲一部分小夥伴腦海中難以磨滅的回憶，永遠消逝於歷史的長河之中。
我爲什麼要寫這篇文章
SAP成都研究院有很多剛從大學畢業不久的年輕小夥伴加入。一起聊天時，有小夥伴悄悄向我打聽，“咱們公司的開發人員們咋看起來都是年輕人？35歲以上的開發人員去哪兒了？難道程序員真是喫青春飯的？”
這些同學想的比較遠，值得贊一個，看來TA已經在思考自己未來的職業發展之路了。據我所知，SAP成都研究院各個開發團隊基本上都有幾位35歲以上的開發人員，可能是因爲我司的工作和生活的平衡做得相對其他互聯網公司而言更好一些，所以使得大家看起來顯得年輕吧? 畢竟SAP中國研究院連續獲得中國外企裏最佳僱主的榮譽並不是沒有原因的。
上圖來自新聞 - SAP再獲“2017中國傑出僱主”稱號
還有的年輕同事問我，“你一畢業就待在SAP成都，每天坐在同一個地方寫代碼，一寫就是10年。過去10年，過去五年，去年都如此，連寫代碼的姿勢都沒變，不覺得枯燥嗎？" 我的回答是: " 我沒有在同一個地方待着，我最初是在軟件園B6的3樓待着，後來又搬到4樓，然後又搬到3樓，然後搬到E5的8樓。我的寫代碼姿勢也不是一成不變，隨着年齡的增長，背越來越駝了。"
說實話，在同一個產品長時間工作，一點點都不覺得枯燥那也不太可能。拿我自己來說，在我工作的第7年, 我找到我的manager Poseidon談心，我說我感覺作爲一個程序員，我的技術成長遇到瓶頸了，現在在開發團隊按部就班地交付產品功能已經成爲我個人的舒適區，我想做一些更具挑戰性的工作。於是Posei把我從標準開發團隊摘出來，讓我專門從事和客戶相關的工作，比如處理客戶incident, 去客戶現場支持，幫助銷售同事打單等等。通過這些工作我能夠近距離接觸中國的CRM客戶，瞭解到他們使用SAP CRM的痛點，同時能通過我的努力幫助客戶解決一些實際問題，有一點小小的成就感。從這個過程裏我也意識到一個道理：再好的技術，如果不能滿足客戶的實際需要，不能幫助客戶把業務運行好, 那麼這個技術就沒有價值。我覺得自己在業務上還有很多要學的，所以2014年10月我又重新回到了SAP產品開發團隊，一直到現在。
這算是我避免讓自己覺得開發是一項枯燥工作的第一種辦法: 當你覺得在現在的崗位上已經做得足夠好，現在的工作已經成爲你的舒適區時，和你的manager溝通確認您的感覺是否屬實，一起討論有無可能從事別的更具挑戰性, 對團隊對您自己更有幫助的工作。
2017年12月27號我開了這個公衆號，一個原因就是在新的一年裏，想嘗試一種新的技術分享方式，這種新的嘗試也能幫助我消除長時間做開發產生的枯燥感：把我會的東西通過SAP Community之外的另一種平臺分享出來，和國內的具有不同背景不同經歷的各位一起交流。
這就是我想表達的避免長時間做開發工作產生枯燥感的第二種方式：把你自己會的技術用你喜歡的方式和渠道分享出來。
分享方式可以有但不侷限於在公司內部wiki/github上寫作，在公衆平臺上寫博客，或者寫微信公衆號文章。
年輕同事關於技術分享的一些顧慮/問題：
1. 覺得沒什麼值得分享的
Jerry的建議：
小學我們學寫記敘文時，語文老師會教我們一些套路。寫技術文章也是如此，最簡單的套路：提出問題-分析問題-解決問題。我們日常的開發工作中不可能不會遇到問題吧，這些問題就成爲技術分享的來源, 不需要去空想。
2. 覺得自己分享的東西太簡單了，大多數人肯定會。分享出來肯定沒人看。
Jerry的建議:
首先要明確，個人的技術分享，最主要的目的是梳理，打造和完善自己的知識體系，至於別人會不會看了受益，這是次要問題。我自己的親身體會，在寫SAP community博客時，我經常遇到寫着寫着就寫不下去，或者是發現自己無法用語言準確表述自己腦子裏的想法。這種現象就說明我對我正在寫的這個知識點實際上還未透徹理解，會迫使我回過頭去做進一步深入研究。研究->寫作->研究的這種迭代和不斷重複，就是我逐漸形成自己解決問題的套路和方法論的過程。
現在很多大神都在自己的微信公衆號上寫技術文章，爲什麼我們關注了很多大神，拜讀了他們很多文章，過了半個月再回憶之前讀過的那些文章，發覺自己記不清文章的內容了。我們雖然讀了很多技術文章，但是反而覺得和大神們的距離原來越遠?
上圖的科學研究結果表明，單純的被動學習就其記憶留存率來說是最低效的，而主動學習表面上看會花費更多的時間，而性價比卻是最高的。我個人最喜歡的主動學習方式就是把我新學到的東西寫成文字，“一次勞神，終生受益”。就像編程開發裏的庫函數一樣，寫好之後可以到處用。
退一萬步說，即使您的文章真的沒人看，它們至少是您在雲端的一份個人技術成長日誌。每隔一段時間，比如一個季度，半年，一年，當你回顧你以前寫過的這些日誌，您能清晰地判斷出這段時間內您的技術是有精進，還是在原地踏步。
我們來做個小測驗：您能準確回憶起您過去一年內，每個月都做了哪些具體的開發任務？反正我是無法用腦子回憶起來。但是因爲我在SAP community上分享了很多我每天工作中新學到的東西，或者是解決的一個難題，再加上我用CDS view做了一個統計這些分享的小工具，所以我能在1秒鐘內得到各種維度的信息。
比如我每年總共分享的文章數
每個月分享的文章數從高到底排序
從數字能看出去年5月我幾乎每天都會寫一篇，因爲那段時間在德國鄉下，有大把業餘時間可以支配, 比如：Jerry 2017年的五一小長假：8種經典排序算法的ABAP實現
第三多的月份是去年10月，因爲那段時間全花在幫助一個國內C4C客戶的上線支持上了，寫的文章全是上線過程中遇到的具體問題。
再比如我想回憶5年前的11月份我幹了哪些事情？
從文章列表我就能立即回憶起那段日子我正忙着和Poseidon一起，幫助中央電視臺CRM項目組共同處理影響項目上線的一些緊急問題。
3. 害怕自己寫的文章裏包含錯誤，被別人指責
Jerry的建議:
這個沒什麼擔心的，是人都會犯錯誤，有人指出錯誤，可以督促自己回過頭進一步研究驗證。如果發現確實是自己錯誤，誠實地承認並且改正就行。如果依然覺得自己是對的，耐心和別人討論 - 您應該感謝網絡上花費自己時間仔細閱讀了您的文章，並且提出寶貴意見的這些熱心人。
我在SAP Community上一共寫過549篇文章，沒有出現過一次因爲文章有錯而被人指責的情況。
避免產生枯燥感的第三種方式：最大可能地讓您的開發工作自動化起來
這裏的自動化指的是: 如果您每天的日常工作中包含一些瑣碎的，重複性的，並且完成這些工作需要遵循的規則是能夠用代碼清晰描述的，那麼儘可能也讓代碼來完成它們，把節省下的時間投入到真正具有創造性的工作中去。
我的一些自動化例子:
- CRM Addon的開發是在S/4HANA系統上進行的，不可避免的需要和S/4同事就一些模型設計進行討論。S/4的同事經常需要我們提供一些輸入，把一些CRM舊的模型信息填入到一些特殊格式的excel裏。這些模型信息來自SAPGUI裏不同屏幕的不同位置，填一個模型的完整信息我數過總共要點15次鼠標，然後7次CTRL+C 和CTRL+V, 才能把SAPGUI裏的信息粘貼到excel裏。這中間還不包含你打開一個模型，用肉眼去掃描需要的信息在SAPGUI什麼地方。然後每個人分了10個模型需要填。
我對這種體力活簡直是深惡痛絕!!! 然而這是工作, 必須得做。我的做法就是，寫一個ABAP程序，輸入是模型名稱列表，執行這個程序，代碼會自動從系統抓取所有需要填的信息，做恰當的格式化之後，把輸出寫到系統剪切板裏。然後我只需要打開S/4同事提供的excel, 一個CTRL V就解決問題。
最後我花了1個半小時的時間完成這個小程序, 然後花了1秒鐘完成excel的輸入。當然我如果老老實實的手動去填excel, 也許花不了1個小時，但這1個小時的體力勞動裏，我在技術有收穫麼？
用SAPGUI做開發，一個優於用ABAP in Eclipse之處在於，我個人認爲，任何想在開發系統的SAPGUI裏實現的自動化操作，最終都能實現自動化操作, 問題只是代價的大小而已。
我在自己的ABAP開發生涯裏寫過大量這種自動化工具，多得我自己都數不清了。
我把它們的代碼放在了我的github上。
爲了方便使用這些工具，我又寫了一些管理這些工具的工具，方便我快速找到我想用的工具：
Some small ABAP tools I write to improve daily work efficiency or just for fun
目的如上面說的，我痛恨體力勞動，我要用代碼來完成它們。
2. web應用調試的自動化。
如果是後臺代碼的bug，我經常遇到的情況是，每次我得在前臺做N次的點擊，跳轉，才能觸發我後臺的斷點，而我處理的後臺錯誤沒有10次8次的調試根本無法定位問題。每次斷點觸發之前的重複操作讓我忍無可忍，所以我通常會自己寫一個小程序模擬前臺的操作，每次執行這個小程序，1秒鐘即可觸發斷點。
我把其中一個例子寫在了這篇blog裏My Tips about how to handle complex and tricky issues
我把這種專門爲了方便調試而開發的小程序稱爲腳手架。
(注: 這篇博客的發佈時間讓我回憶起那不堪回首的調試經歷，2014年4月30日調試了整整一天，花費了8個小時最後才找到問題根源。)
這些腳手架程序的開發通常會增加您進行錯誤調試的總時間，特別是在敏捷開發的時間壓力下，有的年輕同事一定會對是否採用這種方式有些猶豫。尤其當您是一位前臺開發人員時，一開始可能會對如何使用後臺API來模擬前臺操作感到比較困難。然而越困難的事情通常意味着越大的回報，比如您花大力氣學會了自由泳的雙側換氣之後，您在水中的前進方向將更穩定，前進速度更快(我看這篇文章自由泳換氣，只用一邊怎麼行？裏介紹的，我至今還未學會)
如果是前臺js代碼的bug, 但是必須依賴於後臺某些特定的數據才能重現，而生成這些數據又需要在前臺做很多複雜的操作，這導致每觸發一次前臺的斷點要花很多時間。爲了避免這種觸發斷點前不必要的等待，UI5裏面提供了成熟的解決方案：直接把能引起前臺出錯的後臺數據保存下來作爲MOCK DATA, 然後使用UI5的MOCK SERVER把前臺發向後臺的請求攔截並重定向到MOCK SERVER.
前段時間有個俄羅斯程序猿火了，因爲他已經將生活中的很多瑣事也用代碼自動化起來了：他寫了一堆腳本，**會給老婆發加班短信、會在宿醉不醒時給自己請假、會自動根據郵件恢復客戶的數據庫、還可以一鍵遠程煮咖啡。**他的腳本所在的github地址見這個鏈接。收穫的這3萬+的星，說明自動化在程序猿心中的重要程度。
總結
囉嗦了這麼多，對於年輕的開發同事們我的三點個人建議:
1. 當您發現您在當前工作崗位上已經進入成長瓶頸期，現在的工作內容已經成爲您的舒適區時，和您的管理者交流，確認您的感覺是否真的和事實一致。如果屬實，一起探討有沒有可能去做一些更有挑戰性，能讓您更快成長的任務。
2. 養成知識積累並分享出來的習慣。
3. 將您工作中一切瑣碎，重複，讓您抓狂的事情自動化起來。
最後，回到文章題目的問題：SAP成都研究院35歲以上的開發人員都到哪兒去了？
我的回答：就在您的身邊。我迅速在腦子裏過了一遍，成都SAP研究院每個敏捷開發小組都有至少兩到三位35歲以上的資深開發人員，別說35歲，40多歲的都有。咱們同事在公司內部都從不叫他們的英文名字，而直接叫某某老師。
SAP成都研究院開發人員裏最傑出的代表，當然是以人工智能和機器學習聞名於整個西南地區的高級數據科學家Ding Orlando。據我所知我們這位科學家今年也超過三十五歲了，依然是SAP成都研究院開發領域內的旗幟人物。當然我是不會把他的微信號泄露出來的，不然被其他公司挖走，Poseidon會把我掐死。
另一部分和我同一年進SAP成都研究院的小夥伴們，時光荏苒，現在大都已經超過35歲了。
-
有的出去自己開公司，早已財務自由了;
-
有的去其他公司當CEO/CTO/CIO了;
-
有的改行了，成爲金融／政界精英;
-
有的移民其他國家，在當地繼續從事SAP行業;
-
剩下的一部分選擇了繼續留在SAP成都研究院 。
這剩下的一部分有的轉型成了管理者，有的成爲了產品經理，有的成爲了架構師，還有的就像我這樣, 還在繼續做開發。
接下來的公衆號文章, 會有SAP成都研究院其他資深同事分享自己的故事：如何從開發人員成功轉型成一名成功的XXXX。 對這一職業生涯發展感興趣的年輕同事們敬請期待。
附錄: 一些互聯網上的文章
1. 知乎上86萬次閱讀的文章，適用於任何行業： 如何建立自己的知識體系？
2. 我爲什麼鼓勵工程師寫博客
要獲取更多Jerry的原創技術文章，請關注公衆號"汪子熙"或者掃描下面二維碼:
