Just My Life & My Work

Posts tagged ‘architecture’

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

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

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

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

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

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

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

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

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

我在下方回答笑說：

我寧願寫Code給別人Refactor，也不要別人寫Code給我Refactor！

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

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

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

分類：

研究, 過程, 工作

Tagged with:

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

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

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

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

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

（繼續閱讀…）

分類：

研究, 圖表, 工作

Tagged with:

心電貼片裝置與架構

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

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

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

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

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

我們相視而笑～

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

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

那何時能回收成本呢？知道這應用範圍的人肯定能想得出來：Ｄ～

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

分類：

研究, 工作, 工作, 感想, 成果

Tagged with:

糟糕的API製作

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

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

API開發

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

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

幼稚園案子.gif

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

（繼續閱讀…）

分類：

研究, 閒聊, 工作

Tagged with:

MVC與MVP

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

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

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

MVC與MVP.gif

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

（繼續閱讀…）

分類：

iOS, 教學

Tagged with:

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

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

台北車站立體導覽圖
廣告

上圖可點擊放大喔～

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

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

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

跟我一樣喜歡旅遊、美食的朋友可參考：台北吃、喝、玩、樂－逍遙遊（可點擊）

廣告

.

.

參考：捷運車站立體導覽圖。

分類：

研究, 繪圖

Tagged with:

[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，可是事實上要做的功夫可是很多很大～

（繼續閱讀…）

分類：

iOS, watchOS, 教學

Tagged with:

[iOS] Watch App Architecture

在瞭解Watch App目標架構後，我們想進一步瞭解：

  • Apple Watch與iPhone溝通
  • Watch App的運行流程
  • ViewController的生命週期

Apple Watch與iPhone溝通

Watch iPhone commucation

包含兩部分：Watch app和WatchKit extension。Watch app在Watch上運行，只包含Storyboard和Resource；WatchKit extension在iPhone上運行，與對應的iPhone App在一起。當使用者點擊Watch App後，與Watch配對的iPhone會啟動WatchKit extension，然後與Watch建立連接，於是兩者可以溝通（如獲取資料等）。

（繼續閱讀…）

分類：

研究, 繪圖, iOS, 教學

Tagged with:

[iOS] Apple Watch 目標架構

開發Watch App時，所要注意的角色有三個，因為Watch App無法獨自運行，需要透過iOS App來啟動與操作它，而彼此溝通的橋樑則是WatchKit Extension。我們可以很清楚地從下圖得知三個角色的關係：

watch app target structure

使用Xcode 6.2開發Watch App時，原本的專案就是iOS App，操作順序：New->Target->Apple Watch->WatchKit App，便會同時產生WatchKit App與WatchKit Extension到專案中。WatchKit App僅含Storyboards與Resources，WatchKit Extension則含WatchKit Code與Resource。

new target watchkit app

據知未來Watch App可獨立運行，就讓我們拭目以待吧！

參考：Apple Watch开发初探。

分類：

iOS, 教學

Tagged with:

[Xamarin][iOS] 深度了解專案：電話字 (Sample Project: Phoneword)

承接範例專案：電話字 (Sample Project: Phoneword)，再來就是解釋它怎麼運作，包含Xamarin介面和C#程式碼，還有很重要的是Xamarin.iOS Application的剖析。

Xamarin iOS Application03

  • References – Contains the assemblies required to build and run the application. If we expand the directory, we’ll see references to .NET assemblies such as System , System.Core, and System.Xml , as well as a reference to Xamarin’s Xamarin.iOS assembly.
  • Components – The Components directory houses ready-made features from the Xamarin Components store , a public marketplace for Xamarin code. This is similar to the NuGet Gallery for those familiar with Visual Studio. For more information on Xamarin Components, refer to the Xamarin Components walkthrough .
  • Resources – The Resources folder stores icons, launch images, and other media. Xamarin has a separate guide for Working with Resources that explores the role of this directory further.
  • Main.cs – This contains the main entry point of the application. To start the application, we pass in the name of the main application class, the AppDelegate .
  • AppDelegate.cs – This file contains the main application class and is responsible for creating the Window, building the user interface, and listening to events from the operating system.
  • MainStoryboard.storyboard – The Storyboard contains the visual design of the application’s user interface. Storyboard files open in a graphical editor called the iOS Designer.
  • Phoneword_iOSViewController.cs – The View Controller powers the screen (View) that a user sees and touches. The View Controller is responsible for handling interactions between the user and the View.
  • Phoneword_iOSViewController.designer.cs – The designer.cs is an auto-generated file that serves as the glue between controls in the View and their code representations in the View Controller. Because this is an internal plumbing file, the IDE will overwrite any manual changes and most of the time we can ignore this file. For more information on the relationship between the visual Designer and the backing code, refer to the Introduction to the iOS Designer guide.
  • Info.plist – Info.plist is where we set application properties such as the application name, icons, launch images, and more. This is a powerful file and a thorough introduction to it is available in theWorking with Property Lists guide.
  • Entitlements.plist – The entitlements property list lets us specify application capabilities (also called App Store Technologies) such as iCloud, PassKit, and more. More information on theEntitlements.plist can be found in the Working with Property Lists guide. For a general introduction to entitlements, refer to the Device Provisioning guide.

看起來和Xcode裡的檔案架構很類似呢！學習來格外輕鬆～

（繼續閱讀…）

分類：

iOS, Xamarin, 教學

Tagged with:

標籤雲