熊屋 | 技術小記

iOS, Web Development Notes

2015 Combo 8 第一場心得

| Comments

主題 技術單兵作戰及團隊開發流程差異

主講人 Caesar Chi (熱血漢誌, Facebook, Twitter)

2015 年一開春就有一系列的開發者的聚會 - 2015 Combo 8 ,本身從極長時間在極少開發者團隊剛進到一個稍有規模的公司,春水堂科技。因此也想瞭解一下轉換的心境差異及要注意的事項,因此挑了這一天第一場的講座。

除了講座主題之外,也意外中的得到一些在團隊中怎麼和其他成員相處的經驗,以及開發流程中可以改變的事項。

整場

開場時有告訴大家,這場並沒有待在單一 domain 分享,而是比較適合不同專長的人來聽。一開始從獨立開發者優缺點分享,到團隊中有什麼優缺點。最後多加帶入一些在團隊中工作流程的分享,包含測試及和專案經理合作該注意的地方。整場下來還滿有收穫的,有聽到想要的、也有得到一些長久以來問題的解答。

其中最重要的是,要在團隊中保持透明化,避免在開發中隱藏障礙點而讓專案失敗。

獨立開發者與我自己的經驗

從學生時代開始到去年中旬換工作前,一直都是兩人以下,甚至是長時間都是一個人獨自運作專案。就像講者提到的:自己包前端視覺設計、 JavaScript 以及 CSS 的架構,到後端 PHP 的 API 架構,怎麼做系統架構都要自己搞定。

我自己的情形則是,之前在一家類日商公司,要兼顧 web 前端、後台商業邏輯以及 API 再加上 iOS app ,老闆哪管你只有一個人,就是要你做出來。

再加上還要管理庶務,一人兼自己的 PM ,長時間壓力下來專案就會很亂,時程也會一延再延。幸好公司有一隻黃金獵犬:摳尼,還可以跟他玩放鬆一下。

久了之後,一直的跑下來的結果是當然一直很累 (雖然也說這是見仁見智)

小結下來,雖然獨立開發者可以自由定自己的時間,依照自己喜歡的方式寫 code ,幸運的話時程還可以自己排。但是則犧牲掉在日常中和其他人交流討論、相互競爭切磋進步的機會。

進入團隊開發

你每天 pull code 下來,就有人自動幫你把一些功能做完了

這是講者提到的一個小 comment 。

這也是我進到團隊中最大的感受,真的是很大的力量: UI/UX 有設計團隊、有 server 團隊可以直接提供 API 使用、 app notification 的機制也由 server 幫忙產出,我可以更加專注於 app 的開發。

成員的價值

在團隊裡面,老闆和 PM 固然有其價值,他們甚至幫我們做了我們不想做的事情:對外扛壓力、跨部門溝通及繁瑣的文件等。與其在鍵盤後面邊寫摳邊抱怨 PM ,不如真心思考他們心中的感受,大家都希望專案成功、希望在專案中的大家都快樂,並相信團隊中其他成員的價值。

溝通

軟體工程即溝通工程

在過去上過敏捷開發的課程及看過文章就可以發現,不要吝於和團隊成員溝通和交流意見,並需要把自己開發的過程透明化:不論是優點或缺點都要講出來。

Nerver Delay

這也是講者提出來我覺得滿重要的一個概念,對團隊的成員 坦白、溝通、透明化 ,並用專業去評估時程及可行性,就可以盡量避免訂出會造成 delay 的時程。

在估時程的時候也必須把撰寫 test 、重構以及 PR review 的時間估進去,即可避免有「我沒有時間寫測試」的情形出現,長久下來也自然可以調整出團隊進行的步伐。

前端的測試

這次的講者是專精於前端 JavaScript 的開發者,最後則有稍微提到前端的測試,也剛好是我想知道的。

我自己一直視為 app 開發其實是合併前後端特性的全端任務:包含介接 server 端以及 UI 架構。

由於 UI 操作的自動化測試有些複雜(也有可能是因為我沒有實際寫過),我對寫自動化測試 UI 的必要性有些保留的態度,這次分享所得到的經驗也可以作日後佈測試的參考。

以 app 來說,因為前端操作性的測試變化多端,除非官方 SDK 有提供可測試用的事件,不然要套一些特殊的 framework 才會比較好測。網頁前端的話,變化也比較大,要直接測也不是很好測試。

因此他提到可以做最小可行性測試,例如針對餵給 UI 的資料筆數是否符合預期等邏輯性比較好測的條件。

後記

在這幾個月以來,自己在估算 task 的時程的時候常常會過度樂觀,甚至會沒有把可以做重構及測試的時間放進去,導致可行的時間越來越縮短,也發生了「我沒有時間重構」、「我沒有時間寫測試」的情形發生,這點則需要修正改進。

也深深覺得自己很幸運,加入一個不錯的團隊,在日常中期望可以多省些抱怨,並盡自己可以做到的力:寫出好品質的 code 、做出好的產品給更多人使用。

Comments