###### tags: `kgs` `做了什麼好事`

# 自己做過了什麼，自己最清楚

以下記事，除了要記錄「做了什麼」還要寫下「為什麼這麼做」

# 基礎建設

## wiki
最後版本由技術長架設
- 原本用gitit，但是後來改用wikipedia，現在還是覺得用gitit好。(markdown+git)
- 資訊透明、文件共有共編
- 文件補齊與版本一致

## git
- 沒有版本控制，沒辦法工作
- 脫離「人工merge地獄」的利器

## git server
最後版本由技術長架設
- 用gitWeb看code，可視化git的內容
- 用SSH進行溝通，無須每次都打帳號密碼(visual studio只吃http)
- 程式碼開放給公司內部所有被授權的開發者共同開發
- 使用gitolite做ssh key權限管理

## bug tracker
- 因為bug都零散的用word檔在管理
- 開過的bug不知道又開了一次
- 標題的命名規則依UI選單操作進入順序，定位bug的位置

## cppunit
- 防止相同的bug再發生
- 可定義「完成工作」的條件(尚未實現)

## jenkins
- 防止「不立即提供(編譯)最新版，是我的怠惰」的月經問題
- 讓工程師(我自己)把時間花在coding上面 。
- 順便進行自動化單元測試、程式碼品質度量，用某個標準量化軟體品質

# 程式碼品質(技術篇)

## 清除client的warning
- 新人時期拿到code第一件事就是做這件事，避免無法預料的bug產生。

## 更改server架構
- 後來被抓去實作新的Server - RMA, 提出全新架構(架構戰)
- 縮小Server維護範圍，減少寫一支Msg的時間
- 小修改無須很多code一起重編，減少測試一支Msg的時間
- 用C++的方式解決先前的Server的問題。
- 因if-else無法128個而使用的寫法 -> 可讀性很低
- 三層架構區分資料庫動作還是Xml動作 -> coding太多不必要的code
- 一支Msg一個function的設計 -> 無法區分/重複利用 Msg邏輯和資料邏輯
- 太多通用於各個資料表的獨立function -> 要背下來才可以活用
- 還在難以debug的MARCO -> 該使用C++的技術來取代

- 濫用的template -> complier生成的code漲大，編譯速度超級慢
- 太多code在用一個檔案，小修改的編譯內容太多，編譯速度慢
- 專案檔的設置並不乾淨，不必加入KgsLib檔案

# 程式碼品質(管理篇)

## 提案、執行重構程式碼
- 產品程式碼品質太低，邏輯前後矛盾
- 程式定義刪除行為，沒有辦法檢查資料庫資料刪除是否乾淨。
- 區隔Msg邏輯、資料表邏輯、畫面邏輯
- 二次開發的架構也因此產生
- 可完全拿掉MARCO
- 可大量重複使用資料表的邏輯

## 提出「分頁Message」的觀念
- 提高效能，效能與資料量不相依的存取方式。
- 無需依賴WCF，可以更依賴KgsLlib

## 提案自動化功能測試
QA工程師撰寫
- 快速進行「功能完整性測試」，實作後只測試整個產品的主要功能
- 之前有人想過，但是沒有認真面對(評估)。仔細思考評估後發現是可行的。

# 落實前後端分工

## 提案、撰寫通用Query Message
- 分工client與Server，畫面邏輯不在server做。

## 寫 web版 message發射器
- 原單機版測試器，無法模擬client的送出Message情況(沒有經過IIS)
- 遠端主機直接瀏覽器就可以進行測試(無須登入桌面)

## 寫 web版 xml比較器
- 實作Xml的比較邏輯，快速的比較Xml，無須人工比對
- 收到Message之後直接進入比較

# 管理建議

## 提案導入看板方法
- 解決「進度到哪了」的月經問題，避免為了這問題打斷工作拉去開會。
- 失敗原因
- 管理者對「最小切割」的觀念錯誤，為了方便管理。
- 分工對人不對事。
- 面對插單時，還是要問「進度到哪了」。
- 派工依舊整包丟
- 管理者結果論
- 判定此方法不適用現況(不適合於此管理者)。

## 用bug tracker當看板方法
- 最小工作切割
- Server一支Message為單位
- Client一個畫面為單位(注意畫面之間溝通與發送Message初始化資料的時機)
- 解決評估是否方便插單、工作進度詢問、互相Cover工作進度的問題

## 導入Daily Scrum
即時的反映正在「開發中+多人協作+需溝通協調」的問題
- 每天實作上的小問題
- 相似工作的相同問題
- 承接前後工作的交接問題
- 2017/01/16 開始，有繼續了，中間有一小段時間各忙不同的案子，但是卻繼續Daily Scrum

## 進行每週五下午的技術分享會議
- 對於架構與技術交流
- 進行過七場，從2016-09-30 ~ 2016-12-02(約兩個月)
- 包含內部技術、工具運用、先備知識...的交流
- 部門內的人全部都有分過一輪
- 因後來大家各自忙不同的案子而淡出生活~XD