WordZ: Word終結者， 基於Google API開發的文檔自動化產品。可用於線上合同，發票，所有有關文檔的業務流程。主要功能包含，創建，複製文檔，填充變量，導出word，導出pdf等一系列優秀功能
工作了那麼多年，我在閒暇之餘經常思考這樣一個問題，作爲一名軟件開發人員，我的工作，我的研發價值，真的只存在於產品經理所規劃出的這幾個業務中嗎？
開始這項研究的背景是這樣的，我們公司要把籤合同的流程從線下搬到線上，主要涉及到word合同模板的創建，評審，標準合同模板的拷貝，以及一些客戶變量的填充。另外這些合同需要有些需要評審，打印，蓋章，歸檔，和所有公司的籤合同流程一般無二。
這其中的流程就涉及到了很多關於word文檔的操作，合同是word文檔創建，編輯的，打印是將word文件轉化爲pdf，供用戶預覽，打印，另外還有word文檔的審閱模式。背景大概就是這樣了，稍微做過銷售或者簽過合同的都清楚這個流程。那麼問題來了，我們後端使用java的一個包，在將word轉化爲pdf是經常報錯，另外就是打印合同和對合同進行變量填充時，經常報錯，不穩定。用的是一個第三方的jar包。不僅很吃內存，而且功能不太完善。其實我要的很簡單，也很複雜，就是一個可以在線編輯的word系統。包含絕大部分常用word功能。
這模塊的功能我負責了一年了，真的有一年多了，因爲我們公司有很多合同，而且產品規劃很不清楚，經常大改，期間又重構了兩次。經過一年多的摸打滾爬，現在的我已經對業務邏輯，對那些代碼瞭如指掌。雖然對業務和代碼的深入瞭解，我深刻地意識到，這樣的功能不是業務想要的。這樣不穩定，不能在線編輯合同的功能，純粹靠下載word文件，修改後，開始審閱模塊再上傳文件，也根本不是技術人員的追求。 我實在不相信，籤合同這樣一個每個公司都有的業務場景，哪些大互聯網公司就沒有成熟的解決方案。我實在不想，我們不可能是第一個遇到這樣的難題。於是我在幾個月前，我實在想改變一下合同模塊的現狀，我在這個模塊付出了那麼多的努力，解決了那麼多的難題，我不想給自己的職業生涯留下遺憾，不想在我本該更努力去尋找答案的時候，放棄去嘗試，探索。於是開始獨自尋找解決之道。這一開始就停不下來啦。
在一段搜索，嘗試各種產品後我找到了三款比較符合我預期的產品，
- Google Docs API
- 騰訊文檔
- 石墨文檔
這三款產品都可以在線編輯文本，導出word，pdf，打印，以下是三款產品的 編輯器頁面。大同小異。都包含協同辦公的功能，而且也都有存在版本的概念。也有批註，評論。
騰訊文檔：
騰訊這個產品吧，讓我怎麼說那，也有對外的接口文檔，如官網介紹 https://docs.qq.com/doc/DUUxNYWFLeVF0TmRw
但是吧，當你去申請使用的時候，發現只能提交一些信息，等待官方回覆你，我大概是7,8月份提交的。目前依然沒有接到任何消息，可能是我手機號填錯了吧。
石墨文檔
說完了騰訊文檔，再說這個石墨文檔，打着協同辦公的旗號，API都沒有公佈，想要使用，直接就要聯繫銷售人員，也不知道有人多人用，根本不知道水有多深，反正我一般連文檔都沒有公佈，就直接放棄了。
Google 文檔
最後再說Google Docs，是因爲國內他的名聲真不大，csdn上只有寥寥幾篇文章介紹它的使用方法，並沒有介紹它的API，他的集成，他的真正強大，並且要了解他必須要坐上小飛機，去海外衝浪。真正瞭解它之後，你會發現，騰訊，石墨真是小家子器。首先Google Docs的文檔所有文檔對外，相比騰訊文檔，文檔詳細到令人髮指，可惜都是英文的。哈哈哈。。。這已經將一部分人阻擋到外部了。另外。Google Docs 的所有文檔都是存儲在雲硬盤裏，Google這個大佬，爲每個用戶分配了15G的免費存儲空間。你也可以申請更多。此外，Google要打造的是一個協同辦公的生態，Docs只是其中的一個小產品，管理，相互間調用的工具叫做AppScript。 此腳本可了不得，不僅可以將excel的數據渲染到Docs裏，還可以直接使用BigQuery將數據渲染到PPT上。真是一個大平臺，大生態。通過API授權的方式，使AppScript能夠拿到用戶所有的數據，從而創造了一個大融合，大發展，大統一的局面。這很可能是後續國內BAT後面要效仿的。不信的話 我們可以等着瞧。。。。。
扯的有點多了，在搭乘小飛機充分看了GoogleDocs的官網介紹後，和體驗了他們的Demo後，我決定還是用GoogleDocs來作爲第一個嘗試對象。果然它也沒讓我失望，雖然中間很曲折，讓我幾度想放棄，罵娘。但最後還是完成了0.1版本的產品雛形。下面我就爲一一講解我探索Google Docs的血淚歷程。
山重水複疑無路的開始
我之前對谷歌API只有一些很片面的瞭解，但從來沒有使用過，也不知道其中的複雜。 要快速學習一個東西最好的地方是官網，Google Docs API 官網 這一個觀點應該是所有技術人員的共識，但卻有很多技術人員學習一個新工具的使用，總是去一些第三方，或者從亂七八糟的論壇開始。這是非常不對的。只是在學習的開始階段是不對的。但如果遇到問題了，去這些網站去尋找答案，這無可厚非。 下面就是Google Docs API的官網截圖
做的很好，有詳細的文檔，有快速開始的可操作Demo，也有笑容可掬的美女爲你介紹該API的使用。做的可說是用心良苦。對開發者非常友好。
在簡單看了官網的介紹和快速開始的Demo後，我決定立馬去嘗試一下，首先是創建一個文檔。API支持多種編程語言調用，如官網所寫支持這些
瀏覽器，Go ，Java ， .Net，Node.js， PHP ， Python， Ruby 在此背景下，我首選了Python版本去嘗試Demo的運行，這在後來證明是錯誤的，不僅僅增加了自己的開發難度，而且差點讓自己的新鮮想法死於搖籃。在運行了PythonDemo時總是報一個錯誤，鏈接服務器錯誤。後來我實在沒辦法了，就寫了篇博客記錄下來，希望以後自己能記起並且徹底解決他。也是大功一件。我相信我會解決它的，只是時間問題。在多次嘗試無果之後，我又去嘗試了Node.js 的Demo，然後這次還是讓我很失望。依然是鏈接服務錯誤。我嘗試了很多方法，修改參數，demo啓動的端口，去https://stackoverflow.com/查找原因，去他們github下提Issues，就差給他們寫demon的開發人員寫郵件了，當然最後不得已我依然給他們寫郵件，請教。爲了解決我的問題，我會盡我最大的努力，去嘗試一切可以嘗試的辦法，儘管這些辦法收效甚微，或根本不會被人看到，但人總是要慢慢摸索正確的道路，而不是遇到問題，就停止不前，放棄。在嘗試了三四個晚上後，我決定放棄， 放棄從Python和Node.js 的demo開始，因爲相比Python和Node.js 我最擅長的在瀏覽器端使用JS 直接調用API，所以在一陣曲折的探索後，我確定了以Browser爲基棧的產品開發，即在瀏覽器端直接使用JavaSript調用Google Docs API的開發方式，下圖即使我運行官方Browser Demo的結果，輸出結果非常完美，當然這是在搭乘小飛機的情況下。
手可摘星辰的技術方案
確定開發方式後，我簡單嘗試了一個官方的QuickStart demo 果然可以順暢無比地運行，我內心稍有雀躍。既然這個開發方式沒有問題，那就開始制定更爲詳細完善，能夠集成到現有系統中的技術方案吧。
業務背景我已經說過了，以及系統現狀也介紹過了。下面按照自己的思路設計一個技術方案，或者叫可執行解決方案
- 創建一個含有變量的文檔A
- 複製一份文檔A爲B
- 更新文檔B，填充變量
- 下載Word版的文檔B 下載pdf版的文檔B 命名可以自定義
- 打印，在線編輯（完成以上後再探討）
- 在線評審，導出帶有評審的文檔，可以對文檔進行，修改，刪除，替換一些字段，表格內容，圖片
以上的方案是在理想狀態下啊，能否完成取決於API的支持。方案既定，下一步就是筆直地往前走。
步步維艱，步步爲營，學富五車
在確定了技術棧和實現方案後，就開始寫代碼了，
OAuth2.0
首先，Google API 都是通過OAuth2.0授權的方式來調用的，關於OAuth2.0 大家可以查看一下官方資料，
在清楚了OAuth2.0後，我就知道了爲什麼調用一些接口報沒有權限。據說可以使用postman 調試谷歌API，但我試了幾次都沒成功。通過OAuth2.0 我們獲取一個臨時調用接口的accessToken，這個accessToken會一直跟隨着API的調用，由官方庫自動設置到http的headers上。我們不用管理
項目，憑據，API的開啓
我們要使用Google API 首先要創建一個項目。所有的憑據，API 調用，配額，都是在項目之下
進入谷歌雲控制檯 點擊有左上角的項目名稱，在彈窗上點擊新建項目，然後創建憑據。任何API的調用都需要憑據，憑據包括Client ID和 API key 還要一些其他配置項，這就像是一個密匙，是你調用API前的配置參數。
創建憑據在這裏
創建完憑據後，需要此項目開啓一些API，有些API是收費的，有些是免費的。
這裏便是Google的API庫，你可以隨意挑選，
google-api-javascript-client
使用js調用接口，必須要了解一些這個庫，這個是谷歌的一個開源庫 地址
庫裏介紹瞭如何初始化OAuth2.0，如果配置一些變量，發起請求的兩種方法，Load the API discovery document, then assemble the request. 與 Use gapi.client.request
發起請求的一些參數配置
到這裏 該瞭解的都已經瞭解了，再查閱一下文檔庫就可以開始真正動手寫代碼了。
Google Docs API
API 一共有三個 真是少的讓人髮指啊增刪改查就只有三個， 刪除不貴Docs管，歸Driver管
create ：創建
get：獲取詳情
batchUpdate：更新
以上這些東西，我都是經過幾個星期，很多個晚上，不管模塊，不斷試錯，總結出來來的。現在寫的那麼輕而易舉，當初真的是讓我頭疼。國內的資料真的少之又少。我的英文也不是很好。一半靠想象，一半靠翻譯插件。算是把文檔，逐漸琢磨透了。理清了思路就豁然開朗。在這個過程中，爲了讓我收集到的資料別人也能看得到，我就把一部分文檔 複製到了我的博客裏面。有中文的有英文的， 都在這個分類Google API下，大家可以隨時查看。
Google Drive API
瞭解了Docs API ，還要去了解Google Drive API，這個API是去管理操作個人雲盤上的所有文件，上傳，下載，複製，修改。刪除等等一系列文檔操作。。。。。。
目前這個API有三個版本，最新的是V3，其次是V2
以上是我在研發WordZ是所學的大部分技術，我從沒想過，做一個簡單的demo需要那麼多的知識，需要鋪那麼多的墊。如果早知道是這樣，我會不會放棄？答案是不會，因爲我喜歡挑戰，我喜歡創新，不喜歡固步自封，閉門造車。我查看了下活動日誌，從我真正開始開發，探索，到研發成果，一共用了一個月時間。整整一個月，這一個月的每天晚上，每個週末我都在想着這玩意
到底要怎麼做，到底哪裏出了錯？最終功夫不負有心人，我終於成功地做出了一個像樣的Demo級產品
爲伊消得人憔悴
前文我已經說了，我在探索的過程中遇到了很多的困難和挫折，這些困難折磨這我的日日夜夜，讓我難以入睡。每有閒暇時間就去想問題該怎麼解決。下面我就找幾個比較典型的問題來和大家分享一下
典型問題1：Google JS API 授權 失敗
在調用API時，爲了格式整齊，漂亮，將一部分授權代碼這樣寫了
// 初始化OAuth2.0授權
const authenticate = () => {
return
gapi.auth2.getAuthInstance()
.signIn({scope: "https://www.googleapis.com/auth/documents https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/drive.file"})
.then(
res => {
console.log(res)
printLog(`簽名初始化正確結果:${res}`, 'success')
printLog(`Sign-in successful`, 'success')
},
err => {
printLog(`簽名初始化錯誤結果:${err}`, 'error')
printLog(`Error signing in`)
}
)
}
不知道有沒有小夥伴能看出來問題所在， 這個方法也是能執行，但是無法返回一個promise，從而進行後續操作。導致授權失敗
代碼無法正常運行,雖然不報錯。讓我頭疼了一會 頭疼指爲2，我仔細對比了demo的代碼。demo代碼如下
發現除了格式和換行，真的沒有沒有什麼區別了啊。經過仔細的調試，和不斷地嘗試性修改，我知道了問題所在，問題就出在了換行，爲了漂亮，整齊我將第一行，return 後面的語句，換了一行，這樣就導致js代碼執行順序錯誤，此函數沒有返回一個promise。將return 後的換行去掉，立馬正常了。算是自己犯了一個完美主義的錯誤吧
典型問題2：python，Node.js 的quickStart無法正常運行
待完善。。。
典型問題3：使用V3 Drive API文件無法導出
待完善。。。
典型問題4：無法創建帶有內容的文檔
待完善。。。
典型問題5：無法一次填充多個變量
待完善。。。
漫卷詩書喜欲狂，我輩豈是蓬蒿人
待完善。。。
測試用例頁面及日誌
帶有變量的基礎模板，待複製
已複製出來的並填充了變量的文檔
導出的word文檔
導出的pdf文檔
線上體驗地址: mczaiyun.top/wordz（需搭載小飛機）
前無古人後無來者
待完善。。。
