我是怎麼靠自學成為工程師的:懂原理比應用更重要

直到現在我才明白,就算這套語言有著完美的邏輯設計,但一台超跑還是需要厲害的車手才能發揮潛力。也許是因為我自學,不清楚我的能力到了哪裡,也許是因為騙子症候群,也許我覺得不正規的自學,感覺像是作弊。
評論
評論

原文為《How I Became a Programmer. And When I Started Calling Myself One》,作者為 Auto-acc IT 專員 Kurt Rohlandt ,Inside 獲授權編譯。

好幾個月前我就開始想寫部落格了,就像其他人一樣,我迫不及待地希望能為世界貢獻,所以我申請了一個網域,安裝了最新版的 WordPress,然後開始跟 CSS 奮鬥,想把它改造成最適合我的風格。

等到我終於準備好,面對一張擋在我和世界間的空白頁面和閃爍的游標,卻什麼都想不到。我在腦袋裡按了 F5 重新整理,接著又狂按 Ctrl + F5 ,檢查了一遍腦袋的連線,沒有問題,但還是什麼都沒出現。最後我按了 F12 開啟開發者工具,發現那裡也一片空白,只看到狀態代碼:HTTP 204 —— 無內容。

這並不是因為我懂得太少,或是我找不到有趣的例子,想要的話我也是可以信手捻來一些教學文的,我只是不知道該從哪裡開始。

我知道自己想寫一些問題的實際解法或不同觀點,同時給程式新手和老手看,但該討論什麼樣的問題呢?比較內建陣列函式和迴圈的的各項指標,看看該求效率還是易讀?簡介 MVC(Model-View-Controller)、寫 jQuery 外掛教學、列出常用的 SQL 指令,或是單純談論應用程式建構的心得文?想到這裡,我的腦袋就開始進入無限迴圈,所以我只好強制終止思考,把寫作這件事擱在一邊,回頭去處理手邊的程式碼。直到兩個月前,Medium 這個平台吸引了我的注意,才決定要從這裡開始寫作。

(Photo Credit: hobvias sudoneighm)

騙子症候群:我根本沒有資格當工程師

然後我看到了 Jeff Smith 寫的一篇文章,題目是「認識並解決 騙子症候群」(Recognizing and Dealing with Impostor Syndrome),那篇文章提到,維基百科對騙子症候群(Impostor Syndrome)的定義是:

騙子症候群是一種心理狀態,當事人通常無法將自身的成就內化。

Jeff 對此的解釋則是:

簡單來說,在某領域優秀又成功的人,有時會認為自己配不上這份工作,或任何正面的成就和獎勵。他們認為自己的成功不值一提,同時持續擔心自己無能勝任工作,雖然現實狀況根本相反。

剎那間我發現自己好像有騙子症候群,這些症狀非常眼熟。我之前從來沒聽過騙子症候群,說得更精確一點,我根本不知道除了我和辦公室角落那個超級內向的女生以外,世界上還有其他人也有這種感受。

到了這裡,先容我自我介紹一下,我在目前的公司已經待了一年,你可以稱我是領導、資深,或者主任工程師,我前一份工作做了四年,在更早之前,出於熱情和不想自己處理麻煩事的懶惰,我自學了程式。幸運的是,也有很多人跟我有相同困擾,很多使用者踴躍訂閱我寫的程式,讓我得到投資並成立了一家公司。

經過幾年,我在一個專業的小圈子裡面成了德高望重的成員,裡面的人都在自己的領域有相當的專業和權威,我透過這個圈子也經手了許多工作,其中很多根本是不可能的任務。我們也會互相幫忙解決問題或交換意見,很多新手工程師異常地尊敬我的程式碼,這讓我有點不習慣,畢竟我才剛開始有自己是專業工程師的自覺,我也不習慣從學生變成老師。這一切都提醒著我,不久之前自己還什麼都不懂。

我通常幾分鐘之內就能解決漏洞,我可以一眼看出哪裡需要修改,有時候我寫出來的解既簡單又優雅,讓我可以佩服自己好幾天。我知道自己很聰明,朋友也常在酒過三巡後開始瘋狂誇獎我:

他是天才,他的程式都是自學的!你應該看看他寫的東西。

我通常會回答:

我可能滿聰明的,但不是天才,我只不過是編寫前人發明的語言,他們才是天才,我只是照著使用說明走而已。

這全都是我的真心話,我並不是開拓了一片未知的土地,我只是跟著地圖走,你覺得我聰明,可能是因為這份地圖是用函數寫的,看起來很難懂,但它終究是一份地圖,我看著這份地圖,知道何時該抄近路、何時該橫越河流,讓這趟旅程更快、品質更好,但我還是遠遠比不上發現公園的那個人。我連寫了一段還不錯的程式都不敢居功,把功勞都歸給了設計這套語言的人。直到現在我才明白,就算這套語言有著完美的邏輯設計,但一台超跑還是需要厲害的車手才能發揮潛力。也許是因為我自學,不清楚我的能力到了哪裡,也許是因為騙子症候群,也許我覺得不正規的自學,感覺像是作弊一樣。但透過這份自白,我認為相當適合作為一系列工程師心得的起點,了解從何處開始你就成為了真正的工程師。

你可能有注意到,我盡量避免使用「開發者」這個詞,因為我個人覺得這個詞太模糊了,常常產生誤解。另外,很多文章都在探討有資訊工程學位和自學的工程師孰優孰劣,但我並不打算在這裡談論這個話題,因為對我而言,程式之美便是你永遠無法習得全部的知識,我們生存的世界、使用的工具和準則都經常在變動演進。而我認為這可能就是騙子症候群的成因之一。

最終你得抉擇,究竟是想要樣樣通樣樣鬆,把寫程式當作當作興趣,在工作上頂多就是能幫你管專案或開規格;或者是你想要專精某樣領域,時時更新該領域的最新應用,直到你專精的領域被淘汰,最後工作內容只剩下維護舊程式碼。

(Photo Credit: Jens Lelie)

框架泡沫扼殺了工程師幼苗

所以(軟體)工程師到底是什麼?工程師的定義當然就是:

寫程式的人。

但會煮飯不一定就是主廚,寫了這篇文也不會讓我變作家。一開始你就像「薛丁格的工程師」,在成為工程師之前,你是也不是工程師。

我覺得現在整個程式界正處於一種「框架泡沫」(Framework Bubble)中,許多的資源和精力都聚焦在開源和頂尖的框架上,而專精一項程式語言的使用及討論就成了沒人關注的大盲點。幸好我自學程式的年代,框架還沒有如此氾濫,我也不會看到這樣的敘述:

Ruby 是新一代的 PHP。如果你想玩玩可以用 Python,但想要認真一點你最好在 Heroku 或 AWS 用 Node.js ,NPM 適合快速開發,用 socket.io 從 Mongodb 建立 REST API  然後最好用含 Material Design 模板的 Angular app ,不要忘了把它推送到 Git 還要用上 Gulp ,否則這就是糟糕的程式,會讓你的使用者痛不欲生,而且你還會因為玷污了神聖的程式開發,遭到流放。

如果我當時看到前 5 篇搜尋結果都是這樣的內容,我大概就會早早放棄,當個無業遊民或是躺在沙發上尋找心靈啟發。

先別急著攻擊我,其實我很愛框架,因為它們可以讓小程式也能在短時間內擁有大量功能,不用重複 debug 和從頭架構,也不用檢查一堆基本問題。框架幫我們省去大把時間和成本,降低架設網站和應用程式的門檻,讓更多人能將自己的產品分享給世界,達到最有效率的成長和創新。框架也能讓初至中級的工程師開發出實用、架構嚴謹又整齊的程式,你才不會在假日接到求救電話,說新手工程師把你先前建的穩定架構破壞殆盡。

雖然降低門檻大概是框架最大的優點,卻也是最大的缺點,我覺得它會扼殺工程師的幼苗。我認為在沒有全盤了解以前,就不該使用那個框架,你應該要有能力重寫或至少重製這個框架,或者擴充、改造,甚至最重要的是 debug。框架和程式庫對正在學寫程式的人來說可能非常危險,因為你會把他們和基礎程式語言搞混。jQuery 便是常見的例子,我見過無數的人學會 jQuery 就以為自己懂 JavaScript,我自己偶爾也會把 jQuery 和 Vanilla JavaScript 弄混,都是因為我在熟悉 JavaScript 前先接觸了 jQuery。

我花了好幾年改掉這個毛病,因為我在學程式語言的語法前,先學了框架的語法,更因為我習慣了 jQuery 的功能,像是 DOM 的操作和動畫之類,而且丟臉的是,我以前也會大言不慚地說「有了 jQuery,誰還需要 JavaScript 啊?」

那個時候我應該要專心研究語法、設計模式,最重要的是要去理解物件是 JavaScript 的靈魂。我應該要學習製作物件原型,去充實重點觀念,像是「用物件導向的語言寫程式,不代表你就是用物件導向的方法寫程式,」等等。結果我都浪費時間在把按鈕弄得一團亂,做一些累贅的隱藏、滑動、彈出、旋轉動畫,把網頁搞得很花俏卻一點也不實用。

(Photo Credit: Joe Loong)

我的工程師之路始於一套會員卡系統

我一直都對電腦很在行,8 歲的時候我就已經是 Windows 的進階使用者了,我也知道自己有一天一定會開始寫程式,不過命運的捉弄讓我很晚才開始寫程式,當時我甚至有好幾年過著沒有電腦的生活,而且那時候南非這裡網路不普及,沒多少人聽過 Google,而我至今還沒在圖書館和書店看過像樣的程式相關書籍。

2008 年的時候我終於有動力和機會學程式了,當時我在一家超市當經理,那間超市在本地算大,不過也只比得上美國 Walmart 或 Target 商店的一個攤位而已。當時店內有 18 個櫃台,而我是最年輕的經理,所以麻煩事自然都落到我身上。為了一項老年人優待方案,結帳時我得用一隻鑰匙打開鍵盤,登入電腦,經過一堆複雜又不人性的操作,才能順利使用這項折扣,熟練之後我只要 30 秒就能完成以上流程。

我們店附近有 3 間養老院,所以很多老人會光顧,而我時常得在折扣櫃檯和收銀櫃台間跑上跑下。當時我壓力很大,每天工作的內容就是在樓下結帳、陪熟客長輩逛超市,期間又要不斷衝到樓上兌換折扣,我覺得自己要不是年紀輕輕就提早退休,不然就是哪天在店裡崩潰,還被拍下來上傳 YouTube。

然後我就想到了,應該要在店裡安裝一台自動折扣機,我們發優惠卡給這些退休老人,他們只要輕輕感應一下,就能自動折扣。於是我馬上 Google 了「如何寫程式」,一個禮拜後就做出了基本的程式,3 個月後店裡就成功誕生了一套老人優待系統。優待卡的消息流傳得很快,店裡的生意變得很好,年長的客人多到我們得另外買三台輪椅,讓他們行動不便或逛得太累的時候可以用。不久之後我又加入了一般會員卡功能,並將這套系統發展成了南非最早的賣場會員卡系統之一。

到這個階段,不會寫程式的人會將我視為程式達人,但儘管我確實可以寫出一套程式,卻還稱不上工程師。我的系統簡陋又粗糙,是我從網上一知半解地參考了許多語法段落拼湊而成的。我基本上不知道自己在做什麼,而且也不知道背後的原理,我選擇不去質疑背後的問題,就像那句俗話一樣:「如果它沒壞,就不要修它。」

(Photo Credit: Sai Kiran Anagani)

當寫程式變成正職:邊做邊建立觀念

沒過多久我就找到了投資人,接著當上了工程師的職位,但我竟然不是去做一些 Visual Basic 相關應用,而是被派去做網頁。我的概念作品之後雖然還是經過別人修改,但也意外發現我拙劣的 HTML 和所見即所得軟體的功力,和駐站的 ASP Classic 工程師比起來不算太差。當時 Google 真的救了我一命,兩週內我就熟悉了 HTML 和 CSS,再過了兩週我已經會了基本的 JavaScript,開始接觸 jQuery ,而且學會了 CSS box method。

一年後我已經會了 SQL、ASP Classic(VB Script)而且可以做出有管理員登入介面的,還不錯的網站。我開始用閒暇時間寫自己想要的程式、做一些教學,我開始用 canvas 做一些小遊戲,然後終於能夠不靠 Google 寫出程式或網站的 80% 。大約從此刻開始,我認為自己總算是一個工程師了,不是因為我的技術有多強,我那時連中等程度都沒有,而是因為我某種程度上可以了解(物件導向)編寫的概念和潛力。

別誤會了,我不是設計模式(Design Pattern)大師,我當時幾乎不知道它們的存在,但我就是在沒聽過「設計模式」的狀況下,做了一堆類似的東西。我會在腦袋裡面有個概念,可以擬定程式該怎麼寫,而不用真正打出一堆指令,然後再東拼西湊讓它可以勉強運作。我不只會宣告陣列,我還知道陣列是什麼、可以拿來幹嘛、要用什麼方法、這些方法有什麼效果。一旦你透過像這樣的方式理解背後的觀念,學新的程式語言就容易了 100 倍,因為你知道你該做些什麼,也知道你可以用它來做什麼。

搞定這些,剩下的就是一些語言習慣、輸入、輸出和語法了。這代表你能超越這套程式語言,不再受限,你可以建構穩定的應用程式,還有優秀的整體邏輯和設計,這些都是你在語言語法裡面找不到,而要透過一些訣竅、追求完美的心態,或者花時間獲得經驗才能學到的。這些就是我所認為,凌駕於語言或框架之上的技能,也是真正的工程師必須具備的條件。

《延伸閱讀》

想「轉行」靠寫程式吃飯嗎?一個自學程式語言幾乎將自己逼瘋的親身經歷 – 軟體工程師 Quincy Larson

為什麼工程師總是喜歡在三更半夜寫程式?

下班後,堅持自學有多難?

美國工程師的台灣夢

軟體工程師從優秀到卓越的進化之路

大神工程師教你怎麼練就「 coding 速度快、 bug 數量少」的境界

歡迎加入「Inside」Line 官方帳號,關注最新創業、科技、網路、工作訊息

好友人數

蛻變敏捷開發組織並不難! AWS Amplify幫前端工程師從雲端快速建立REACT程式

台灣企業勢必需要明確轉型策略,搭配適合的雲端工具作為入場券,一來降低數位化門檻、二來減少摸索資源的浪費。
評論
shutterstock_1451794139.jpg
評論

打造敏捷開發流程、加速前後端工程師的協作效率,是許多企業在面臨疫情之後,認為亟需將彈性元素納入為企業文化當中。雲端運算服務領導業者 AWS 台灣,觀察到前端工程師主要負責處理最貼近用戶的 Web、行動應用程式,但他們往往需要與後端團隊合作過程,遭遇耗費大量討論時間,才能處理使用者介面事項。

為了降低前後端的溝通成本,有些前端工程師在掌握介面管理能力之後,開始橫跨到後端的伺服器、資料庫開發經驗,甚至進一步培養技能,成為能負責測試、安全、效能多面向的全端工程師。

有的人會透過 Side Project(利用業餘時間開發有興趣的專案)或參加 Hackathon(黑客松)方式,運用 AWS 雲端工具嘗試自行擴展後端,並建立簡單易用的工具程式。究竟,AWS 平台提供哪些資源幫助前端工程師擴展更多元的技能樹?

掌握入門教學!前端工程師如何將 REACT 程式快速上雲

前端工程師運用 AWS Amplify,快速在雲端建立 REACT 應用程式

事實上,AWS 的入門課程指出,運用 AWS Amplify 在雲端建立 React 應用程式及服務集,只需五個學習歷程,包含建立 React 應用程式、初始化本機應用程式、新增身份驗證、新增 API 和資料庫、新增儲存體。如果想快速了解 REACT 程式快速上雲的方法及示範教學,本文節錄 AWS QUICKSTART 學習資源內容,幫助前端工程師更快掌握重點。

首先,何謂 AWS Amplify?AWS Amplify 是一項全托管 Front-End Web & Mobile 服務,採取無伺服器模式,在後端建立、部署和託管單一頁面 Web 應用程式或靜態網站的 Git 型 CI/CD 工作流程,加速開發過程直接整合其他 AWS 服務。舉例來說,像是整合封裝好的 Library 資源、或運用一些 Components UI 軟體去配置後端,以及利用 Admin 的 UI 做資源上的管理。

透過 AWS 增加雲端技能 在組織發揮你的影響力

AWS Amplify加速Develop、Deliver 與 Manage流程

AWS Amplify 主要優勢展現在三大項工作階段,分別是 Develop、Deliver 和 Manage。Develop 部分可利用 CLI(Command-Line Interface)或 Admin UI 設定後端,使用 GraphQL 或 REST API 設定也是可行的,進而快速建構一個前後端專案。此外,開發者還能搭配 AWS 其他服務,例如使用 AWS Authentication 全托管認證服務,或 DataStore、Storage 等多項 Feature Categories。

到了 Deliver 階段,若是要透過 AWS Amplify 執行 Web Hosting 任務,可拆解出三個流程。首先是將 Repository 與 AWS Amplify 進行連結,這邊可整合 Amplify Console 提供的支援資源包含 Github、Bit Bucket、Gitlab、以及 AWS 的程式碼代管工具 AWS CodeCommit。一旦連結以後,開發者可透過自己的 Configuration,决定在各個不同的 Build 要執行什麽樣的指令,最後再透過 Deploy 方式,幫助工程師進行前端的 Hosting。

在最後一個 Manage 階段,開發者則可利用 AWS Amplify 的 Admin UI,以開啓瀏覽器方式,透過視覺化介面統一管理資源。例如在 Admin UI 介面左側選單,涵蓋 Content、User Management 的區塊,讓參與專案但沒有 AWS Console 權限的使用者,可利用 E-mail 方式邀請使用者進到 Admin UI,進行一些設定或觀看其他相關資源;甚至在 Set Up 區塊還有相關選項,例如要針對 Data Modeling 或 APP User 做權限管理,以及可連結到 AWS 其他服務。

運用開放資源 AWS Amplify Framework,打造高效能應用服務

AWS QUICKSTART 學習資源還介紹到另一個 AWS 提供的開放資源 Amplify Framework,一樣可利用 Amplify CLI 的方式,配置 Web 和行動應用程式的前後端,以及開發者需要用到的服務,讓應用程式更易於構建,並獲得安全、高性能的使用體驗。

Amplify CLI 一樣有支援多個不同 Category,例如較常使用的幾個 Comment Line,像是Amplify Init 指令做初始化或創建幾個不同資源;或是 Amplify Status 指令,隨時在開發過程查看各個 Category 狀態;甚至專案結束後,可利用 Amplify Delete 直接把 Amplify 所創建的資源做一次性删除。另外也可透過 AWS Amplify Client 利用比較抽象化方式,讓開發者直接利用 Component 實現想要完成的項目。

填寫表單 找到適合你的快速上雲服務與工具!

實際示範給你看,設定 React 程式可以如此簡單

假設前端工程師現在要快速部署一項有驗證功能(Authentication)還要搭配 Rest API、GraphQL、Analytics 等服務的應用,如何快速設定 React 程式?在 AWS QUICKSTART 的學習資源後半段,有詳細說明要啟動這類型專案的操作方法。

開發者可以先利用 AWS Lambda Function 結合 Amazon API Gateway 方式,創建出一個 Rest API,到了 Authentication 階段,則使用到 AWS Cognito 的服務,接著針對 GraphQL 需求,可利用 AWS AppSync 服務,以及最後如果有 Analytics 的需求,也可以串聯 Amazon Pinpoint 工具。Amazon Pinpoint 是一項彈性而可以擴展的行銷通訊服務,開發人員可利用 Amazon Pinpoint API 追蹤 Web 使用者的行爲,或是針對 APP 推送、電子郵件、簡訊點擊行為蒐集到具體的資訊。

在這整套流程示範之後,值得特別強調的是,AWS AppSync 是一項全托管的服務,能及時更新,甚至在使用者離線時仍可以持續去創建和修改數據。一旦設備連上線之後,這項應用程式就可重新連線,並接到後端同步數據,達成彈性、自動化擴展或減縮各式 API 的請求。

打造第一個你在 AWS 上的應用程式

AWS 最後強調,Amplify 是相當適合建構出一個靜態 Web、Apps 服務模式,例如說像是打造部落格,或者是一項 APP 內的代辦事項應用等;加上 Amplify 具全托管服務特色,可串聯上述 AWS 在雲端所提供的資源,都能在部署過程加以整合,加速開發流程及效率,並且有效節省開發資源。如果想用低門檻的雲端解決方案,其實前端工程師是能在開發流程更靈活配置資源,甚至為公司的商業、服務模式挖掘出創新價值。

了解更多:AWS 開發者系列