其實這跟公司風氣有很大的關係
像軟體公司 比較有點規模的
會把一些重要的會議結果 文件 規範 UML 或是之前的投影片分門別類放在confluence上
隨時忘了要查什麼就馬上可以查
有JIRA issue tracker 每一件事開一張ticket追蹤 還可以放附件和commet在上面
後人遇到類似的issue搜尋一下就找得到解法 我好幾個issue都靠搜尋公司issue tracker
來解
code寫完用fisheye做review 開好review後大家自己上系統看別人寫了什麼code 有什麼
意見 直接在上面問問題回答
相比起來 有些公司就沒什麼制度 甚至很多大公司也一樣
文件和資料靠口耳相傳 或是放在某個share folder上許久沒更新
issue靠email來傳遞 沒在mail loop裡面的根本就不知道這件事
code review是一群人借會議室投影機review 每個team這麼多人報上一週進的code一個下
午
除非有人做會議紀錄不然review了什麼大家根本記不得
很多時候制度風氣和工具建立起來後 根本事半功倍 不用花什麼時間問問題或回答問題
時間就比較可以拿來花在討論架構算法需求變更等更需要溝通的問題 而比較少花在問之
前哪個issue解到哪了 環境要怎麼架之類的瑣碎事情
-----
Sent from JPTT on my iPhone
--
像軟體公司 比較有點規模的
會把一些重要的會議結果 文件 規範 UML 或是之前的投影片分門別類放在confluence上
隨時忘了要查什麼就馬上可以查
有JIRA issue tracker 每一件事開一張ticket追蹤 還可以放附件和commet在上面
後人遇到類似的issue搜尋一下就找得到解法 我好幾個issue都靠搜尋公司issue tracker
來解
code寫完用fisheye做review 開好review後大家自己上系統看別人寫了什麼code 有什麼
意見 直接在上面問問題回答
相比起來 有些公司就沒什麼制度 甚至很多大公司也一樣
文件和資料靠口耳相傳 或是放在某個share folder上許久沒更新
issue靠email來傳遞 沒在mail loop裡面的根本就不知道這件事
code review是一群人借會議室投影機review 每個team這麼多人報上一週進的code一個下
午
除非有人做會議紀錄不然review了什麼大家根本記不得
很多時候制度風氣和工具建立起來後 根本事半功倍 不用花什麼時間問問題或回答問題
時間就比較可以拿來花在討論架構算法需求變更等更需要溝通的問題 而比較少花在問之
前哪個issue解到哪了 環境要怎麼架之類的瑣碎事情
-----
Sent from JPTT on my iPhone
--
All Comments