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

  1. 工作時做了什麼，自己最清楚
  2. 基礎建設
    1. wiki
    2. git
    3. git server
    4. bug tracker
    5. cppunit
    6. jenkins
  3. 程式碼品質(技術篇)
    1. 清除client的warning
    2. 更改server架構
  4. 程式碼品質(管理篇)
    1. 提案、執行重構程式碼
    2. 提出「分頁Message」的觀念
    3. 提案自動化功能測試
  5. 落實前後端分工
    1. 提案、撰寫通用Query Message
    2. 寫 web版 message發射器
    3. 寫 web版 xml比較器
  6. 管理建議
    1. 提案導入看板方法
    2. 用bug tracker當看板方法
    3. 導入Daily Scrum
    4. 進行每週五下午的技術分享會議

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

原文連結: https://darkblack01.blogspot.com/2017/06/blog-post.html
移植時的最後更新日期: 2017-06-03T22:34:48.553+08:00


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

基礎建設

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
發表於 
tags:
  • { 社大的日子 }