這裡所謂的「開發左移」指的是Developing Shift-Left,讓開發者提前在問題尚未被寫成需求之前,就參與問題的討論與剖析 (而不是將網頁應用程式 web application由前端執行大部分的邏輯運算,改從由後端執行的Shift-Left Development)。當我們遇到棘手難解的問題時,可以運用開發左移來增進創意。又稱之為「Ask your developer?」。
創意始於對問題的深入了解
我們經常期望工程師能夠有發揮創意的表現,但卻總是把規格已經定好的需求交給他們,這時候他們唯一能做的事也就是對既定的需求進行拆解罷了,那來創意! 雖然敏捷開發要求工程師在看到需求時,一定要先問Why? 不要在不知為何而作的情境下就一頭鑽入開發工作。但這樣做並不能夠換來創意,若是我們能夠在問題尚未被寫成需求之前,就讓負責開發的工程師能夠參與問題的討論與剖析,不但能夠確認工程師充分的了解問題所在,更能夠讓他有機會參與需求的討論與撰寫,也實踐了「向開發人員提出問題,而不是解決方案。」(註1. 參考自《Ask Your Developer》)
設計模式 Design pattern 模式可以幫我們應付程式的複雜性,要學會設計模式,只要要養成一個習慣,是的;只要死守一個原則就夠了,至少一個。它就是: 單一職責原則(Single Responsibility Principle)。它是《Clean code》作者 Robert C. Martin 所發明的 SOILD 原則裡的第一個原則,這裡我們只取一個而不是五個都要,那樣就太貪心了,而且你本來就應該一次只做一件事,然後把它做好就對了。
.
單一職責原則(Single Responsibility Principle) 定義: There should never be more than one reason for a class to change. . 意思是;一個類別只能有一個改變的原因。 就是一個類別只負責一件事情這樣就不會產生相依性了。 .
它能解決甚麼問題? 就是解相依性,當改變一段底層的程式碼,會影響到其他也相依到這個功能的程式碼時,解法是把他們區分成不同的 class 然後各自擁有自己的 interface 就解開相依性了。(缺點是功能類別被切得太細時,就可能會發生過度設計,而使得類別凌亂而難以歸類,提醒你了!)
Uncle Bob 說單一職責原則是關於函式和類別的,但它又以不同的形式出現在二個層次上,在元件層它成為內聚性規範的CCP原則(註1. the Common Closure Principle共同封閉原則),在架構層它又負責建立架構邊界的變化軸(將程式碼的依賴關係從資料流裡解耦出來,並耦合到架構的層級上,這裡的層級;指的是策略與輸入及輸出的距離,定義是: 管理輸出與輸入的策略是系統中最低層級的策略)。
讓我們回到第一張圖,透過「自我提問」來啟動你的學習,我喜歡透過Email問自己一些問題,然後透過整理和過濾這些問題,來釐清哪一個問題才是你真正要面對的,然後排序一下,找錯了就換下一個。雖然還是你自己認為的(自以為是的一種假設,你還是可能會犯錯)。但我很喜歡用這種假設思維的模式來過濾資訊,因為即便錯了也能很快的重新再來(進行開放空間Open space時,就是要用這招,雖然花時間但效果好極了)。不僅如此;因為有了假設,你的搜尋就可以收斂許多,凡是跟假設無關的資訊大可忽略它,這是長期使用 Google 搜尋時所換來的心得(你可以觀察那些能夠很快google到問題的傢伙,他們都是懂得運用假說思維來過濾龐大訊息的人)。
依據埃文斯資料公司(Evans Data Corporation) 的開發者體驗報告,目前的趨勢將導向為開發者導向的市場(developer Market)趨勢,該公司2019 最新統計的資料顯示2018年全球共有2300萬軟體發展人員,預計到2023年底這個數字將達到2770萬。(註 1.)而這群人將是電子產品或是手機上應用軟體App的最大購買者。所以;未來最具潛力的使用者將是軟體開發者。這也讓開發者體驗(DX, Developer experience)成為實施 API first 的成功基礎。
API first 是企業的核心肌群
API對企業的重要性就好比「核心肌群」對人體運作的重要性一般(註 3. 核心肌群)。核心肌群能有效地藉由動力鏈傳遞力量到四肢,讓人體可以做出更順暢、更有爆發力的動作,如果核心不穩的話,就像站在一個浮板上要你全力丟球,在站不穩的情況下,力量根本使出不來。訓練核心肌群也可以矯正身體多處的疼痛,並且降低運動的傷害,提升訓練的功效!企業推廣API First 也是如此,它能健全組織的各種運作模式,使得企業不論是對內或是對外都有著一致的開發模式,因而健全了組織的運作。
企業不斷的強化自身核心競爭力,希望能夠服務更多的使用者,將所有的服務通過API銜接給合作夥伴、APP開發者、智慧設備生產廠商,實現資料、服務的有限開放,從而服務更多的業務場景,快速形成一個龐大產業鏈。這一點可以使得企業在不改變現有生產模式的情況下滿足使用者碎片化且日益膨脹的需求。這也是造成這股API first 風潮最吸引人的地方。
談產品開發要以使用者為導向;也就是UX至上,談API first 就必須以開發者為導向,也就是開發者體驗( DX) 至上。
API First 的變革,不同於敏捷變革,它可以明確地擁有共同的藍圖來顯示改變的方向、願景與時程。有了明確的時程做依規,可視化的建構流程便可以如同敏捷Sprint 開發一般的協助雙方調整各自的腳步來配合整個生態系統。但API First 與傳統開發大不相同,它完全建立在共同開發的跨團隊協作上,因此開發領域要大上許多,它需要擁有像 SCRUM的每日站立會議來協助大家的同步作業並分享心得。它需要以需求來驅動,因此更需要採用像使用者故事地圖(use story mapping)這類需求的藍圖來協助大家同步。而開發者則要由熟悉的自我學習的方式轉變到較頻繁溝通、分享的團隊學習歷程,而這也正是實踐DX所需要肩負的責任。上圖中;以雲端的方式來描繪藍圖,實質上它是API First 規劃策略藍圖時最有趣的地方,也就是你可把企業想要開放的功能服務,都視成是位在雲端上的獨立 Services,當然前提是要將安全做好、做足了。
API也要做相對應的更新,API是有生命週期的。而我們的使用者都是使用系統或軟體再調用我們的API的間接使用者,API的更新需要使用者跟著做相應的改動,而每一次更新對用戶來說都是一種傷害,我們稱它為改版的漣漪。解決之道;對內部呼叫而言,過去是大喊一聲要大家來開會,在會議中詳細的說明即將異動到的地方,麻煩大家回去再檢查看看是否有影響,有問題的再排schedule 來配合。這是跨部門之間一種極端勞民傷財的協作方式。在實施API First的期間,應該設法將這類的偶發協作改成定期服務的形式(將協作變成服務化,以降低溝通的成本),成本將會低得多了。對外部呼叫而言,我們需要做好原有的API版本控管(註5. Version control)或相關版本說明(例如 Visual Studio 版本及可配合的 .Net Framework 版本)。類似大型軟的預作宣告(例如: version XX將在2019年停止服務 ),這種現象也將會越來越為普遍。重要協力廠商則需增加異動前期預告的推播通知。
實施 API First 在初期,能夠體驗到效能的相對提升是一件令人欣慰的事,但在相依性越來越高的系統中(生態圈中),要發佈一個新版本(套件)可能很快就會變為一場惡夢了。如果相依性關係過高,可能面臨版本控制被鎖死的風險(必須對每一個相依套件改版才能完成某次可以成功的升級)。而如果相依性關係過於鬆散,又將無法避免版本的混亂(假設相容於未來的多個版本已超出了合理的數量時)。當你專案的進展因為版本相依性被鎖死或版本混亂變得不夠簡便和可靠時,就意味著你正處於相依性地獄之中,唯有能夠隨時的關注開發者的體驗才能在順暢的開發中順暢的相處著。
開發者體驗(developer experience, DX) 是API First 實施成敗的核心,過去身為程式設計人員我們常常會遇到一些API 荒唐的連自己的demo 程式都不會通過(demo 程式不work),我們總會嗤之以鼻,懷疑該公司到底有沒有在做測試,但在API First 的時代下,我們應該做的是立即反應給該單位,你的 API 出狀況了,要做好回饋並要要求即時的修正,設法讓損失降到最低。因為大家都處於一個共同的生態圈下,損失也是共同的。
即時回饋是做好DX的決條件,不論是內部或是外部的服務,我們需要即時的回饋來使損失減少到最小。這一點;就像工廠裡的自動化生產線一般,我們需要及時監控來保證服務的正常化。避免這種無知的浩劫,需要隨時蒐集數據與進行判斷的IOT(物聯網Internet of Things 是指連接著各種裝置的集體網路和幫助裝置與雲端和裝置之間互相通訊的技術)的觀念都是做好 API First 不可或缺的一環。
難以防範的漣漪效應
讓 Code Review 成為最重要的一環
程式碼審核(Code Review)是既花時間又花人力的工作,但對於 API First 的開發團隊而言它的重要性更是不能取代。傳統的 code review 多以程式的正確性與可讀性為主。但在這裡審核者又多了一個身分,就是扮演使用者的身分,所以簡單好用又順暢成了另一項要求,反之;它可能是讓撰寫程式的開發人員學到最多的地方(提前取得回饋),因此盡可能維持小更改的開發模式,就變得更為重要(註 8.Google 的 code review)。
2019年底,我在無意間踏入了探索開發者體驗的旅程,找不到書本在談開發者體驗(DX, developer experience)的,只好四處尋找相關的文章、網站資料。這段期間;發現了一個網站就叫 DX Hero (https://www.dxheroes.io/)該公司是一個開發適合開發者平台的產品為主的公司,名符其實是為了developer 著想。還有一家作工具的廠商就叫DX (https://getdx.com/) 它致力於開發使開發者表現出最好一面( Empowering developers to do their best work)的開發工具。這二家公司在網站上也都有提到他們心中對「開發者體驗」 Developer experience 的定義。另外;在學術論文方面,我所找到最早的一篇是來自赫爾辛基大學二位教授的文章,標題是: Developer Experience: Concept and Definition 由Fabian Fagerholm與 Jürgen Münch共同完成,是一篇會議論文(Conference Paper,註1.)出版日期是June 2012.文章裡從認知、情感與感知三個面向來探討DX。算是比較學術性的探討。
第一招 開發者體驗即學習 : 要求正面去看待學習,工程師不是什麼都會的(老闆總是這麼想,只要會寫程式就行了),我們也需要學習只是我們背後的學習你看不見罷了。開發者需要時間去學習開發工作的專業知識。要正視它;就是把學習的時間也納入專案開發的流程,希望的是工程師要先有概念以後才去做估算、Break down to task,不是還沒弄清楚就按習慣進行盲目的猜測,因此要先學習。要敏捷化;就是逐步的學習、開發然後驗證。也就是落實敏捷開發所謂的: 小增量、多迭代與尋求回饋。
功能要開發的好,工程師必須由一位初學者的位置,上升到迅速成為某個領域的專家,然後再把它套用到程式的功能邏輯上頭,並驗證這個功能符合使用者的要求,而這個使用者通常是指的是另一位開發者,就是這個原因讓我們經常把開發者體驗看成是使用 API 時的體驗。但這無疑的是開發者體驗的一種較為狹義的定義,如果我們把整個開發的生命週期都放進來,則廣義的定義應該是泛指開發者在開發的過程中的所有體驗(註 2. 開發者體驗的定義)。
The ‘visible’ aspect refers first to making student learning visible to teachers ……, also refers to making teaching visible to the student, such that they learn to become their own teachers.” (John Hattie, 2009)