almost 2 years ago

其實已經夠忙了,要寫的東西也超多的,除了閒談軟體架構和 Java Magazine 的翻譯,沒想到又弄了雜記,是怎麼了呢?

軟技能

周三晚上參加了臺北市政府產業發展局主辦的老闆學校講座最終場《2016年, 老闆,我想做遊戲可以嗎?》,本來只是想看看這類的活動是什麼,不過整場歡笑不斷,主持人挺厲害的,加上參與座談的創業家都喝了不少啤酒 (是的,啤酒),所以也爆了不少料,但因為是喝酒後說出的,一概不負責 XD

自己曾想過開發遊戲,所以在高中選類組時,就選了二類組,一直朝軟體工程師的路邁進,也一度在遊戲橘子待了三年,不過呢?不是開發遊戲,嗯,再次幫老東家打次廣告,是開發 BeanGo!,自己也知道台灣遊戲產業的現況,所以,並沒有真的開發過遊戲,只有在學校寫過一些小玩具。

會中,聊到怎麼避免打掉重練時,提到了我耳熟的字眼:scrum,事實上創作避免不到打掉重練,不好玩的成分留在遊戲中不但不會加分,反而是扣分,只是有沒有什麼方式讓這件事提早發生,讓傷害降到最低,在場四個團隊有兩個明確提到他們用 scrum,而且都是分成兩個小 team,主要的原因都是想維持較小的團隊有較小的溝通成本。

這讓我想起去年,在 Agile Tour Taipei 2015 分享前團隊怎麼朝 scrum of scrums 邁進 (投影片),從一個變成兩個 (嚴格上算是三個,一個是負責營運),投影片其實列了蠻多的觀察與身為 scrum master 的自省,後來看到 David Ko 在 FB 的社團上發的一張照片,上面寫著:

Culture eats process for lunch
Don't create a process, create a movement

是啊,敏捷重要的是文化與精神,流程倒是其次,但要怎麼塑造出團隊的文化與精神,或換一個方式想,如何讓團隊自己想要有敏捷的文化與精神,自身能力確實不夠,在離開前團隊時,雖然用了些方法讓團隊自己組成他們認為最合適他們現況的隊形,但從他們討論的內容,隱隱約約覺得少了點什麼?但我似乎又幫不上忙。

會後,我與其中一位創辦人聊聊他們 scrum 怎麼跑,以及程式、美術與企劃,這三種技能差異甚大的成員怎麼合作,他也苦笑,其實他們也花了很多時間磨合,但我們都提到,要引導團隊需要的不是 process,而是很多的軟技能,讓團隊自己能夠成長。

API 風格

前陣子寫了篇《閒談軟體架構:API Naming Style》,而最近則是特別有感覺,目前的專案,用 Swift 3 在開發,大致由三個人寫,雖然貢獻比例差距蠻大的,但從程式碼就看的出來三種不同的風格,一個是寫 iOS App 好幾年的老手,也因此 API 幾乎是 Objective C 的風格,自己呢,不敢說完全掌握到 Swift 的風格,但自認是最接近 Swift 3 提出的新風格,最後一位是最近剛開始學 iOS App 開發的新手,也因此風格相當不穩定。

有人會說,怎麼有差這麼多嗎?其實真的會,Swift 和 Objective C 一樣,函式的參數名稱有分內外,若從別的語言轉過來,一開始最不習慣的就是 label (對外的名稱),會覺得很麻煩,平常想一個變數名稱就已經很難了,寫 Swift 要想兩個,超煩的,這也就是三個人的差別:囉嗦、自認精煉和不知道該怎麼命名。

我個人是這樣,用什麼語言就要像用什麼語言,不然自己的程式在那個語系中與其他函式庫會格格不入,同時我也把寫程式當作在寫作 (這樣說來,包含技術部落格,我現在幾乎天天在寫作,而且寫作的量很龐大),我都是以如何讓程式讀起來像自然語言的角度,去想 label 的名稱該是什麼,所以會常用到大量的介係詞當作 label,希望透過這些 label 將函示名稱、label 和變數名稱能組成一句可以讀的完整句子。

短期內,我也不認為這專案的 API 風格會收斂到一個大方向,就讓它隨風飄吧。最後,分享給還需要改程式作業的後輩助教們,別再相信:『這程式很簡單啊~所以大家才會都寫得一樣』這句話,這肯定是屁話!

基本上,這系列會比較是跟軟體開發上有關的牢騷,浪費大家的時間看,真是不好意思。

← 閒談軟體架構:Plug-in JUnit 5:下個世代的單元測試 →