[請益] 請問大家是怎麼做依賴管理的呢？

  大家好

  想請問一下，板友們的公司是怎麼管理長期維護的大專案之依賴(dependency)呢？
  小弟我剛出社會，進了這間自行發展 ERP，以 Java 實現系統好幾年的公司。
  系統經年累月下來，專案寫到很大，大到就算不把全部的檔案從 CVS 檔案庫抓下來，
  桌上 i3 4g 的電腦 eclipse build workspace 都要超過五分鐘甚至更久，
  eclipse 有時短時間操作太多還會當掉....

  零零總總許多依賴管理的問題消耗掉我很多時間又令我焦躁不安....
  可是我算新鮮人，過去沒有其他經驗，一些狀況總感覺有些問題，卻又不知怎麼解決，
  不知道可以說給大家聽，並向大家參考依賴管理的經驗嗎?

  首先，專案大了以後，我既不可能也不需要把整個系統完整抓下來。
  可是在我只抓自己單位維護的模組之餘，也多少會依賴其他單位寫的類別，
  這個時候就是惡夢了....
  專案一大，每次只要透過 eclipse Team Synchronized 從檔案庫拉一個檔案下來，
  就能讓 workspace 花很多的時間在那邊 build，在那邊檢查依賴
  想像一下當我們為了修改模組裡面 A 類別，抓下來跳紅叉叉，發現缺少依賴類別 B，
  好不容易用 lag 到不行的 eclipse 抓下 B ，build 之後還是跳紅叉叉....
  發現它依賴 C....
  如此下去，有時就算只想把本地的專案同步到一個能繼續工作的程度，
  在不斷lag 和 build 之下都像一場噩夢....

  若再加上專案依賴的 lib 很舊了, 只能使用 XML 設定 Spring 依賴注入....
  就更恐怖....
  Spring 的設定檔基本上除了自己單位維護的模組以外，
  我根本不敢更新其他可能呼叫到的模組之設定。
  因為一更新，專案就跑不起來了，有太多類別要跟著更新，
  而且都要到本地開發伺服器跑的時候才能從 Spring 的錯誤訊息裡面
  知道還缺哪些東西....
  起伺服器已經要一些時間，出錯誤以後重啟應用程式，又是一堆時間過去....

  接著.... 就算設定檔可以不同步，但其他模組的類別不可能完全不同步，
  因為多少會呼叫他們，
  然後這些類別也會變動....更新之後起伺服器又是一連串 Spring IoC 例外，
  像是原本要注入的方法在修改後不見了之類的
  每次錯誤就代表這個大專案要在本地重新 publish 一次，
  令人焦躁不安的幾分鐘又這樣過去....
  幾次錯誤累積下來，工作的時間都耗費在照顧這些依賴的問題上，很傷腦筋....

  等到要提交程式碼和設定檔時，又是很可怕的經驗....
  高層應該是基於管理考慮，每一次功能的修改，調整與擴充都要在公司內部
  自己開發管理系統上面列出異動的程式和語系檔與設定檔清單及檔案路徑。

  每天幾個特定時間，管理系統會依照記錄自動 build 並部署到共用測試環境
  條列修改清單這件事在本地的專案大時，是很費力的，
  要一個一個檢查各種共用設定檔和語系檔與類別....
  有些共用的核心類別新增 import，新增或刪除方法與成員，都要條列出來
  這些條列的項目只要一不小心少填了項目，自動打包就會失敗，考績又遭殃了....
  為了確保沒有少提交檔案到檔案庫，或是少列出修改清單，我們提交前都要很費時
  而且比寫程式時更專注的檢查，過程也花掉不少時間....不在開發上面....

  然後提交前，eclipse 的 Team synchronized view 在本機檔案大的情況，會很 lag
  我們要在這種操作環境下合併與同步衝突的檔案，
  中間要是 eclipse 很 lag 或是當掉，一切要重來，時間又這樣過去了....

  說了這麼多，可能已經有人猜出我在什麼公司
  其實講這些不是要抱怨公司不好，公司為了管專案也做了很多事，
  但我的團隊開發經驗還不夠，只能在此描述過程中覺得不太舒服，令人焦躁的現象，
  總覺得軟體發展這麼多年，也許會有更優雅更方便的依賴管理方式

  想在此藉由這個例子，請問大家的公司是怎麼管理依賴的呢?
  我想參考大家的經驗，也許可以讓自己透過一些工具減少本機啟動伺服器的時間，
  並管理好本地的依賴....讓這些莫名其妙為了能 build 而燒掉的時間可以更少....

  謝謝大家

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.167.97.15
推 yyc1217:gradle或maven吧；如果專案太大了要不要拆成幾個子專案
→ yyc1217:也許可以將CVS改成svn或git，後者可以隨你開branch
  使用 gradle 或 maven 然後換一種 vcs 都是我想過的方法，
  但只知道有什麼工具可以用應該還不太夠....
  希望可以拋磚引玉，了解大家是怎麼運用這些工具管理專案的，謝謝大家

推 bxxl:前公司做4G手機的,專案也很大,c++ VS2010重新build要20分
→ bxxl:不過同步code從來沒有問題啊
 說幾分鐘不是要強調它多大或怎麼樣的，只是想說給個數字也許會方便大家了解大小
 重點是想請問大家用什麼方法，在效能短時間難以大幅提升的桌電
 開發並管理專案的依賴，如此而已

推 sing10407:分子專案，子專案與專案間耦合性要低
推 bxxl:應該可以設定要同步哪些目錄, 那就維護這個設定檔就好了?
→ StubbornLin:把大系統拆成可以獨立運行的子系統
→ StubbornLin:以 "服務" 的概念去封裝 盡量不要全擠在一個系統裡
→ StubbornLin:服務和服務之間可以用 RabbitMQ ZeroMQ ActiveMQ之類
→ StubbornLin:的 或是 RPC的方式進行溝通
→ StubbornLin:一些功能盡量看能不能用 "模組" "外卦" 之類的形式
→ StubbornLin:實現
→ realmeat:看不出你的問題在那邊, 自己動手寫build 流程可以解吧
→ realmeat:我只覺得你沒有處在能解決這問題的位置上
推 sedgewick:這時候你需要的是: 一杯好咖啡、悠閒的心情還有聊天對象
 真的!! 有杯好咖啡加閒人在旁聊天, 電腦要lag要慢也無所謂了

→ alan3100:如果專案大成這樣沒用maven也很怪
→ alan3100:差異檔要自己產生也很怪 直接從change log抓不就好了
→ alan3100:每次花時間填表不如去找差異檔寫個程式把表自動建出來
 想請問這邊 change log 是什麼意思? CVS 可以自動比對並記錄 commit 內容清單嗎?
 我對版控系統的了解還很有限, 只會基本操作而已...

推 sedgewick:然後為了自動化的程式再填新表格, 加上 debug... 科科.
→ sedgewick:話說 CVS 我是沒概念, 但是以 git 來說, 不能過度自動化
→ sedgewick:因為那樣會失去版本控制的意義, 只剩下備份功能而已
→ alan3100:team>XXXlog 至少有修改的檔案列表
→ alan3100:佈版前後差異找不到內建功能的話就開2資料夾用額外工具比
→ alan3100:例如winmerge 至少讓你填表省事一點
推 sedgewick:其實專案分割牽扯到部門利益分配, 不夠力的還動不了它
→ sedgewick:我倒覺得可以努力建議一下拆成 staged build...
→ sedgewick:當然切 stage 的壞處是會干擾自動化, 不過這個比較可行
→ sedgewick:相關的 build rule 要改就是了, 也是大工程...
→ sedgewick:不過比較不會卡在某些「包裝成技術問題」的分贓環節
 請問 stage build 大概是什麼樣的做法呢?

→ TonyQ:我之前在一個一兩百人 CODE 也是分好幾個 team 寫的專案裡，
→ TonyQ:他們也是切 project 上 maven，大家只載有需要用到的 source
→ TonyQ:不需要的就直接用 jar include 就好了～
→ TonyQ:而且我覺得問題是 CVS 吧，團隊一大光是解 lock 就解死人了
→ qrtt1:真心討厭 CVS
推 CRPKT:一般 dependency 可以翻成相依性
推 CRPKT:對 mavan 或 gradle 不熟的話可以自己先玩玩
→ dou0228:用 CVS 就可以準備回家了
推 Blueshiva:用CVS就回家的話，那用TFS要去哪？(茶)
→ TonyQ:TFS 我只當 issue tracker 用...-_- 我超賭懶用他當版本控制
→ TonyQ:用過一次，我只有想殺人可言。後來我跑去用 git-tfs，但還是
→ TonyQ:很想殺人。
推 lovdkkkk:用 CVS 是人要去配合它, 拆好檔分好工幾乎不會遇到 lock
→ lovdkkkk:以此為前提的話 lock 反而可以當成是否分工有問題的警訊
→ lovdkkkk:工具百百種, 用得順手就是好工具
推 liddle:來吧！git就是為了解決這類問題而生.別彷徨了
→ liddle:這邊有熱騰騰的饅頭... 喔 是熱騰騰的brach管理
→ liddle:從個人的專業小實驗到鉅型專案的管理都可以搞定
推 sedgewick:哦, staged 就是把一次蹦出最終的結果拆成幾個步驟啊
→ sedgewick:譬如我用 make 好了, 會把 make all 拆開...
→ sedgewick:變成 make stage1/stage2/all 這三個步驟.
→ sedgewick:笨歸笨, 還蠻有效的... 科科.
 公司每天定時 build 好像也是這樣做，但是有異常好像都會影響考績，
 這做法目前我看來是對系統長期的穩定有幫助，可是對基層工程師的更新和同步
 過程沒助益，自己負責更新的東西一多，等到要自動 build 的時候都心驚膽跳的。

推 sedgewick:那也是很奇怪, 你們的 auto build 都已經拆開了...
→ sedgewick:那你們對應到的 VCS 也有拆開的方法嗎？
→ sedgewick:就是 stage1 的東西在哪個 branch, stage2 的在哪裡...
→ sedgewick:諸如此類的... 沒這個對應的話你還是會一做一大包啊.
→ sedgewick:也不一定是 branch, 有可能是教你 merge source 的順序
 哦哦~ 不好意思剛才回文好像沒完全理解你 stage 的意思
 那這樣我們的 auto build 應該不算有分 stage
※ 編輯: dream1124       來自: 118.167.99.26        (01/25 00:21)
推 sedgewick:那那那就建議看看吧...
→ sedgewick:如果你的運氣很好, 遇上規劃階段有 software stacks
→ sedgewick:或者是 API 有拆成好幾個 layer... 那就有機會.
→ sedgewick:沒有的話................那還是換電腦吧.
→ sedgewick:不過就算有 stack/layer design, 照你填單的數量來看...
→ sedgewick:我是覺得大概沒人會想去碰這塊... 科科.