我是如何成為一名全棧工程師的？丨IDCF
星標關(guān)注，第一時間獲取IDCF社區(qū)資訊，了解活動動態(tài)，福利多多不容錯過！
作者：宋奕興
來源：Thoughtworks洞見作者
經(jīng)歷了將近一年的時間，我終于階段性地完成了從iOS開發(fā)到后端開發(fā)的角色轉(zhuǎn)變。
現(xiàn)在我可以自豪地說，我已經(jīng)接近一名全棧工程師了，已經(jīng)熟悉了后端開發(fā)的各種工具、環(huán)境和一些后端工作的方式。
接下來，我將繼續(xù)熟悉框架、工具、語言，并繼續(xù)深入研究后端的一些技術(shù)方案和實現(xiàn)策略。
通用軟件開發(fā)流程
在這將近一年當中，經(jīng)歷過太多的坑了。
幸運的是，我們作為一名通用軟件的工程師，這個行業(yè)發(fā)展了這么多年，其工作流程已經(jīng)趨于穩(wěn)定。
所以，在我個人看來，無論是什么樣的開發(fā)角色，對于開發(fā)這個崗位來說，我們大致可以將知識結(jié)構(gòu)分為以下幾個方面：
語言
框架
IDE
依賴管理
測試框架
編譯運行環(huán)境
運行平臺
打包工具
部署方式
CI/CD配置
性能指標
如下圖所示，例如：
做iOS開發(fā)的語言就是OC或者swift，我們學習語言特性之后，需要學習如何使用對應(yīng)的框架進行開發(fā)，開發(fā)過程中，我們用Cocoapods做依賴管理，使用XCTest寫測試代碼，最后經(jīng)過LLVM和Mach-O的編譯打包后生成了IPA包，我們將IPA通過Xcode發(fā)布到AppStore中，然后用戶可以下載并運行在相應(yīng)的AppleOS(iOS/iPadOS/MacOS/WatchOS…)中，并且上線后我們需要重點關(guān)注的指標是崩潰率和卡頓率。
那么我們也可以將這些模塊映射到后端的學習中去。
后端開發(fā)也會大致遵循這個結(jié)構(gòu)，就像流水線上的各個工位一樣，每一步都是需要做的，只是使用的工具和方式不同罷了。
接下來，比如，我們選擇JS語言進行后端開發(fā)，那么我們一定也會選擇一個框架（如果不是從底層開始寫的話），假如我們選擇了NestJS框架，那我們肯定也會問，管理依賴用什么做呢？測試用什么框架寫呢？哪個IDE好用呢？我要如何將它進行打包發(fā)布呢？上線之后我們用什么指標作為衡量其好壞的標準呢？
一旦我們擁有了針對整個流水線或者工作流程的認知，我們接下來要做的，只是在尋找有什么工具能夠?qū)崿F(xiàn)這一步驟而已，如此，對于快速學習上手很有幫助。
這里，有一個網(wǎng)站，或許能有所助益，https://roadmap.sh
借助這個網(wǎng)站，我們可以清晰地規(guī)劃自己的學習路徑。
圖片來源：https://roadmap.sh/backend
開發(fā)過程側(cè)重點的轉(zhuǎn)變
正所謂屁股決定腦袋，作為一名前端或者iOS開發(fā)，在開發(fā)過程中的側(cè)重點一般在以下幾個方面（按照我腦袋中的順序排列）
UI/UX的實現(xiàn)
怎樣的數(shù)據(jù)結(jié)構(gòu)可以更好地驅(qū)動UI
如何和后端交互
各個模塊之間如何更好地調(diào)用
如何更好地持久化數(shù)據(jù)
如何更好地使用線程，協(xié)調(diào)UI渲染時的主線程和其他線程
如何讓CI/CD更有效率
降低崩潰率/卡頓率
而在后端開發(fā)過程中，我的側(cè)重點變成以下幾個方面了：
數(shù)據(jù)如何更好的存儲，注重表結(jié)構(gòu)的設(shè)計
如何和前端更好地交互
contract怎么設(shè)計
怎么更好的兼容多平臺，例如，Auth怎么做，BFF怎么做，數(shù)據(jù)結(jié)構(gòu)怎么設(shè)計
怎么更好地做API的版本管理
各個模塊或者服務(wù)之間如何更好地協(xié)作，如何更好地設(shè)計事件
CI/CD怎么更有效率，不同環(huán)境的部署怎么做能更好地做E2E測試
降低接口響應(yīng)時間/HTTP錯誤率
當然，側(cè)重點的轉(zhuǎn)變主要還是因為前端和后端的服務(wù)對象不同。
前端應(yīng)用更多的是服務(wù)用戶，所以如何將頁面做的更好是首要，然后再向后思考如何更好地為頁面汲取數(shù)據(jù)。
而后端更多的是服務(wù)前端，或者其他后端服務(wù)，重點在于數(shù)據(jù)處理和API設(shè)計，所以數(shù)據(jù)是首要，如何存儲數(shù)據(jù)，如何傳輸數(shù)據(jù)，是重中之重。
開發(fā)者思維角度的轉(zhuǎn)變
由于工作的側(cè)重點變了，所以思考的方式也會隨之改變。
作為一名iOS開發(fā)，在日常生活中，我會習慣性地對一個正在使用的APP思考，這個特效是如何實現(xiàn)的，這個APP的頁面是如何組織起來的，或者這么多頁面同時存在切換，它是如何進行內(nèi)存管理的？
而作為一名后端開發(fā)，我開始思考的是，微博的互粉功能在數(shù)據(jù)結(jié)構(gòu)上是怎么保證高效率查找的？微信消息是怎么做到丟失率這么低的？
更加明顯的是，在進行需求分析的時候，之前習慣性的將頁面作為錨點，比如討論業(yè)務(wù)需求首先確定這個頁面交互如何實現(xiàn)，然后確定什么數(shù)據(jù)更好的驅(qū)動頁面，然后再定API。
而對于后端，更多考慮的是背后的數(shù)據(jù)表字段怎么定義，表關(guān)系如何管理。
但是，可喜的是，由于現(xiàn)在同時具備這些經(jīng)驗了，所以又可以提起那個老生常談的策略：分層，或者分而治之。
所以，在進行需求分析的時候，更多的關(guān)注點，或者切入點就是BFF和contract怎么定義，用AOP的方式管理團隊的關(guān)注重點，大家討論的時候只關(guān)注交互的地方，以及可能變化的地方，剩下的工作都在各自的領(lǐng)域中進行，互不影響。
這種方式同樣適用iOS開發(fā)內(nèi)部或者后端開發(fā)內(nèi)部，比如我們同時完成一個大的功能，我負責A，你負責B，于是我們先定義好A和B的交互部分，將interface先實現(xiàn)，然后各自回到自己的領(lǐng)域做事，最后面向interface接洽就好。
如何更好地理解業(yè)務(wù)
隨之而來的，我可以理解頁面，知道如何做UI/UX會更好地服務(wù)客戶，現(xiàn)在也可以理解數(shù)據(jù)，知道如何更好地讓數(shù)據(jù)流轉(zhuǎn)和存儲，所以針對業(yè)務(wù)，站在技術(shù)人員的角度，我們可以提供更多的建議，以及指導如何更好地拆解和實現(xiàn)業(yè)務(wù)。
比如，使用BFF來隔斷前端所需的數(shù)據(jù)結(jié)構(gòu)和內(nèi)部數(shù)據(jù)結(jié)構(gòu)，用來避免業(yè)務(wù)變化對底層實現(xiàn)的影響，并且可以兼容各個平臺，給不同的平臺分發(fā)不同的數(shù)據(jù)結(jié)構(gòu)。
業(yè)務(wù)的變化可以被隔離在domain中，前端對于domain的體現(xiàn)是不同的module，后端可以是module也可以是微服務(wù)，然后我們討論時重點關(guān)注的是他們中間如何交互，而不是很多的內(nèi)部實現(xiàn)細節(jié)
再比如，現(xiàn)在需要實現(xiàn)一個登錄功能：
作為前端，我只在乎如何畫出登錄頁面，調(diào)用登錄接口，持久化session然后進入主頁面。
作為后端，我只在乎如何進行Auth的實現(xiàn)，然后存儲生成的 session并記錄日志。
可以從流程中看出來，初始數(shù)據(jù)是前端提供的賬號密碼，從前端流向后端，而后端生成session，然后從后端流向前端，我們第一步需要做的就是確定數(shù)據(jù)怎么流，剩下的就是各自領(lǐng)域的事情，后端去研究數(shù)據(jù)怎么存，前端去研究頁面怎么畫，僅此而已。
在此基礎(chǔ)之上，我們就可以把握整體，進行更好地架構(gòu)設(shè)計和分層設(shè)計了。
并且無論是前后端之間，還是前端和后端各自內(nèi)部的工作。
如何開始
前面說了一大堆，都是成為全棧之后的好處和所得。
那么，如果你也有這個計劃，你應(yīng)該如何尋找一個機會，或者創(chuàng)造一個機會開始呢？
從一個純粹的前端轉(zhuǎn)到后端，并不僅僅是技術(shù)棧的遷移，還包括思維視角的轉(zhuǎn)變。
首先，我們得確立轉(zhuǎn)職的原因：
主觀上
興趣學習
成為一名全棧開發(fā)
成為一名TL
客觀上
項目需要
市場需要
如果僅僅是項目需要，那機會已經(jīng)送到眼前，相信一般情況下，項目上會給你時間和精力專門從事學習，并且還有很多機會直接進行開發(fā)，剩下的只是效率問題。
但如果沒有客觀的條件支持，那么我的處理方式是，找一個你感興趣的APP，去思考它是如何實現(xiàn)這些功能的，然后嘗試著自己去實現(xiàn)，例如小紅書，微信等等。
用一個項目和實踐來承載你的學習，這樣子，就不僅僅只是看看文檔，并且練手的時候順便分析學習了一個成熟產(chǎn)品，也不用耗神在創(chuàng)造技術(shù)的應(yīng)用場景上。
再接下來，確定你要點哪些技能點。
從興趣，市場需求，各個方面，確定語言，確定框架，然后最好跟著官方文檔進行學習吧。
上面分享的模塊化知識和roadmap網(wǎng)站在這里就非常有用。
或者跟著某個學習視頻來進行學習和練手，但是會有幾個問題：
講解的技術(shù)點不一定是官方最新建議的
一般這種視頻進行的練手項目都很簡單，不能完全應(yīng)對真實的使用場景
學習方式
學習需要區(qū)分了解和使用
在這里，我將知識點分為三類：
知識類：這種類別的知識我們需要的是記住，例如我們看到狗就知道他是狗，例如我們知道我們需要用NodeJS去運行我們的應(yīng)用。
這類的知識主要在于主動獲取并記住理解它。
技能類：這種類別的知識，就是唯手熟爾，例如我們需要熟練地使用JS中各種語法特性，我們知道拆分數(shù)據(jù)需要用哪個函數(shù)。
有一些知識起初是知識類類的，當我們知道了解后，但是一旦你運用到實踐當中，并且越來越熟練，就證明你徹底掌握了這項技能。
索引類：這種類別的知識，是技能類退而求其次的產(chǎn)品，有些技能或者方式我們并不需要掌握的如此熟練，但是，我們是知道有這種方法存在的，在需要精確的書寫實踐它的時候，再去查閱就行了。例如π的前30位數(shù)字，例如八皇后的算法。
而針對不同類別的知識，我們采取不同的學習方法。
針對語言的學習，重點在于練習，是我們需要不斷使用和磨練的技能：
數(shù)據(jù)類型
數(shù)據(jù)結(jié)構(gòu)
函數(shù)的定義和使用
線程
對于我而言，學習JS的時候，對應(yīng)著OC，或者Swift的一些語法結(jié)構(gòu)，會學習的很快。
在這里其實也可以進行各種模塊化，例如數(shù)據(jù)結(jié)構(gòu)其實已經(jīng)比較恒定，在不同的語言中，字符串、HashMap、數(shù)組、Decimal都有各自的處理方式方法，只是名稱不同而已，實現(xiàn)的功能是一樣的。
再比如，無論是什么語言，都需要進行函數(shù)調(diào)用棧的管理，只是實現(xiàn)方式不同罷了。
而一些特殊的地方，例如JS中的類型解構(gòu)，也可以找到對應(yīng)的概念去理解，例如Swift中的元組。
針對框架，重點在于對控件的使用和對其文件組織方式的了解。
我們根據(jù)需求和興趣選擇某一個框架后，在這個框架中，構(gòu)建運行應(yīng)用，使用其提供的工具進行需求的實現(xiàn)，例如在NestJS中使用TypeORM或者接入Kafka非常方便，它使用module-controller-service的方式來組織文件。
在上面的陳述中，我提到可以選擇一個成熟的APP進行仿作練習，在這個過程中，使用TDD，并且使用ChatGPT來進行結(jié)對編程簡直是絕佳的選擇。
TDD可以幫助我們快速了解框架，語法和API的使用，而結(jié)對編程能夠幫助我們更好地了解它為什么這么寫，為什么能夠適用這個場景以及獲取一些經(jīng)驗，尤其在有了chatGPT之后，就算沒有一個大佬或者共同學習的小伙伴跟你結(jié)對編程，但是我們依然可以假裝在結(jié)對編程。
寫在最后
在這快一年的時間里，我接觸了PHP，Typescript，React，React-Native，最近開始研究研究ES的標準，從一名iOS純開發(fā)慢慢轉(zhuǎn)型到后端甚至全棧，在這個過程中不僅僅是提升了自己的技術(shù)能力。
更多的是了解了不同崗位之間思考的差異，能夠更好的作為TL拆分需求，跟各個崗位的同學們進行溝通。
并且，經(jīng)過發(fā)現(xiàn)總結(jié)后，又提升了一點點自己快速學習的能力。
現(xiàn)在只是想寫出來，和大家共勉，其中當然有很多不那么恰當甚至錯誤的理解，也希望能夠得到大家的指正。
如何成為一名全棧工程師？這不，機會來了！從《研發(fā)效能（DevOps）工程師》認證開始！
【端到端的研發(fā)效能】成為高級管理者的必備技能！
五期班10月20日開班啦！掃描下方海報二維碼，立即報名，考取職業(yè)技術(shù)證書，擴展職業(yè)發(fā)展與晉升之路！