工作時做了什麼,自己最清楚

沒有留言:

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

基礎建設

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