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

看板Soft_Job作者時間12年前 (2014/01/23 22:25), 編輯推噓15(15047)
留言62則, 14人參與, 最新討論串1/12 (看更多)
大家好 想請問一下,板友們的公司是怎麼管理長期維護的大專案之依賴(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

01/23 22:33, , 1F
gradle或maven吧;如果專案太大了要不要拆成幾個子專案
01/23 22:33, 1F

01/23 22:34, , 2F
也許可以將CVS改成svn或git,後者可以隨你開branch
01/23 22:34, 2F
使用 gradle 或 maven 然後換一種 vcs 都是我想過的方法, 但只知道有什麼工具可以用應該還不太夠.... 希望可以拋磚引玉,了解大家是怎麼運用這些工具管理專案的,謝謝大家

01/23 22:48, , 3F
前公司做4G手機的,專案也很大,c++ VS2010重新build要20分
01/23 22:48, 3F

01/23 22:48, , 4F
不過同步code從來沒有問題啊
01/23 22:48, 4F
說幾分鐘不是要強調它多大或怎麼樣的,只是想說給個數字也許會方便大家了解大小 重點是想請問大家用什麼方法,在效能短時間難以大幅提升的桌電 開發並管理專案的依賴,如此而已

01/23 23:09, , 5F
分子專案,子專案與專案間耦合性要低
01/23 23:09, 5F

01/23 23:25, , 6F
應該可以設定要同步哪些目錄, 那就維護這個設定檔就好了?
01/23 23:25, 6F

01/23 23:27, , 7F
把大系統拆成可以獨立運行的子系統
01/23 23:27, 7F

01/23 23:27, , 8F
以 "服務" 的概念去封裝 盡量不要全擠在一個系統裡
01/23 23:27, 8F

01/23 23:28, , 9F
服務和服務之間可以用 RabbitMQ ZeroMQ ActiveMQ之類
01/23 23:28, 9F

01/23 23:28, , 10F
的 或是 RPC的方式進行溝通
01/23 23:28, 10F

01/23 23:31, , 11F
一些功能盡量看能不能用 "模組" "外卦" 之類的形式
01/23 23:31, 11F

01/23 23:32, , 12F
實現
01/23 23:32, 12F

01/23 23:35, , 13F
看不出你的問題在那邊, 自己動手寫build 流程可以解吧
01/23 23:35, 13F

01/23 23:46, , 14F
我只覺得你沒有處在能解決這問題的位置上
01/23 23:46, 14F

01/23 23:48, , 15F
這時候你需要的是: 一杯好咖啡、悠閒的心情還有聊天對象
01/23 23:48, 15F
真的!! 有杯好咖啡加閒人在旁聊天, 電腦要lag要慢也無所謂了

01/24 00:11, , 16F
如果專案大成這樣沒用maven也很怪
01/24 00:11, 16F

01/24 00:16, , 17F
差異檔要自己產生也很怪 直接從change log抓不就好了
01/24 00:16, 17F

01/24 00:19, , 18F
每次花時間填表不如去找差異檔寫個程式把表自動建出來
01/24 00:19, 18F
想請問這邊 change log 是什麼意思? CVS 可以自動比對並記錄 commit 內容清單嗎? 我對版控系統的了解還很有限, 只會基本操作而已...

01/24 00:36, , 19F
然後為了自動化的程式再填新表格, 加上 debug... 科科.
01/24 00:36, 19F

01/24 00:37, , 20F
話說 CVS 我是沒概念, 但是以 git 來說, 不能過度自動化
01/24 00:37, 20F

01/24 00:38, , 21F
因為那樣會失去版本控制的意義, 只剩下備份功能而已
01/24 00:38, 21F

01/24 00:58, , 22F
team>XXXlog 至少有修改的檔案列表
01/24 00:58, 22F

01/24 01:07, , 23F
佈版前後差異找不到內建功能的話就開2資料夾用額外工具比
01/24 01:07, 23F

01/24 01:08, , 24F
例如winmerge 至少讓你填表省事一點
01/24 01:08, 24F

01/24 01:29, , 25F
其實專案分割牽扯到部門利益分配, 不夠力的還動不了它
01/24 01:29, 25F

01/24 01:29, , 26F
我倒覺得可以努力建議一下拆成 staged build...
01/24 01:29, 26F

01/24 01:31, , 27F
當然切 stage 的壞處是會干擾自動化, 不過這個比較可行
01/24 01:31, 27F

01/24 01:31, , 28F
相關的 build rule 要改就是了, 也是大工程...
01/24 01:31, 28F

01/24 01:32, , 29F
不過比較不會卡在某些「包裝成技術問題」的分贓環節
01/24 01:32, 29F
請問 stage build 大概是什麼樣的做法呢?

01/24 02:16, , 30F
我之前在一個一兩百人 CODE 也是分好幾個 team 寫的專案裡,
01/24 02:16, 30F

01/24 02:16, , 31F
他們也是切 project 上 maven,大家只載有需要用到的 source
01/24 02:16, 31F

01/24 02:16, , 32F
不需要的就直接用 jar include 就好了~
01/24 02:16, 32F

01/24 02:17, , 33F
而且我覺得問題是 CVS 吧,團隊一大光是解 lock 就解死人了
01/24 02:17, 33F

01/24 08:01, , 34F
真心討厭 CVS
01/24 08:01, 34F

01/24 09:11, , 35F
一般 dependency 可以翻成相依性
01/24 09:11, 35F

01/24 09:14, , 36F
對 mavan 或 gradle 不熟的話可以自己先玩玩
01/24 09:14, 36F

01/24 09:55, , 37F
用 CVS 就可以準備回家了
01/24 09:55, 37F

01/24 11:56, , 38F
用CVS就回家的話,那用TFS要去哪?(茶)
01/24 11:56, 38F

01/24 11:57, , 39F
TFS 我只當 issue tracker 用...-_- 我超賭懶用他當版本控制
01/24 11:57, 39F

01/24 11:58, , 40F
用過一次,我只有想殺人可言。後來我跑去用 git-tfs,但還是
01/24 11:58, 40F

01/24 11:58, , 41F
很想殺人。
01/24 11:58, 41F

01/24 12:20, , 42F
用 CVS 是人要去配合它, 拆好檔分好工幾乎不會遇到 lock
01/24 12:20, 42F

01/24 12:24, , 43F
以此為前提的話 lock 反而可以當成是否分工有問題的警訊
01/24 12:24, 43F

01/24 12:24, , 44F
工具百百種, 用得順手就是好工具
01/24 12:24, 44F

01/24 13:20, , 45F
來吧!git就是為了解決這類問題而生.別彷徨了
01/24 13:20, 45F

01/24 13:20, , 46F
這邊有熱騰騰的饅頭... 喔 是熱騰騰的brach管理
01/24 13:20, 46F

01/24 13:21, , 47F
從個人的專業小實驗到鉅型專案的管理都可以搞定
01/24 13:21, 47F

01/24 23:50, , 48F
哦, staged 就是把一次蹦出最終的結果拆成幾個步驟啊
01/24 23:50, 48F

01/24 23:50, , 49F
譬如我用 make 好了, 會把 make all 拆開...
01/24 23:50, 49F

01/24 23:51, , 50F
變成 make stage1/stage2/all 這三個步驟.
01/24 23:51, 50F

01/24 23:51, , 51F
笨歸笨, 還蠻有效的... 科科.
01/24 23:51, 51F
公司每天定時 build 好像也是這樣做,但是有異常好像都會影響考績, 這做法目前我看來是對系統長期的穩定有幫助,可是對基層工程師的更新和同步 過程沒助益,自己負責更新的東西一多,等到要自動 build 的時候都心驚膽跳的。

01/25 00:11, , 52F
那也是很奇怪, 你們的 auto build 都已經拆開了...
01/25 00:11, 52F

01/25 00:11, , 53F
那你們對應到的 VCS 也有拆開的方法嗎?
01/25 00:11, 53F

01/25 00:11, , 54F
就是 stage1 的東西在哪個 branch, stage2 的在哪裡...
01/25 00:11, 54F

01/25 00:12, , 55F
諸如此類的... 沒這個對應的話你還是會一做一大包啊.
01/25 00:12, 55F

01/25 00:15, , 56F
也不一定是 branch, 有可能是教你 merge source 的順序
01/25 00:15, 56F
哦哦~ 不好意思剛才回文好像沒完全理解你 stage 的意思 那這樣我們的 auto build 應該不算有分 stage ※ 編輯: dream1124 來自: 118.167.99.26 (01/25 00:21)

01/25 00:25, , 57F
那那那就建議看看吧...
01/25 00:25, 57F

01/25 00:25, , 58F
如果你的運氣很好, 遇上規劃階段有 software stacks
01/25 00:25, 58F

01/25 00:26, , 59F
或者是 API 有拆成好幾個 layer... 那就有機會.
01/25 00:26, 59F

01/25 00:27, , 60F
沒有的話................那還是換電腦吧.
01/25 00:27, 60F

01/25 00:28, , 61F
不過就算有 stack/layer design, 照你填單的數量來看...
01/25 00:28, 61F

01/25 00:29, , 62F
我是覺得大概沒人會想去碰這塊... 科科.
01/25 00:29, 62F
文章代碼(AID): #1IuIPEAc (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文
完整討論串 (本文為第 1 之 12 篇):
文章代碼(AID): #1IuIPEAc (Soft_Job)