Just My Life & My Work

Archive for the ‘工作’ Category

App 產品歷經十年的挑戰與困難

我想是可以分享的時候了~

2019 年我進入一家 2009 年成立的公司,是以 Web 起家,2012 年開始研發 App,據傳當時僅有一為 App 工程師,同時要寫 iOS 和 Android,這讓聽到的我感到不可思議,一方面佩服該工程師偉哉之處,一方面擔心若該工程師發生意外,有人能夠接手處理嗎?🤔

我接手 iOS 專案時,已經不再是由一人同時研發兩平台,所以我能專注在我熱愛的平台 iOS,首先評估當前專案狀況。

iOS App 歷代開發者接手時間

  • 第四人:2019/09 就是我~🙃
  • 第三人:2017/04
  • 第二人:2014/03
  • 第一人:2012/07

接手別人寫的專案有好處嗎?有~但壞處也不少喔!

好處是不必再想架構,基本上照著前人已制定好的架構繼續做即可。
若有新的功能,則視情況發展自己的邏輯架構。

壞處則是首先要熟悉前人的程式邏輯,我必須瞻前顧後,確定不會影響舊有功能為前提,才能繼續開發新的功能。
由於 App 已有久遠歷史,專案有數量眾多檔案與複雜邏輯,每次編譯會花費 1-5 分鐘不等(端視筆電規格與有無快取)。
有可能踩到前人不小心埋的坑,導致增修功能後,產生不預期的問題,甚至可能難以除錯。

(繼續閱讀…)

[圖解] 2022 年科技業衰退追蹤

身為資訊軟體工作者,會時常關注國內外企業的聘僱狀況,來了解當前產業景氣狀況。🤓

2022 後半年,發現有好多裁員新聞,但是一直都很難去了解整體狀況。偶然間在臉書粉絲團發現特別的網站,會統計大企業公開裁員新聞,圖解做得非常好理解,我們一起來看一下吧~

這是每個月裁員數量統計,數字越大就長得越高。

有在一些平台群體中聽聞,在該企業宣布要裁員,在該企業的員工上班會忐忑不安,直到結果出爐,才稍做喘息。

(繼續閱讀…)

什麼是 Scrum 團隊?

目前我們研發團隊已經跑了兩個 Sprint,想要陸續來了解一些跟 Scrum 有關的定義和規則。

原本以為【敏捷開發】可以加速開發,畢竟叫做【敏捷】,但查了網路文章,有經驗人士分享,結果根本就不是啊⋯⋯🤪

這讓我對敏捷開發幻滅,身為我這種生產力極高的工程師說,實際跑才兩個 Sprint 就發現,此模式是會拖慢我開發效率的⋯⋯不過還是希望習慣此開發模式之後,會逐漸加快吧~

這次就來理解什麼是 Scrum 團隊

看了這張圖,就能了解 Scrum 團隊包含哪些角色,目前看起來 Scrum Master 和 Product Owner 相當重要,我們團隊是由有三年跑 Scrum 研發經驗的工程師翔所領導。趁這時候聽話照著做,肯定能學到許多!😎

我們工程師有 Web、iOS、Android、Flutter、Backend、Architect、DevOps 等。而設計師、需求者(市場、業務、產品等)等不在我們 Scrum 團隊中。

(繼續閱讀…)

軟體外包風險評估

由於市場業務部不斷提出新的需求,迫使我們設計研發部必須加速實現,但當前人力有限,勢必得尋找新的人力資源,有兩種方式:

  • 招募人才
  • 外包團隊

當下狀況是,來不及招募到合適人才,而市場業務部恰好有認識的外包團隊(中國與台灣各一),長官們決定嘗試接洽,然因為長官不熟開發知識與技術,於是就請我來當窗口,向兩個外包團隊說明我們想要使用的技術與達成的結果。🤔

(繼續閱讀…)

Scrum 與 Sprint

工作多年,一直有聽說跑 Scrum 與跑 Sprint,但一直不曉得真正的規則是什麼?覺得新創公司的開發步調就是種跑 Scrum,但好像又相差甚遠。🤔

終於,這次新創團隊,某位翔大在前公司有跑 Scrum 的經驗,從無到有建立起來整套流程,據說他為了履行 Scrum 的真實義,甚至還因此讓上司覺得跑 Scrum 是個阻礙⋯⋯

我想,引進新的管理辦法,確實會讓原本順暢的工作流程受到干擾,也就是原本跑得流暢的工作程序,會出現窒礙難行的狀況。除非公司能夠承受變動過程的成本,如此推動跑 Scrum 才有機會成功~

我認為,須根據公司成長階段來實施 Scrum,初步可分為

  1. 0-1 草創
  2. 1-10 混沌
  3. 10-100 穩定

比較適合的是 1-10 階段,為什麼呢?介於混亂與穩定之間,可有效率發散與收斂研發效能!🤠

(繼續閱讀…)

萬年老系統

萬年老系統是非常誇張的說法,我寫 iOS App 是從 iOS 6 開始,至今 2022 年已邁入 iOS 16,若說是老系統,應該頂多 16 年啦~😀

實際上現在公司的產品,是從 2016 年開始(看程式檔案有年份),還是使用 Objective C 開發,至今邁入第七年,我發現是有四個工程師陸續接手研發,因為有看到作者名字和程式風格。

因為我一直是開發 iOS App,所以一個月內我就對大部分的功能流程熟悉,包含串接後端 API 部分,只要有使用到的 API,一定給他測個成功和失敗案例。

目前公司後端工程師數量遠超過前端,畢竟後端模組至少有 10 個吧~假如 iOS 和 Android 勉強算兩個模組,可見後端複雜度之高~🤪

稍微了解 API 後,我明白後段相依性很大,想要在舊有錯綜複雜邏輯下往上加功能,肯定會有一些出乎意料之外的狀況。讓我想起萬年老系統那張圖~很是貼切呢!

總之,且戰且走,我們採滾動式開發~盡可能不要讓前端拿到有問題的 API 就好啦!😜

若有朋友需要開發 App,歡迎來找我喔~

[圖解] 專案計畫與實際

這次執行的區塊鏈平台產品,沒有足夠時間可以完整進行:分析、設計、實作、測試、釋出

看到下方這張時程圖-專案計畫與實際,發覺我們正面臨的狀況,正好只有兩個月的時間,就要釋出給大眾使用,全部時程都擠在一起,這樣成果品質是不會太好的⋯⋯

我想主要原因在於,我們接手前人所寫的解決方案,尚未了解此 Code Base 架構與品質,就率先決定產品推出日期。

當我們人力陸續到位,能夠開始部署,才陸續遇到問題,光是要將缺陷給修正就要花點時間,再來還要新增需求。時間有限之下,需要有所取捨,如此就會造成混亂,每次局部測試一直遇到狀況,修正後還是會偶發狀況,表示整個系統是相當不穩定。

我主要心力放在 App 開發,我所在乎的後端,就是期待 API 能正確運作。於是我要先走一步,提早研究將來會使用到的技術。

期待接下來的時程能順利囉~🤪

Macbook Pro M1 Pro Benchmarks

三月初拿到全新筆電,忍不住就想要來比較效能差異。先前跟朋友借 Macbook Pro M1 2020,性能已相當優越;此刻公司配給 Macbook Pro M1 Pro 2021,想必然性能更升一級,那麼量化後會有多少差異呢?

(繼續閱讀…)

升級 Macbook Pro 硬體

此文撰寫於2021/09

最近發覺我手上的 Macbook Pro 2015 年的筆電,狀況越來越多,一開始我還能適應,不過最近狀況頻繁發生,於是審慎思考是否該換新的 Macbook Pro,畢竟未來狀況無疑會越來越多且頻繁~😳

為什麼狀況會越來越多且頻繁呢?

廣告

1. 為了開發最新最前衛的 App,勢必要跟著最新最前衛的技術走,於是將隨著時間更新 MacOS 和 Xcode,這兩者規格持續會有某大程度提升,也因此會更操硬體。每次我更新 MacOS 後,便明顯感受到,點擊頁面(Xcode 和 Chrome 等軟體)會延遲比上個 MacOS 更久。比如,過去可能是 0.1 秒反應時間,現在會提高為 0.2 秒,甚至更久。

2. CPU、Memory、Disk 使用率將會逐漸升高,一方面是軟體升級,一方面是硬體折損,一來一往,每經過一年,硬體的負擔將越來越重,而且運行的體感將越來越卡頓。其實就跟 iPhone 每經過一年,升級 iOS 後的體感極其類似。

我手上公司機 Macbook Pro 2015 狀況大致上如下: 

1. 硬碟空間不足,僅有 128GB
2. 記憶體不夠,僅有 8GB
3. CPU負擔重,僅是 2.7GHz 雙核心 Intel Core i5

參考:https://support.apple.com/kb/SP715?locale=zh_TW

公司太省了吧⋯⋯😬影響到我的產能變低、錯誤變多,那可就萬萬不可啦~跟大家建議一下,要是公司連工具設備都不肯更新,可能就要另謀出路,因為工作後續衍伸的問題,都會從此誕生~不信?讓我們繼續看下去~

(繼續閱讀…)

2022 年我的工作桌

新的一年已經開始半個月,要來省視一下我的工作環境與設備,俗話說,工欲善其事,必先利其器

我得老實地說,是個標準的工作狂,於是除了公司有工作桌外,在家也是有個精簡的工作桌~🤪

首先來看一下我在公司的工作環境~

這時候我有三台電腦!?天哪~就算是再怎麼愛工作,也不必要一個人做三人份的事呀~

(繼續閱讀…)

標籤雲

%d 位部落客按了讚: