履歷
======

###### tags: `履歷` `Resume` `第一次離開軟體公司寫的履歷` `202201`

# 2022
:::info
主要放履歷上經歷項目的資源內容
:::

## 芳基
### **證明現行 WMS 可用新觀念改寫 (Skills: FoxPro/OOP/三層式架構**
因產品是用程序導向開發，當時我向公司提出不好理解和維護，經討論後開始著手進行規劃。

#### 當時嘗試改變兩件事情, 一個是引入類別與物件導向, 另一個是引入多層式架構, 依現行的業務邏輯去獨立功能與職責, 讓程式更容易閱讀進而改善維護.
重新規劃的軟體架構可分三層『底層管理路徑設定、table 連線，中間層管理權限、商業邏輯，外層是對 UI介面統一控管、共用介面、防呆』。
- 1層: 基本路徑、table連線
- 2層: 商業邏輯、共用邏輯、sql select、sql upd、資料異動紀錄
- 3層: UI統一管理邏輯、UI權限匹配邏輯、共用介面、防呆、錯誤攔截

### **因公司內部想轉型，方向設定往 asp.net (Skills: asp.net MVC5/EntityFramework6/MS SqlServer/IIS/TFS**

公司認為產品的技術太舊，想往 dotnet 的方向來發展，所以請我研究相關方法。剛開始因同仁習慣用 winform 所以選擇 webform，但中途我發現了 MVC，經分析後認為 MVC 有更好的發展性，與公司提出後獲得認同。接著建立了新版的 WMS。
#### 當時的想法是將 Repository 獨立出一個專案，多個網站可以來使用相同的 Repository。如果只是基本 CRUD 就不用再額外撰寫程式碼。
- 為什要將這些功能獨立出一個專案呢? 主要是為了讓各專案不需額外配置基本 CRUD，統一集中也達到方便控管。
- repository 獨立，並建立 service 封裝基本的 CRUD。service 使用 automap 做了 model map viewModel。
- Service 中的 CRUD 參數使用了 func 增加彈性，並搭配泛型減少未來修改程式碼或需額外擴展的相關行為。

#### clinet 統一使用 repository 達成 CRUD，不管是 web、console、winform 等應用程式，皆能共用 repository。
- 各個 clinet 只需要建立 EF 相關的 model，就可在需要資料異動的地方無痛使用 repository 達到基本的 CRUD。
- 也因應各個比較特殊的業務邏輯，需要特殊異動資料的方法。可以透過繼承 service 的介面與實作類，去調整自己需要的業務邏輯。

#### 權限控管使用 .net identity，因需要對 controller 做更細的管控。主要是為每個 Action 額外增加了 CRUD 的權限滿足業務需求。

#### 專案最後是 web mvc 的形式，透過 IIS 架站。為了版控額外架設 TFS。

## 金財通
### **開發檔案相關處理排程，協助簡化各部門排程處理檔案上不同的業務需求 (Skills: asp.net/OOP/DesignPattern**
需求是有很多檔案需要異動，異動結果需要發出通知。且異動的情況有很多種，如果按照舊有專案設計，會有不同目的的參數設定於 Config，而且程式碼會有很多重複。造成不容易閱讀與維護，擴充也是。

因此分析後決定異動檔案參數的設定使用 json，使用陣列儲存設定。因應多種不同異動的需求，使用介面定義共同的行為。且透過 model 儲存需求對應 json 的參數設定，除了更清楚閱讀另外在撰寫程式可用強型別的好處。

**簡單說明架構:**
實例出任務相對應的物件，封裝控制流程步驟讓外部更方便操作。設計模式用到 Factory 、Template Method。(細節請參閱 JsonFactory.cs)

因有多個不同的任務，且未來任務可能會增加。所以從需求抽象建立出一個介面，讓各任務去實現自己的細節。設計模式用到 Strategy。(細節請參閱 IWorkers.cs 與實作出介面的子類)

### **接手現有專案，開發新功能於付款流程中串接兩種金流(Skills: Java(nativeApp)/.netCore/MS Sql/Angular/Javascript/TFS**

#### 在同一段期間需接觸兩個新領域去解決未來任務 Angular & App。
學習一個新的語言或框架時，個人會先關注的有『為了什麼而誕生的、語言特性、專案的檔案結構、專案架構、生命週期、IDE、IDE 快捷鍵』。
- 學 Angular: 一開始先試著了解『SPA、架構(app.module、router …)、property & event binding、html template、rxjs』。 並且去實現官網教學，從中獲得未知的問題或方法。(https://angular.io/tutorial)
- 架構是由外到內大致是: **app.module.ts + import outside moduler => router => 各功能的 modlue + routing + component => bi service + endpoint**

- 學 Android: 剛開始先看『第一行代码 Android 第2版-郭霖』從中去學習相關知識。接著試著了解『app 開發環境、專案檔案結構、Config 相關、生命週期、畫面 layout、activity、多執行緒』。
:::info
開發/建置環境: 需要知道引用的函式庫的來源與安裝方式，android studio 有內建開源的 jdk，所以系統不須額外安裝。android 新版核心庫向下相容是透過 support library。

app & activity 生命週期: app 本身的生命週期是最高等級的，再來是 activity、fragment。

**多執行緒 簡易概念:**
1. 自行建立的 thread 不能直接操作 UI，原因是沒有通道將 msg 丟到 messageQueue。
2. 操作 UI 是透過特定的 Thread 執行，並且搭配特定的 looper 與 messageQueue (存放 task, runnable) 讓其它的 Thread 可以透過 handle 傳送 Msg(需搭配 runable) 到 messageQueue，達成修改畫面的任務需求。
:::
- 學習 .netCore2.2: 對 asp.net 有較多經驗，在學習上是專注在常用跟差異的地方。一開始先試著了解『為何而生、世代交替、MVC 框架的使用、可建立的預設專案、專案架構、Kestrel Web Server、DI&IOC&Service Lifetime、Application Lifetime、Middleware、REST-Like API』。

#### 啟動需求任務專案
後台:
- 後台專案是新開發的，是使用 .net core2.2 & .net standard2.0 & angular。
- 我負責的任務是串接綠界、嘗試建立 app 與 web 的跳板。
- 因時程較趕所以得加速後台串接綠界(文件太多要研究要好一陣子)，過程中問題比較多是文件的說明容易被各自表述，或者有不清楚的地方(有些要帶 null, 或者不能有這個屬性名稱 ...等)。再來是信用卡交易過程綠界的關卡狀態，說明過於術語所以這部分通了蠻多信的。釐清能直接取消交易的時機、退刷、查詢交易狀態。
- 再來是要建立 angular web 與 ios && android app 之間的溝通渠道，一開始就有兩個主要的問題，一個是 web 如何向 app 溝通，反之另一個也是。最後的解決方案是 app 中建立 js object 注入到 webview，讓 web 可以呼叫，反之 web 也建立一個讓 app 可以呼叫。
- 後來另一個問題是如何在 angular 中撰寫 javascript?? 因 app 無法呼叫寫在 conponent 底下的 js，後來是透過引入函式庫的概念，將 javascript 放在獨立的資料夾，之後在 angular.json 設定。

APP:
- 開始交接 app 專案，專案是由原生 android 寫的。因為專案是外包公司寫的，所以能問得不多也沒有文件。
- 所以先從 app 進入點開始看，看到進入 mainActivity 後就比較熟悉了。架構蠻簡單的不過關注點很分離，另外是有一些萬用類別，還有 api request 程式碼散落在各處。
- 但在專案的 layout 上學到不少東西，學到了很多方法去組織畫面。(多tab 組成的頁面, android 畫面元件, xml 語法, 畫面共同布局, 清單元件, 統一文字與按鈕大小, layout view object 對應到 activity ...)
- 需求要建立一個入口連結到客戶的 pay 還有綠界, 客戶的 pay 是直接引入其他部門的 aar, 綠界則是透過我們建立的後台溝通渠道導向綠界交易介面完成交易。

測試過程:
- app 對站台不好測試，後來是透過內網連到本機的專案 run 的 debug 專案，這個狀態才方便兩邊都進到 debug 模式。app 如果要對 webview 下 js script 可以連結到電腦上，透過 chrome 進行 debug。

### 依據客戶需求規劃新產品(APP)，優化現場作業 (Skills: Java/Kotlin/Sqlite/Git

#### 提供解決方案讓 App 透過標籤機產生標籤

藍芽標籤機:
客戶想到了一個 idea 是在智慧型手機上，透過連接藍芽標籤機印出標籤。除了通用讓成本降低之外，且讓現場作業加速。這是客戶公司第一次做，對我們來說也是 哈哈。

跟客戶在溝通時有點像是在談理想，這次參與的人很多。有幾次幾乎是他們資訊各部門蠻多人來看我們 demo 簡單用手機連到藍芽標籤機列印，然後給了一些意見。在最後的需求是要打 API 要回解析過後吐回的一串英數，完成的當天先 demo 給我們部長看，接著再去客戶公司 demo 那次客戶公司的部長也有來。是一次很有趣的經驗。

- 配對後找出藍芽標籤機這段有找到解決方案。一開始出現的問題是如何連線到藍芽標籤機? 後來是去藍芽標籤機的官網找到相關資源取得 SDK 還有相關文件。
- 因為有兩台藍芽標籤機，除了找到指定機器的流程一樣之外，其他都不同。所以後來透過介面提出相同的行為，將共同的流程邏輯獨立到抽象類，再透過兩個類別去繼承來分別實作。外部使用依賴注入就可以得到對應標籤機的服務實例。
- 接下來是傳送指令這一塊，說明文件真的很多。要從中找到有用的資訊也是花了不少功夫，這時候真心認為提供 sample code 真的很重要。對操作標籤機連線、釋放資源、列印歸位，到如何列印日期時間、條碼、位置設定、印字碼設定，是否有支援傳送多張或重複列印幾張 ...等。

#### 提供解決方案讓 App 透過將PDF透過印表機列印
PDF 透過印表機列印出來:
客戶又想到了一個 idea，目前都沒辦法直接透過 APP 打單後，直接用印表機列印。所以又想嘗試看看，主要可以增加他們服務的多元性，吸引更多的客戶且優化既有服務，或者有不同面向的業務可推展。這也是客戶第一次做，對我們來說也是。哈哈
- 在 APP 上面製作 PDF，網路上有範例可以參照。初步進行測試是沒問題。
- 這個一開始的問題是從 app 傳送資料到印表機的那條路不知如何走。後來嘗試了 socket、wifi direct、印表機商的 SDK、Google Cloud Print 這幾條路，或許都可行那至少都要選一條，因為這幾條都還需要嘗試。因客戶不想要流程上還要轉到其它應用(那時候有個已經可以作用了)，所以選擇了 Socket。(印表機商的SDK, 打電話去詢問都說是國外開發, 所以要溝通上找出可能性不容易)
- 使用 socket，透過 TCP/IP 機制找到印表機。前面那些方法已經花了很多時間，socket 目前還有些問題待解決，那時候我的主管說拖太久客戶會 argue，現在想想應該有跟客戶訂一個時間。不過那時候我確實全心投入，真的沒有去想什麼人力成本、止損點、善用資源...等等。
- 後來直接請部長發一封信給全公司的人，看有沒有人能提供解決方案。可惜是沒有(其實是幸好沒有 哈哈哈)。所以後來在摸索一下，決定跟客戶進行討論。說透過 android 原生列印服務，除了比較快速外也是最多人使用的方式，另外還找了 mopria 跟他們說這是 google 旗下的產品，未來有新款印表機也會支援等等。總之就是想辦法說服他們囉。

#### 為了改善消費者的操作體驗，縮短新需求的開發時間而提出重構，內容包含優化網路請求時從同步變為非同步、優化架構。
最一開始 APP 是設定為簡單工具，沒想到越來越多的業務需求反應上來，導致功能越來越多。但當初是用最快速且簡單的方式去撰寫，沒架構、沒用非同步發起網路請求、不清楚的職責。

後來為了因應未來需求、優化使用體驗、系統穩定性、系統擴展性，跟客戶提出重構的工作任務。當他們答應的時候，說真的我是挺開心的。因為這需求對他們來說並不是直接的利益關係。

當時規劃與想法:
- 趕鴨子上架的 app 沒有架構，邏輯都散落在 activity 或者簡單抽成一個類別，導致有不少重複的程式碼，且不易維護跟閱讀。所以當務之急是要給出一個可行性的架構。
- 先了解 app 的定位
- 我們的 app 是大多功能皆需不少網路請求，才能完成整個流程。==>> 由 UI 發出請求 => 網路請求取得資料 => 資料處理後的商業邏輯 => 將整理好的資料呈現於 UI
- 對 APP 定位有一定程度了解後，就開始建立基本架構由外而內分別是:
- UI(Activity、Shared View、Fragment、Schedule)
- BiManager(依據頁面去區分)
- API Manager、DB Manager、Utils
- 以下介紹各層別負責的職責
- Activity 只需抓住 UI Event 並呼叫對應的 BiManager 取得資料作呈現即可
- BiManager 是依照功能頁面去區分的，並且創造 callback 接口讓 Activity 去呼叫。
- API Manager 是搭配 Retrofit 去實現，封裝初始 Retrofit 的行為，讓各功能的 API Manager 去使用。並且創造 callback 接口讓 BiManager 使用。
- Utils 是放一些共用的且邏輯不複雜的功能。
- 分層的最大差異與好處:
- 不再有大量重複的程式碼，有 OO 的概念從**了解指令變成了解物件的互動**
- 從架構來看可以看出明確的職責，增加可讀性與維護性。
- Activity 皆示用非同步操作，增加使用者的體驗度。(retrofit 的非同步不用再切換為 mainThread)
- BiManager && ApiManager 皆由抽象去定義行為，有兩個好處
- ApiManager 可簡單使用假資料，不用等後端完成後才開始開發。
- 未來如果加入單元測試時降低難易度。

### 現有專案優化資料儲存邏輯 (Skills: .net MVC4/.net EF4/DesignPattern
需要增加功能在維運中的系統專案，因為時代背景的關係當初的架構已難以負荷現在的需求。新的需求就是要在這個維運專案中掛入新的功能，因不想以新專案報價客戶想用現有的維護人力下去開發。

所以我們就不規畫新專案，在現有的維運系統上掛載新功能。但新需求會有批次新增或修改資料的功能，所以決定建立新的 Repository 並使用 BulkInsert 套件達成批次的 新修

此次是讓在上間公司實作的 Repository 有機會出頭，除了 ef framework 版本不同所以細節有些不一樣，而且有額外實現其它需求。將過往的 Demo Project 實現出來，是蠻有成就感的事情。

**此次的調整規劃如下**
- 預計目標
- 支援批量的新增與修改
- 支援操作 EF 時可跨交易於不同 BiService
- 實現
- 建立新的 Repository，並且使用 SqlBulkCopy Service 達成批次的異動資料。
- Repository 的實作類去封裝交易細節，建立基本的 CRUD。
- 外部在操作 Repository 不會感受到內部使用到 bulkinsert。把細節封裝在實作 IBulkHelper 的類別中，並且還支援交易。
- Repository 的實作類查詢資料是透過 EF 機制，新增與修改皆透過 SqlBulkCopy 機制達成。因套件只有 insert 所以有另外實作 update 機制。是透過建立 tempTable 去達成。
- 支援各 BI 跨交易，可透過注入 Repository 並搭配交易機制達成。

### 因客戶業務需求增加調整硬體架構配置 (Skills: .netCore/Git/Azure DB Service/Azure AP Server
除了需求業務增加外，另外的原因是兩個不同部門的功能掛再一起，除了會影響原系統運行外，還有一些政治因素。所以要將功能抽離出另外一個部門的系統。

約20個功能掛在另外部門的系統上，有些功能是關連到別的系統，導致這次的移轉複雜度較高。所以有先將新的後台獨立報價後先行開發，移轉部分則分成兩階段進行，這樣會讓以上線的系統轉移更有保障。

#### 先建立新後台，並實現部分功能
將較核心的功能先移轉過來一部分，library 用 netstandard2.0，web 的部分是用 .netFramework 4.7.2。這裡我負責的是分析舊有的功能，分析完成後跟別的 team 講述需求並請他們實現。

前端的調整部分，將 API 統一為 json 的溝通模式、調整原本的 API Manager 設定 API URL 的邏輯。

上線是先跟客戶溝通好，將最新版本佈署到特定區域。測試穩定後再全面更新上線。最後硬體架構跟當初的規劃不同，導致某些功能異常。可見不管內部進行了多少測試，實際上線後可能會有不同的情況。

#### 實現第一階段
我負責的項目包含新舊後台、前端、分析需求後規劃功能。分配兩個隊友一個顧後台，另外一個則是開始帶著進入前端。

- 新舊後台的變化是在 API 資料的調整，此次的修改幅度不大。舊後台的部分是我處理，新後台的部分請隊友處理，並於完成後開始查閱第二階段的需求與修改幅度，確認需求與如何實現的想法。
- 前端的部分此次異動幅度比較大，所以規劃上是我自己實作，讓新加入的隊友理解 客戶、客戶需求、使用情境、產品樣貌、系統架構、前端架構，另外就是此次調整的內容，請他看完規格後，接著看我修改的程式碼。

#### 實現第二階段
終於勸客戶使用 Sql Azure DB(其實是使用我們部門的扣達)，這個階段調整的幅度就是後台多前台少，另外包含後台的硬體架構調整。

意外插曲: 因為 azure db 如果使用 code first 開啟會是最高等級的實例，意外讓成本增加了一點錢。

- 一開始主管考慮到現行系統運行與方便考量，提出一個想法是在一個站台底下掛兩個 EF DBContext，達成現行系統增加的功能連線到新的DB。這個想法不錯但沒有實踐過，再來這個客戶是需要好好伺候的那種。所以當下我提出另外的想法是還是維持一個 DB Context，修改專案原始的API而不是建立新的，將新版本掛在新站台上，新版的前台去連第二階段的新後台，這樣也不會影響既有運行，也可對第二階段進行測試。
- 與另外一個 team 溝通好第二階段的調整狀態後，因先前本來就有請他們看規格，所以這次主要確認的是細節，還包含著這次調整幅度較大的取配號機制。這次後台調整是由三個人共同進行，我負責一部分新增的功能，與建立新站台並佈署應用程式。
- 測試上用 jmeter 主要是再觀察取配號的機制，跟部分 API 密集的呼叫。取配號機制就看取走的總量是否相同，用不同的情境下去測試。另外一隻API就是密集的呼叫，觀察成功與失敗的數量。(因 AP 上還有運行中的系統，所以還得挑時間測試。)

### 客戶因受疫情影響，要求各專案需短時間內調整並配合上線 (Skills: App/.netCore/asp.net/Git/MS Sql
需求是客戶的兩個部門同時發出的需求，控制現場接收訂單的總量是它們最主要的考量。但這個機制會間接影響到他們的獲利數字，所以做出來是讓高層的人知道有這個機制，可想而知應該沒人敢隨便用。也因客戶的高層關注導致需求是很急的。

- 當時從客戶通知主管，到各專案啟動只花了五天。還用了新專案報價的方式，也就是在維運下擠出人力。所以那段期間還有既有的任務。(客戶窗口還在這時候交接)
- 一開始討論就是確認各專案所需花費的工時。總共報了兩次給客戶。這部分我是去評估 哪些系統、解決方案、調整幅度、可用資源 去估出可實現的工時。
- 這次負責的有四個專案，有三個後台兩個前台。後來臨時增加的另一個專案。
- 規格開出來後，這次的任務都交給隊友執行。期間就是溝通與確認，並同步需求異動。包含 codeReview 反覆確保增加的關卡，是否為較佳的效能去達成。臨時增加的專案則自己解決。(此次需求是我最多專案同步進行，且也是擁有最多隊友的一次經驗)

## 正美畢業
- 整理清單做過的任務
- 踏入色彩管理、與老師培養信任感
- 從電商平台與供應鏈平台，來思考導入色彩管理：B 2 C, B 2 B
- 多次的暫停與重新思考 (參考 2022 色彩管理未來方向、討論版)
- android 串 cr30 demo (考慮過要用網頁還是 app、一開始是從技術角度、後來從市場與使用者來重新定義)
- 從線上線下去推廣：線上知識、線下課程、社群
- 從供應商去切入還是從消費者去切入
- 與團隊取得共識、專案時程 與 promise
- color engine：如何介接、learn、引入單元測試
- iOS 開發方向與基礎架構、ui design system
- AImagek、HPcapman、3min profiler、camera 1min-iccProfile
- Android iOS NFC
- line 官方帳號引入電商購物 (liff)
- 分享
- 技術解決方案
- 看要不要把過往做過的，都加上對應的公司名稱 (注意不能放的資訊)
- 寫成線上筆記，供日後查看
- 以專案的形式來說明：ectrack,
- lead 過四人左右的團隊在金財通
- 列在履歷上的項目，要馬搭配專案不然就要有對應的證明
- 投擲履歷時，依據 JD 調整對應的任務清單
- 搜集目標公司
- 更新履歷
- linkedin 更新，差把內容補齊
- 履歷調整的更精簡
- 主放近兩個工作跟 side project
- 數字化
- 技術細節不放太多，因為很難放得完。
- 多放影響力跟解決的問題
- 技能只擺重要的