2017年4月21日 星期五

美國軟體工程師的日常

今天看到有科技報導介紹台灣Fintech的新聞

講到台新銀行的新App Richart

App好不好用我是不太清楚

畢竟網路銀行轉帳在美國已經很成熟了

中國也是網路轉帳算是日常生活了

台灣因為某些原因,現在才開始發展

希望網路銀行相關技術也能在台灣成熟普及

不過主要這篇報導讓我驚訝的是

裡面特別強調了他們是如何成功轉型並且開發出這個App

他們引入了軟體開發流程Agile (敏捷開發流程)

我本來以為這已經是很常見的開發模式了



1. Agile

以我公司來說也算是Fintech (但不是網路銀行這種)

我們也是引用了Agile開發

但以我們人少小公司來說

其實並不是完全遵循所有精神

以我們來說並沒有開一些公司常做的會議

像是什麼Backlog 清理,Sprint 的增減會議



平常流程大概是這樣

每周一早上,組長會跟他所有組員follow up他們進度以及這周需要完成事項

組長會把這些事項根據是新功能或是Bug修正做成Task 和 Issue分配給你

接下來就只要把事情做完了,沒有問題就沒事了

而我們公司策略的關係,公司每個禮拜都會推出一個Release

每天變動得很大,所以我們主要是以一個Release作單位

每個禮拜一組長們都會去開Release會議

而到周五會有Group sign off的會議

所有對這次Release有貢獻的人都會參與



至於當初這些Sprint跟Spec是怎麼來的

我們公司跟客戶有很密切的聯繫

公司主力產品每天都會有客戶來跟我們說希望改進什麼會新增什麼

組長們評估後覺得可行好用就會看難度加入這周或下周Release裡


2. 工作時數

不得不說美國科技公司大多工時大勝台灣

我上班都是朝8晚5,但通常5點半之後才會離開

但我們公司不像其他公司,可以隨意幾點到都好

畢竟跟行業有關,客戶大多是華爾街人士

他們一大早就上班了,假如我們還姍姍來遲9點10點才進公司

在那之前系統出問題就沒人幫忙了


3. 文化

平常與主管相處我覺得見仁見智,很多時候真的看你組長人好不好

幸運的是我的組長人很好

平常沒事時都會跟組員講垃圾話 (當然你要回話他才要跟你講)

有聽說朋友的主管很喜歡在家工作

我朋友每個禮拜都有一兩天在家工作也是很爽

但不得不說溝通對於一個軟體工程師來說真的很重要

開發大型系統來說已經非常難以單打獨鬥了

要大家一起合作溝通真的是很重要的一環

平常工作遇到問題,我都會馬上提出跟主管同事討論

他們通常都比較有經驗可以馬上提出良好建議給你

要是因為卡關而自己摸索許久反而會拖類工作效率

是不太建議的


4. 表現

美國科技公司大多你勇於表現發表看法大家不會因為你資淺而不聽你的

在適當時候表現自己的能力有助於主管與你討論規畫你的發展

當交給你的任務做得好又快

自然會被主管發現也會反映在你未來薪水上了XD

以我來說我會在自己能力所及(deadline之前)

盡量思考如何把我程式碼寫得更好懂

邏輯更清晰,更好維護,方便擴充

一方面當練功,也會因為程式穩定而被重視

因為我們小公司來說,我的工作自由度很高

交給我做的都是一個大元件

一個新功能服務來說牽扯到Backend Frontend

我通常都是負責整個Backend的開法

整體設計流程架構都可以自由發揮

算是小公司的福利吧XD

美國工作的準備時機

最近跟同樣在紐約工作的台灣強者吃飯聊天

不可避免談到當時念書找工作心得

有幾點觀念倒是蠻值得推廣的

真正準備時間應該是在出國前就開始了


非常贊同這個觀點

對於出國念書的CS同學來說

大多抱有留在美國奮鬥幾年的夢想

但真正為這目標做努力的時間

應該是在坐上飛機前就要開始了

最重要的應該是要認識到自己是要以找到工作為目標

在念書期間就開始準備找實習

並且有空就刷刷題目為面試做準備

相信持續這樣做的同學也能順利找到工作

畢竟連強者都這樣做了

普通人就更應該努力啦!

2017年4月7日 星期五

Error Handling 的重要性

被問到求學期間跟工作後寫程式上最大不同是什麼

應該就是開發一個程式會注重的點了

在學期間,課堂上給的功課,甚至是期末Project

都有個相對短的deadline,以及清楚的功能和分數

寫出來的程式只要完成所指定的功能就可以得到滿分了

所以我求學期間寫的程式只要注意功能有沒有完成就好了

測試的環境也都是固定的


但工作後由於程式演變成了產品

產品假如出錯,所造成的影響就比較大

尤其是開發金融相關軟體影響更大

像是華爾街交易員,假如他用的軟體出錯了會造成的影響都是幾百萬美金

所以正確處理edge case就是很重要的事情

基本的checking是必要的

例如: 在method 或 function開頭,對input做檢查

一個小小的檢查就能大幅降低程式出錯的機率

也對debug有很大的幫助 (因為你能肯定這個method的input不可能是null之類)



接下來就是檢查到異常input時丟出正確的exception

也會讓你的code更好用

假如你開發API要給別人用

有正確的Error訊息能幫助其他人不用看source code就能知道錯誤在哪


但值得注意的是在物件導向世界中

常常有很大一串的function call chain

錯誤能傳遞到哪一層就需要好好設計了