看板
[ Soft_Job ]
討論串[閒聊] 主管要求註解代替刪除
共 5 篇文章
內容預覽:
這個應該是加在commit message. 以git為例. git log. /需求單號(找到該筆commit-id). git show commit-id. 想看這次改了哪些地方. git show commit-id. 想邊看code邊看哪些更動是這次修改的. git blame. 可以取代
(還有132個字)
內容預覽:
這好解決不是問題.. 需求單可以一整塊寫在實作前.也可以寫在宣告前.達成共識就好.. 實作的人員本來就應該指出實作是依據哪一個規格實作.. 是因為沒有依據功能來封裝才會導致這種說明呈現破碎.. 前專案我是軟體頭的時候.我制定的方式是.以檔案(模組)為責任區分.. 但是開發進行中不乏會互相支援.. e
(還有1114個字)
內容預覽:
謝謝大家的意見!. 推文講到的，我都有參考。 NDark 的建議很實用，我也有在會議上提出~. 我還滿幸運的，主管們肯聽我們的想法，以及花時間討論。. 我花了2天的時間整理我論點，可行的建議，寫了一篇9頁、2000多字的圖文並茂的抗辯書(不過我覺得花時間做這件事很值得，而且口頭討論很容易離題。).
(還有779個字)
內容預覽:
我完全同意你的看法.. 我也遭遇到你的相同困境.. 我猜想,這可能是"曾經"沒有使用版本控制的"資深"程式人員所帶出來的習慣.. (我不敢斷然推測是硬體程式人員,因為我從未與硬體程式人員工作過.). 然而,改變人是一件困難的事情.. 改變資深或上級人員的觀念又格外困難.. 因此,我能建議你的,也就是
(還有507個字)
內容預覽:
是這樣的，主管最近要求凡是修改檔案一律. 1. 以註解夾住修改的地方. 2. 原本的程式註解掉，不要刪掉. 所以原本改完一行變四行，例如:. //2012/09/12 修改人 需求單號 申請人 主旨等等 Begin. // string errMessage = "";. string errMes
(還有350個字)