Skip to main content

六角學院 - Node 企業專題班心得

· 17 min read
Thibe

HexSchoolNodeBootcamp

在第一份工作接近尾聲的時候,我正在騎驢找馬,而在確定拿到第一間 offer 的時候,不怕死的我還報名了一個由六角學院開設的 Node 專題實戰班。很順利地,我同時間在 3 月初的時候開始新工作,也開始了企業專題班的 side project 開發,上班學習 Angular;下班畫 Figma、研究新技術、使用 React 進行開發;周六晚上還要小組討論,週日常常要忙著部署新進度,就這樣過了充實的四個月。

專案進程

在這次的 Node 專題實戰班中,我們是北十七組,製作了個募資網站叫做募質部

依據課程的規劃,我們的專案分成了以下七個里程碑,就讓我隨著記憶來跟大家介紹

  1. 題目確認
  2. 專題定稿
  3. 進修技術
  4. API 規格
  5. 環境建立
  6. 角色端建立
  7. 簡報階段

題目確認

在題目確認階段,是我們組第一次也是唯一一次的實體見面,我們經討論後,將範圍縮小到人力資源網站和募資網站,最後經由投票將題目訂為募資網站,參考了許多知名的募資網站,包括嘖嘖、挖貝、kickstarter 等等,開始規劃專案會有的角色,例如:使用者、會員、募資團隊、後台管理員,從這些角色的去完成他們的使用者故事,未來專案也會依據使用者故事去一一實作。

題目確認完之後,我們在一次開會中將每周開會的時間訂為每周六的晚上 21:00 ,也在不久之後決定了我們的專案名稱為: 募質部,題目理念:「募質部」的品牌理念是透過眾人的力量,在募資平台上支持優質的專案或企業,一同創造更美好、更有品質的生活。

專案定稿

確認完題目之後,我們初步了解了我們想要做出的募資網站,會有三個角色端:提案者、使用者、管理員。接著,就會開始著手網頁的設計稿,這也是許多組員們第一次使用 Figma 去繪畫網頁設計圖,我們的分工蠻明確的,分成三組去進行繪圖,加上有組員有當過設計師,所以,在組員們繪圖出來後,可以幫忙進行些調整。

在專案定稿里程碑中,我們組也有先繪製了泳道圖,包括使用者的註冊登入,提案到募資成功或是失敗的流程,主要是使用 Figma 裡面的 Figjam 去做繪製,我覺得要完成簡略的設計圖十分適合。

最後,我們也在討論與合作下,提供了五頁設計稿給專們的設計師去做更細部的繪製,其中包括首頁、專案瀏覽頁、提案頁面,特別的是因為是有專業的設計師的參與,所以說,許多基本的元件、圖片也是事先設計好了,在後面的開發流程中,幫助了不少。

進修技術

每個專案開始之前,我們都先要確定我們此次專案要使用什麼技術,去解決什麼樣的問題、製作出怎樣的網頁,進修技術的里程碑中,通常大家的野心都很廣,會想涉略許多自己沒碰過的新技術,這些新技術像是 Web Socket、Redux、TypeScript 等等,你可能想說這些技術不是有段時日了嗎?你還沒用過嗎?

但實際上,你工作的公司不一定很常開新專案,或是不像是新創公司那樣求新求變,平常也沒有夠大的專案和人手讓你去嘗試加入這些技術,自己的專案好像是牛刀小試,剛好此次的專題就十分合適(講得很像業配~XD)。我個人是在前兩個里程碑之中就感覺自己可能沒有那麼多心力去研究新技術,且自己也還是菜鳥前端,就把重心全部放在前端的技術上面,主要是想碰

  1. Next.js
  2. TailwindCSS
  3. Node.js
  4. MongoDB

上述是回顧自己寫的預期學習內容,發現自己還是有點心想碰後端,但從後面完成專案來看,其實完全是心有餘而力不足。在進修技術里程碑之中,其實前後端分工差不多就會慢慢成形,我覺得同時間應該都要開始放心力在接觸新技術,像是我有撰寫一些文件去了解 Next.js 和 TailwindCSS ,這些開發前準備幫助了我在開發階段比較好上手,較快進入到開發的節奏之中。

API 規格

API 規格里程碑中,開始針對畫面需要什麼資料去做發想,來規劃 API ,我們算是規劃得很詳細,切分出很多 API ,同時間,負責後端的組員,將資料庫的種類先建立好,分門別類,我們的資料大概分成了十個類別,主要的是

  1. 使用者
  2. 團隊
  3. 專案

其他資料庫雖然有做初步的規劃和開出 API 要進行的操作與回傳的資料,但並沒有時間去開發。我覺得比較可惜的地方是花在非必要的 API 規劃的時間有點多,畢竟我們其實最後只大概完成其中的 30% ,而這部分該如何改進呢?

我想是需要較有經驗的後端開發者,加上一些領袖的個性,依據他的經驗設計基本款的資料庫,決斷地切斷不必要的規劃,選擇核心功能去規劃討論。當然都是後話,每次遇到的情況不會相同,失敗得到的經驗會幫助你修正得更快。

環境建立

環境建立的里程碑是我負責的,好抖~XD,在前面規劃了兩個月多一點的時候,進入到了專案開發期,由於我們組別相較於其他組別晚開發,所以有許多組別已經先開始,也將開發環境建立好可以參考,因此我在此階段參考了幾個組別,去完成我們的專案建置,組員們討論是分成前台、後台、後端的程式資料夾,主要是先建立好前台資料夾的環境,我加入了

  1. ESLint
  2. Prettier
  3. Tailwind
  4. Husky
  5. cz

印象深刻的是,我那時候在週六討論前,花了一兩天的時間去研究與準備 live demo 在週六晚上給組員們看未來要如何開發,在專案的 readme 參考了北十五組,寫入了該怎麼去使用該專案,我們也討論出程式碼撰寫的規則,只是後來開發因為時間與專案規模漸大就變得比較亂。

不得不說,此里程碑可以說是最有趣的里程碑,開始依照設計稿進行開發,第一個任務是完成使用者的登入註冊功能,大家剛開始都還是有點ㄘㄨㄚˋ,我自己也是沒那麼有自信,就算之前有看過網課也實際操作過,在選擇任務的時候還是會從簡單的開始,施展不開。

倒是因為我們組內全部人都沒有後端開發的背景,所以後端的建置也是花了不少時間,登入註冊功能也就以前端配合 firebase 可以完成的第三方登入為主,順利地在里程碑的期限內完成基本的登入註冊功能。之後,就開始了每週分任務開發,前後端激烈溝通的循環。

開發期,會看見每個人都慢慢成長,像是有組員建立好 Material UI 的基本元件讓大家復用,表單套件和文字編輯器套件也是十分俱挑戰性;我也開始學著如何使用 MUI 去做元件,熟悉 Tailwind,部署到雲端;組員在沒有後端的情況下使用 Mock 的資料,後端建立資料庫、調整 API 、部署雲端,就這樣畫面慢慢地出現,加上了功能。

角色端建立

角色端建立的里程碑,是回應一開始題目確認階段的規劃,也是環顧自己組別開發的專案有沒有達到基本的角色端功能,會希望是至少有兩個角色端的功能,以我們的專案來看,最重要的是提案者和使用者,提案者需要先建立好提案,裡面可以有專案介紹、價格、不同方案,而在使用者方面,可以看到提案,去選擇他們想要的方案進行贊助。

我們實際上完成了提案者的角色端功能,而使用者方面有完成到可以選擇方案,但贊助的功能十分粗略,沒有進行訂單的儲存,也沒有時間去處理到物流這一塊,物流的話感覺相對金流來說,可能更為困難些。

最後,因為發表日期剛好撞到連假,讓我們多了些時間去開發,於是我配合後端就加上了後台的功能,可以針對專案的狀態進行改變,算是完成了第三個角色端,也學習了些 table元件的製作,可喜可賀!

簡報階段

一個好的產品,會需要好的包裝與行銷,簡報階段就是要發揮三寸不爛之舌,去極盡所能地介紹我們的專案,然而,我們組別已經氣力放盡,故沒有那麼完整的準備,主要由我們其中一個組員作為發表人,介紹了我們專案的動機,想解決的問題或是完成的功能,使用的技術,加上組員針對自己開發的部分去錄製影片介紹,最後延伸到我們這次參加專題班的收穫,以及未來的展望。

收穫與反思

在這趟四個月的旅程之中,我真切地學習到了一個專案如何產生與進行的過程,好像是個新創公司,但大家本業也不是在此,使用的時間沒有那麼多,花費的精力也不會很大。

我覺得從企業家的角度來看,會想要以最小的成本換取最大的利益,所以才會有些像是我一樣的較缺乏團隊合作經驗的開發者,另一個角度是,若是我夠強,可以選擇更好的公司,也會有更多的團隊開發經驗,第三個角度是,個人的產業選擇,若是選擇接案公司的話,團隊協作接觸的機會會比較少。

之所以會說到團隊經驗的缺乏,是因為我在看許多參加這次專題班的成員,覺得最大的收穫就是獲得團隊開發經驗,我個人也是感覺如此,像是之前雖然知道 git的基本操作,也聽過 Git flow,但實際上我在第一間任職的公司開發,也沒有按照 Git flow 去進行程式協作。綜觀這次專題班,確實許多組別都以 GitHub flow 進行開發,也就是相對 Git flow 來得簡單,但是確實有版本控制的觀念進去,以減少程式錯誤的影響性,也增加團隊間的協作產能。

除了 GitHub 上面的協作,從一開始每個組別就會透過 Discord 日常交流和 Notion 筆記軟體來去做每個里程碑的紀錄,每週也都會有會議紀錄,分享著彼此的進度、遇到的困難,統整後和專題教練進行回報與討論。

最主要的是週六晚上的線上討論,從一開始專題規劃,技術研討到 API 規劃,以及開發時期的一起解 bug ,再再顯示團隊間溝通與協作的重要性,感謝一路上互相製作專題的組員們!!!

每項技能與成就都是站在巨人的肩膀上完成的,依照較完整的里程碑規劃走,我們才能完成此次的專案,而學習到的技術也是,透過閱讀該套件的 document 和使用 chatgpt 問答,搭配著時下的趨勢工具,使得開發變得比較順遂,隨著時間與經驗的累積,我慢慢地看見初階工程師的日常,開發功能與解決 bug ,其中不變的是遇到問題,要試著善用手邊資源去研究與解決問題,每次的解方雖不是最佳解,但我想會離最佳解一步步地趨近。

2023/08/13 結尾。