Just My Life & My Work

Posts tagged ‘architecture’

[圖解] 軟體工程師離職後

去年還在健康科技公司上班時看到這張圖解軟體工程師離職後,還覺得是個開玩笑的狀況,沒想到終於被我遇到啦⋯⋯

曾經有聽說過,某新創公司的產品是由超強老闆寫出來,上線營運後發現市場接受度相當高,有意擴張規模而雇用幾個工程師來承接他之前寫的產品,這是我朋友吉米的前公司做博弈軟體的故事。

產品創始人把心中的想法迅速時做出來,透過雛形來測試市場接受度有多高,開發軟體過程想必不會寫得很有彈性,因為「彈性」是需要大規模超仔細地想各種可能發生的情況。比如若我當初只想要搞定80%的狀況,大概一個月就能做出來;若我要再觸及剩下的20%,可能要再多花兩個月才能完工。於是乎我會選擇前者!

當驗證市場可行後,接下來就來補剩下的20%。然而儘管只是20%,想要在既有的架構上可就不太容易擴展,而老闆僱用來的工程師肯定不可能全盤了解當初寫的架構與流程,因為裡頭包含各種Features、Bugs、User Cases、Work Flows、Workarounds等。加上老闆所展現的Coding StyleLogic,與雇用來的工程師所使用的並不一致,導致剩下的20%由老闆來寫只要兩個月,而若讓雇用來的工程師來寫的話就高達半年⋯⋯

回想我還在健康科技公司時,是如此呼風喚雨,iOS App由我一個人獨自從無打造出來,後進來的Android工程師都要仿照我的方式來實現,畢竟小而美的創業公司資源不多,要盡可能使用最少資源來達成目標。對比現在港商的工作狀況,產品已經由資深同事開發10個月,架構是由他建立起來的「樂高系統」,MVC架構非常分明,就好比我當初使用MVP架構HiLife App,然而相對的所花費的時間變多。

過去一個大功能我能在一天內完工,現在一個小功能我可能一天內還無法安心動手,落差非常大啊⋯⋯有時候真的想要不管既有架構,把可運行的Code塞進去,馬上就可以有正確的效果,只是長久來看,只會不斷增加「技術債」,這我在圖解理想與實際的軟體架構有提過。

想起我偉大的前同事德叔說:

要Refactor他人寫的Code需要很大的氣度。

我在下方回答笑說:

我寧願寫Code給別人Refactor,也不要別人寫Code給我Refactor!

對我來說,加入新創公司就是想快速成長,要像個成長駭客一樣跟著產品進化,來盡可能獲得較多的成就感!最終實現自我~

於是乎,之後若要我選擇的話,我肯定會選擇從「無」開始打造產品,因為我可以根據當時的規格(畫面、功能、流程等)來決定架構,可以很快就把既定的藍圖實現出來。

我心中有好多Idea要實現啊⋯⋯

廣告

[圖解] 理想與實際的軟體架構

理想與實際會有非常大的差異,在軟體界更是尋常可見!可是因為軟體並非實際的物品,所以通常不易讓「外行人」了解!不過當你看到這張圖解理想與實際的軟體架構,就能大概知道開發一個軟體將有哪些狀況會發生。

此圖取自IT狗的俄羅斯方塊,很高興這張圖寫實地描繪出我所經歷過的狀況XD~

軟體界所謂的規格(Specs),以我過去的經驗來看,大致只有在初期開發時管用,新的技術、新的需求、新的人事物⋯⋯都會影響啊~

我常笑說,我寧願從無開始打造,也不想要去維護他人遺留下來的「毒(技術債)」。

(繼續閱讀…)

心電貼片裝置與架構

我公司同事阿龍設計這偉大的心電貼片韌體架構,與他共事一年後學到非常多跟韌體和硬體有關的知識技能。在此來揭露可公開的心電貼片裝置與架構

首先來看我們公司的完成品,心電貼片裝置,猜猜看它有什麼特殊功能?

厲害的他已工作超過22年,其中有20年都在做韌體,所以之後有韌體方面的問題都可以請益他!

他語重心長地說:「我可以從 軔體 → (Linux)驅動程式 → (Android) 框架 → (Android) 測試APP 一路做下來,但不玩啦,很累人的~

我評估現實後說:「若時間和金錢不夠的話⋯⋯就要支出人生最重要『健康』~

我們相視而笑~

那這個架構可以做什麼呢?看到的人可以拿去再研發!我們已經證明此架構可行,可以實現搜集心電和呼吸訊號,接著進行分析,透過人工智慧的演算法,判斷使用者的身心狀況,做到醫療保健目的!

此玩意兒需花費多少時間與金錢?若想在一年內完成,大致要準備1000萬台幣,研發包含硬體、韌體和軟體,我公開我和阿龍配置的研發成本~

那何時能回收成本呢?知道這應用範圍的人肯定能想得出來:D~

若有意願開發的人,可以跟我聯絡,我將這項利益大眾的技術傳承下去。

糟糕的API製作

一年前也就是2017/1/27的紀錄,我經手一個幼稚園案子,我以為只要負責開發App的部分即可,所以報價非常的親民,因為對方是我非常好的老闆朋友。不過最後證實,這個案子讓我公司虧錢,時間成本多出3倍,為了斬斷所有牽絆,在卡卡頓頓開發一年後,宣布不再接手維護。

以下就描述我身為軟體架構師觀察到的問題:

API開發

此案不明原因分成三個人⋯⋯

  • A創造規格人(實作原型)
  • B建立架構人(實作雛形)
  • C開發實作人(實作成品)

幼稚園案子.gif

照理說,ABC要同一人才是!因為每個人的邏輯思考不同,若分為三個人接續製作,最後成果極度可能四不像,那可是會大大增加開發成本!

(繼續閱讀…)

MVC與MVP

已經寫超過三年半的iOS App,一直以為自己對MVC很熟,但其實不然,畢竟我一直不是用正規的MVC來實作,相信大多數的iOS App開發者也有類似的煩惱XD~

不過沒有寫得很標準,其實不會怎樣,大不了專案難以維護,接手你程式的工程師想要翻桌,這是每位稱職工程師的必經之路!於是我們會學習會成長,然後寫出更好的架構來。

最近技術委員會決議要統一iOS和Android的專案程式架構,由我們最資深的工程師楊大決定從MAC進展到MVP

MVC與MVP.gif

有了這張對照圖,就能很清楚MVC與MVP的差別!最關鍵的地方就在View和Model不互通有無的三角戀情。

(繼續閱讀…)

[圖解] 台北車站立體導覽圖

九年前搭捷運以來,回台中的家時必停留在台北車站,原本就有台鐵北捷,陸續又蓋好高鐵北轉,讓整個台北車站結構變得十分複雜。老實說,到現在我還是沒有記熟這四個交通互轉時的路線,但是有了這張高人設計師所畫的圖解台北車站立體導覽圖,我便可在腦海裡浮現立體圖,就算趕時間也能不慌不忙地走到目的地月台。

台北車站立體導覽圖

上圖可點擊放大喔~

實在很佩服設計師,能把極其複雜的北車結構畫得如此清晰,他還有畫些其它的捷運站。

台北車站每日運量高達32萬人次零號出口畫了這張表格,一目了然地知道台北捷運2015年08月運量前20名

台北捷運2015年08月運量前20名

跟我一樣喜歡旅遊、美食的朋友可參考:台北吃、喝、玩、樂-逍遙遊(可點擊)

.

.

參考:捷運車站立體導覽圖

[iOS][Watch OS] Watch OS 1 與 Watch OS 2 架構

才剛結束的2015年WWDC,宣布了Watch OS的誕生,而且馬上就是Watch OS 2!這跟過去一年的Watch OS 1有著非常大的差別,不過為了簡單起見,我們就先直接瞭解關鍵的差異,也就是Watch OS 1 與 Watch OS 2 架構

Watch OS 1架構可以參考我先前寫的Watch App Architecture

architecture watch OS

乍看之下只是把WatchKit Extension從iPhone移轉到Apple Watch,可是事實上要做的功夫可是很多很大~

(繼續閱讀…)

標籤雲

%d 位部落客按了讚: