以下記事,除了要記錄「做了什麼」還要寫下「為什麼這麼做」
基礎建設
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