Alpha Camp Twitter專案期末反思

一、背景說明

　　當初會選擇AC課程，是高中同學小新邀請我一起參加的。本來一直都有斷斷續續接觸過程式，但幾乎沒有經過系統性學習，很高興這次有機會與小新一起完成AC的課程。

　　考量到彼此都有正職工作，且自己還須兼顧家庭、兼職等，因此與小新一開始設定的目標就是，將Twitter專案的基本功能完成，並好好體驗團隊協作的過程。

　　原先希望設定體驗的專案模式是前後端分離，畢竟從學期二開始，教材都是由全端開發的角度設計的，若能透過這次的專案，體驗業界常見的前後端開發模式，將是相當不錯的經驗。

　　在這樣的前提下，與小新開始找隊友過程，竟然比想像中還要困難，而且全職學習者比我們想像中還要多。以我們的組合來說，全職學習者應該想要更密集、強度更強的專案開發過程，加上前端實在太搶手了，沒有一開始就先跟同學約定，實在不容易找到。不過，非常幸運的，在找尋的過程中找到了Eric，雖然也是全職學習者，但團隊協作意識非常好，也很能體諒小新與我有全職工作的限制，也由此最終確認了全端開發的模式。

 

二、專案初始啟動

　　在Twitter專案啟動前，我們三個人已經先約定，在當週六的晚上，確認整體開發的配置與測試git版本控制。

　　一者，我們都沒有與他人透過git做版本控制，未免衝突、覆蓋或刪除他人的程式碼，三人都有共識在初始成本最低的時候盡量測試，可以避免往後的悲劇，事實也證明如此。

　　二者，沒有先做整體開發配置，分工不明確的情況下，也不容易快速推展專案進度，因此首先就時程、資料庫、路由、開發日誌等，詳細規劃之後團隊協作的流程。這裡有段插曲就是，原來測試檔已經寫定資料庫與路由，這部分若能早點知悉，就能避免在最後階段倉促將路由修改成測試檔要求的形式。

　　不過，還是覺得專案初始，能夠針對這些基本架構，彼此溝通討論、並做整體的規劃，這段經驗還是很棒的！

　　另外就是開發日誌的部分，專案評核的時候，有助教談到我們組別因為不熟悉github提供的功能，因而有點疊床架屋。事實上應該也是如此，不過當時真的沒想這麼多，只是把小新與我平時工作熟悉的協作模式帶入，也許這點未來再熟悉程式領域的開發模式後，在經驗上能夠做更好的整合。

 

三、角色分工

　　整體檢視twitter專案後，決定將整個開發切成三大塊：基礎建設與管理員功能、推特頁面與功能、使用者頁面與功能。分別由Eric、小新與我負責。

　　這樣的考量主要是Eric是全職學習，時間比起我和小新都較多，因此就辛苦他先做專案的基礎建設，包含資料庫、路由、整體資料夾等開設，並先完成註冊等功能，以利接下來開發，而我與小新就是剩下來兩個功能的隨意分配了。

　　後期因為以通過測試檔為主要目標，加上小新請了一個禮拜的特休假，改為小新與Eric努力修改現有的程式碼以符合測試檔，而我就手邊以開發的功能，調整成符合測試檔的規格，另外小新也總籌了Heroku的上傳，十分carry。

 

四、藉由專案熟悉與學習的技術

　　這次Twitter專案的難度與規模，再重新回想的話，其實並沒有想像中的難與龐大，主要還是受限於時間與熟悉度，才會覺得有點措手不及。從這個角度來看，AC以Twitter專案作為期末重要的驗收作業，實在是設計得相當好。

　　學期三初始，囫圇吞棗了許多新的知識與開發流程，最重要的就是資料庫的引入，以及整體路由的設計，加上增加更多第三方套件的使用（如使用者驗證、檔案上傳等等）。再加上後端的一些重要概念與知識，如同步與非同步、API的串接等等。透過Twitter專案，可以很好地驗收自己對這些技術與知識的吸收。

（一）同步與非同步

　　首先最重要的就是，掌握同步與非同步。即使在教案上可以很輕易地理解同步與非同步的概念，但真正落實在程式碼與運行上，其實中間還有一到坎，需要透過大量的實作才能體會。

　　在集中衝刺進度的中秋假期，我和小新花了幾乎一天的時間，把整個資料庫的種子翻修過，其中就是大量運用到同步與非同步的概念。藉由如何適當地產出種子，也逐漸熟悉與掌握非同步的運用。

　　此外，有個比較可惜之處，是我太晚知道可以在各路由的function中，導入async模式，這樣程式碼或許可以更加簡潔易讀，也不會無限then到底，困在大括號{ }的陷阱中。

 

（二）重新熟悉前端切版

　　雖然以興趣來說，是比較傾向後端的邏輯與資料處理，但藉由這次專案的開發，也再重新熟悉前端的切版，掌握到了不少小技巧，如style的應用、position的用法、input檔案的使用與限制等等。

　　但比較可惜的地方是，為了衝進度，在整體前端版面的規劃與設計上，沒辦法好好的統一，尤其是本地端的CSS。自己在寫的過程中，都會深刻覺得這在未來的維護上一定會非常的不容易。因此，如何在前端元件上良好的命名，包含id與name，以及CSS的統一套用，都是未來需要精進的項目。另外一個點就是，bootstrap有自己既有的class模式，雖然可以下載到本地端做客製化修改，但如果要維持線上引用的模式，如何讓bootstrap的風格與本地CSS協調融合，而不會在未來維護上產生困擾，我覺得也是需要好好思考與規劃的。

 

（三）ORM與資料庫的應用

　　後端整體說來，就是依據情境對資料庫做不同層面的處理，因此熟悉資料庫的應用是滿重要的，不過這件事情還是很不熟悉，以下可以分幾點來說：

1.資料庫的撈取：無論是findAll、findById等，都可以加入條件，做更有效率的撈取，但是不熟悉ERD的情況下，究竟該設定什麼條件，撈出來的東西長什麼樣子，還是要做無限console.log大法，才能真正知道。這過程中也花了非常大量的時間，雖然這是必經過程，還是會覺得很花時間啊！

2.陣列與物件的熟悉：資料撈出來後，通常會以陣列的形式儲存，但陣列與物件的應用，有時候還是會不夠熟悉或遺忘，甚至陣列某些函式，如map、filter等，都還是要重新熟悉語法與概念後，才能好好使用。這也是透過Twitter專案，再重新檢視自己的學習狀況。

3.如何輸出需要的資料：這也是滿有趣的一點，就是當處理完邏輯程序後，理論上應當要能輸出預定的結果，卻產生各種奇妙的錯誤，或無法傳出，無論是promise或async的<pending>，還是無法適當將data傳入handlebars，都是不停debug的過程，但這過程中也逐漸熟悉javascript、express以及handlebars的運用。

 

（四）查詢資料與使用第三方套件

　　教材提供的第三方套件，通常都是固定的模式，也是在特定的情境下，當專案要求的情境轉變，或者是規格不一樣，就必須重新檢視第三方套件的其他應用，印象最深的就是multer與imgur的導入。為了要同時處理大頭照與封面的各種上傳情境，重新爬梳了multer的官方文件，並好好實驗了非同步的各種限制，最終還是產出理想的結果，可謂可喜可賀，也甚有收穫。

 

五、總結、回顧與展望？

　　整體來說，Twitter專案，可以很好地驗收個人對整體程式碼的熟悉，而熟悉度絕對程度影響了準確性、適用性、完成度以及速度，這部分真的只能多練、多累積經驗，才能熟能生巧。

　　本次主要就是完成基本功能，特別是截止日期前看到滿江紅的測試檔，團隊決心以完成基本功能與測試檔為主，行有餘力再來考慮黑客松的事情，但事實也證明確實沒有餘力再處理黑客松的功能，是滿可惜的一件事情。

　　如果再重來一次的話，整體的團隊協作我覺得還是很棒，初始規劃也很好，但絕對會加入先好好閱讀完測試檔的要求，納入整體規劃中，並要求美開發一個功能就測試一次，這樣應該會大幅度地降低專案開發末期的窘迫感。

　　另一個比較可惜的是，因為開發進度急迫，彼此都只能開發彼此的功能，很少能夠好好針對某個功能討論，雖然遇到困難點或糾結點，我們還是有很熱烈地溝通，但如果時間充裕些，可能可以對彼此開發的功能更能掌握，code review也更能扎實點，彼此也更能學習到多一些東西。

　　最後就是，還是很慶幸能藉由這次的專案合作，感受業界的協作模式，也很謝謝兩位組員的互相搭配、情義相挺，至少在各種情境跟困難下，都是全心全意地解決問題、朝向完整開發的目標，很榮幸能與兩位組員度過這段美好的時光。