親身經歷:如何在高中畢業時成為一位軟體工程師?

想當 coder 嗎?高中畢業就馬上成為軟體工程師的作者告訴你,並沒有想像中那麼難,學業與工作之間只要溝通好反而還相輔相成!
評論
Photo Credit: Shutterstock/ 達志影像
評論

本文為作者投稿,經 INSIDE 編審後刊載。作者 Mencher 岷錡,目前正在新創公司中擔任全端工程師,也正深入探究微服務與 Kubernetes 的開發。過去曾擔任第七屆梅竹黑客松總召、Hackathon Taiwan Junior 創辦者,致力於推廣黑客文化的開發精神,並持續提倡科技跨域的整合實作。

繼上次在梅竹黑客松的小型分享後,決定好好寫篇文章,將這段提早啟程的工程師人生撰寫下來,也希望能給將要畢業的高中生、想轉職工程師的挑戰者一些幫助!

這篇文章適合誰

  • 高中要畢業,準備踏入資工領域,然後想先做大事的你
  • 想要轉職工程師,正在探詢方向的你
  • 正是一位 CS 學生,想看看我的工程師養成學的你
  • 有閒,也願意一同分享,自己跳級打怪故事的你
  • 純粹路過,想看看這段故事的你

你是怎麼在高中畢業成為一位工程師啊?

這句話基本上是每位遇見我,得知我同時是一位資工系學生,也是正在軟體界開發的工程師時,會先拋出的疑惑。

老實說,我也很意外,因為這並不是一開始所預想的計畫。

而當我嘗試細數這些歲月,慢慢從 Junior 升為 Senior ,並正讓自己邁向 System Architect 的過程中,回頭看當年高中畢業時的衝動,我反而覺得「高中畢業躍升工程師」只是這段歷史中的一個事件,反而工作前的準備與工作後的養成才是最重要的。

我發現,如果沒有工作前的一些前置準備,我將無法有充足的知識與能力承擔起工程師的職位,也沒有管道。而若沒有工作後的個人持續養成,我則很容易被有實力的後進與快速迭代的技術中被淘汰掉。

也因此,以下我將和大家分別談談我的一些準備與養成,希望帶給讀者們一些幫助。

獲得工作前的準備

有一種做不到,是自己覺得做不到~

基礎的英文閱讀能力

英文,我想基本上是踏入軟體開發界的標準配備。但是並不需要到強大的聽說讀寫能力,像在考 IETLS 或 TOFEL 一樣,除非要去美國工作 XD。基本上有基礎的閱讀能力就完勝了。

在後續工作歲月中,每當發現一個新的開發概念,或在查技術文、Bug 時,首先映入眼簾的通常都是英文。在工程開發界中,文件 ( Document ) 通常在你嘗試調用某個機構提供的服務,或想用某個開源專案時,必定需要閱讀的篇章,而這些通常都是英文。

舉個工程師時常發生的故事作為例子:今天你在開發某個 feature ,看到爆出了 Bug ,頭腦想一想發現找不到解決方案,於是你將 Bug 貼到 Google 上查查,發現看到 Stack Overflow (一個問問題的網站) 有人解決過,點進去後發現滿滿的英文。

如我過去想查某個技術怎麼用時,都希望找到繁體中文的解說。而很快就會發現繁體中文找不到,就會看看簡體中文的解說。而很快就會發現簡體中文找不到了,就會需要看英文文章,看久後以後自然都只看英文了~

工作前很會寫程式嗎?並沒有

首先要先強調,我在工作前的寫程式能力,並不精熟。而硬生生學寫 Code也太無聊了,所以我通常都找有趣的範例當開端,順勢學得一門知識。

最早是從國二開始,想在暑假期間找個目標達成,就去書店隨意買了一本 C# 基礎入門,照著書中的範例做了一個紅綠燈,看到程式跑起來就很開心。

之後高中創辦資訊社後,隨著老師 C++ 的教材慢慢學,但也是學的很淺,連 Linked List 、 OOP (物件導向) 都不清楚,也沒有參與過競技程式、比賽的訓練。

畢業前夕,和國文科秀雯老師合作一個科技跨域的教案,「用程式進行紅樓夢文本分析」,因為題材有趣,我順勢補足了很多自然語言學習的知識,我也意外和白先勇作家有了一次餐敘。

儘管程式背景能力不充足,慶幸入職的第一個專案是前端,使用簡單好學(High-Level Language)的 Javascript 與 Vue.js 框架,我憑藉著所擁有的開發能力,並隨著在多年的 Google 查資料、看各種文章,及系上更專業的訓練後,慢慢補足了專案開發的實力。

「老闆,來點寇汀吧」是我對前端感興趣的開始,也許你也可以看看:

而在 Codecademy、Udemy、 Hahow 線上課程盛行的現代,精熟一個易入手的 Javascript、Python 語言不再是件難事,能做到的事也足夠支撐你成為 Junior Engineer 了,也建議大家可以嘗試看看。

參與社群

參與社群,幾乎是主導了我近期人生的軸線。不論是參與別人主辦的社群,或是自營了幾個黑客松社群,我皆在過程中遇見了人脈、接觸到了大神、學得了近期開發潮流。

我在高中時期,首次接觸了科技社群 Hackathon Taiwan,而當時的我近乎零基礎。抱著一股衝勁,我還是參與了一場黑客松,聆聽著一場場完全聽不懂的技術短講,並試著和大神工程師互動、交流,找出自己之後能回頭自學的道路。

接著,我持續抱著不怕死的個性,將我所見所聞的黑客松社群,帶回我的高中學校,創辦了專屬全台高中生參與 Hackathon Taiwan Junior 。我也因此和當時 Hackathon Taiwan 的社群前輩有更多交流與討論,這個鏈結也促成了後續我首份工作的誕生。

工作這麼多年後,我還是能時常在社群裡和別人的互動交談中,討論到很多技術面的開發與進展,也促使我體認到自己還不足,並找出能持續精進的空間。同時,我也在自營的梅竹黑客松中,試圖轉型並實踐我所想像的科技價值,也期望讓更多不同層面、背景的人,能有不同的角度切入黑客文化的精神,讓科技得以締造出更多附加價值。

而社群所醞釀的價值仍不僅於此。筆者撰寫時下,全台正面臨口罩分配數位化的議題。這次由數位政委唐鳳,所引領的公私協力、開源開發的精神,讓民間的公民科技社群也投入很多開發能量,進行口罩的數位追蹤。

簡言之,參加社群只有好處,沒有壞處。

人格特質

這些年在社群界與大學中,遇見了許多非學習體制內、跳級的工程師與大神,發現這些人都有些共存的人格特質,譬如:

  1. 好強,對自己要求高,且需要用成就感維生
  2. 敢做夢也敢挑戰,而且實踐度很高(重要!)
  3. 懂的時常評估自我能力與資源,並持續精進

能成為一位有成就的人,基本上是每個人願望。不過有願望後,會付出行動的人,通常都會少 50 % 。而付諸行動後,得以達成最終目標,往往只剩個位數 %。我認為實踐力,是上述的道路能否成功的最大因素。找出適合自己的方向,並擁有高度實踐力,是肯定會成功的,因為我遇到太多強大的工程師是非傳統體制的。

我的第一個專案: giloo 紀實影音

獲得工作後的養成

保持學習的心,不然就要被淘汰了

Keep Learning : 技術的快速迭代

加入過產品工程開發的人,大部分應該都相當熟悉 Scrum,對於產品進展的快速迭代應不陌生。

我在工程開發的這幾年,也發現了技術的迭代不容忽視。以下便是一個鮮明的例子:

在傳統,如果做商業邏輯的,可能選用 Node.js 作為服務核心,並在單體式架構下持續開發邏輯,務實一點的可能採取 MVC 、MVVM 等架構。

而就在自己坐穩了後端服務後, Microservice 微服務出現了,這個詞彙在近 3 年成為開發界顯學,很多大牌公司 Google 、Netflix 等跳下來實踐後,也從開發端到維運端一次性顛覆,傳統熟悉單體式開發的工程師也不得不重新理解。

緊接著談到維運,Kubernetes 又是新一門顯學。維運人員(或 Devops Team)開始著重 Containerize 服務,如果是 Machine Learning 的服務就要想想如何掛入 CustomResource 和 Controller,如果是 microservice 就要一起想 Service Mesh 等機制……

上述所說的這些,最想強調的便是工程師的學習是永無止盡的。當我們嘗試坐穩某個技術與稱霸,停止學習的那一刻,我們就是等待被淘汰的人。

而我認為,保持吸收新知的習慣,特別是英文文章,是追上開發世代最有效率的方式,這也是我上篇所述英文的重要性。

基礎學科的建立:Algorithm、Data Structure、Operating System

我認為,成為一個工程師並不困難,但成為一個好的工程師比較困難。

而 CS 界的三大主科: 演算法(Algorithm)、資料結構(Data Structure)、作業系統 (Operating System) ,是從普通工程師邁向專業工程師的基本配備。

筆者剛開始工作時,一個主科都沒學過所寫出的 Code,到後期全部主科都學過後的 Code ,長得樣子是完全不一樣的。

而若筆者是從 Javascript、Python 入手的工作,或許會隨著公司業務需求或升級 Senior Engineer,開始需要對部分服務做性能調教,這時就會開始思考轉向 Golang 或 Rust 等語言。而尤其撰寫上述語言時,沒有基本 Operating System 概念肯定是會處處碰壁的。

受惠小公司:我得以學很廣,並決定深入一個研究

工程師最快練功的方式,應屬直接投入一個專案。因為各式各樣的開發進程 Deadline 、與別跟薪水過不去的心態,會促使自己更快掌握技術,完成開發。

而能參與到這麼多不同類型的開發,仍然起因於我待在新創圈中,所以能在短時間學得很多開發經驗。

受惠於新創公司,開發任務並未分配的很清晰,我在入職的半年後轉型到後端領域,以 Node.js 繼續做商業邏輯的開發。從 Authroization 到 Authentication ,參與過 Line Bot 、Streaming 、Payment System 、 E-Commerce 的調教與重構。也在不同專案中調用、學習了不同 Database ,從 SQL 到 noSQL (Graph Model \ Tree Model) 之類的。

遵守 T 型人才的法則,不但要讓自己實作經驗很廣,還要有一門特別精深。我在工作兩年後,我重新投入了 microservice 開發,並回頭學習 Kubernetes,後者也成為了我大學最終專題的研究。(也因此,這也是先工作所帶給我的益處,因為我能以個人職涯為導向,更加確定自己想研究的項目。)

但小型新創仍有它無法完善的壞處,而關於小公司與大公司的好與壞,下面這篇好文值得大家讀一讀:

常見的 Q & A

這些年很多人問我一些問題,以下是我嘗試整理的資訊:

1.一個未接受過專業資工訓練的學生,如何踏入工程師行列?

這個問題我會先拆成方向和資源來談,而不同的方向會需要調用不同資源。

方向是指,你想先用最易入手的方式,成為工程師嗎?

如果是,以前端開發為優先選項,學習 Javascript,並找一個前端框架(如 Vue.js)精熟,你很快就能成為一位 Junior Engineer 了,也有空間跨足後端。(不過是最初階的,光是前端就分有好前端與壞前端,還是需要後續的持續養成)

如果不是,你想走入資料科學、人工智慧、機器學習等專業領域,我認為就不是這麼容易下手,可能需要透過大學開出的 Mooc 、線上專業課程,或一個完整的資工系訓練基礎學科後,才有機會。

而資源是指,你要透過哪些資源培訓自己,達成目標。參與科技社群、撰寫 Side Project 、加入實習、Review 開源專案的 Source Code ,都是很重要的資源,也務必貼切自己的職涯方向。

2. 學業與工作之間,是否可以兼顧?

以我從高中畢業的暑假開始工作,至今已經 2 年半了,並其中參與了一年梅竹黑客松總召的經驗來看,懂的利用時間,並能和公司做有效溝通,不但不會有衝突,反而會有加乘效益,因為能更加知道自己要修什麼課、專題要研究什麼,如上方所述。

以上就是我試著回顧提早工作的工程師旅程,想與大家分享的個人經驗。如果讀者有任何想法,也歡迎在底下留言跟我分享,也希望我的文章能給讀者們一些幫助!

責任編輯:Chris
核稿編輯:Anny


開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?
評論
評論

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

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

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

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

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

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