看板 DataScience 關於我們 聯絡資訊
※ 引述《littleyuan (baby)》之銘言: : 大家好 : 我是ML新手 跟的前輩是很優秀的超強者 : 但是前輩很不organized 寫的code總是不commit : 主管希望下個項目之前我可以提出報告要如何改進並且希望前輩能跟進 : 我是覺得ML和其他寫程式有點不同 : 因為不斷測試參數 每次調參數都commit的話好像太繁雜 所以我一般是有了好結果才com : mit一次 不知道大家一般怎麼做的 : 另一個問題是資料庫會更新 更新過程那原來的model 不變讀到的數據就不一樣了那出來 : 的結果也還是不一樣 : 這樣要怎麼reproduce做出和原來一樣正確率?? : 大家會寫個word檔紀錄每次Data的變化嗎? : 想知道大家實際工作上是如何管理的呢? 你可以commit到另一個branch master branch只放乾淨的程式碼, 然後設定限制, 永遠不能被直接commit 只能透過送pull request的方式 這一種方式在一般軟體開發很常用 http://nvie.com/posts/a-successful-git-branching-model/ (google搜得到中文翻譯版) 以兩人合作來說 feature branch跟master branch兩個分支就夠用 簡單說是當你要開發時, 開一個新的branch 完成時送pull request到master branch 和另一個人code review, 完成後merge 到master 資料庫會更新這點來說 應該local, staging, production 不同環境各有自己一份資料 別人要測試你的參數時, 都是共用local的資料 你可以從production抽一些資料放到s3當成給local用 local:給大家本機用的, 資料量不要太大不然讀得很慢 或是筆電會當掉 staging:上production前部署到伺服器測試看看運作如何 production:實際有使用者在用的環境 資料會變動 cookiecutter主要是讓專案更有架構 https://github.com/drivendata/cookiecutter-data-science 如資料流程擺一起等等 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 95.91.211.168 ※ 文章網址: https://www.ptt.cc/bbs/DataScience/M.1523698437.A.895.html
littleyuan: 謝謝你寶貴的意見!我原來的做法真的太雜亂了 新的項 04/14 22:02
littleyuan: 目會開始用這些方式來好好整理的! 04/14 22:02
tay2510: 推! 04/15 00:53