[請益] 請問大家是怎麼做依賴管理的呢?
大家好
想請問一下,板友們的公司是怎麼管理長期維護的大專案之依賴(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
01/23 22:33, 1F
→
01/23 22:34, , 2F
01/23 22:34, 2F
使用 gradle 或 maven 然後換一種 vcs 都是我想過的方法,
但只知道有什麼工具可以用應該還不太夠....
希望可以拋磚引玉,了解大家是怎麼運用這些工具管理專案的,謝謝大家
推
01/23 22:48, , 3F
01/23 22:48, 3F
→
01/23 22:48, , 4F
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
01/23 23:28, 9F
→
01/23 23:28, , 10F
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
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
01/24 00:11, 16F
→
01/24 00:16, , 17F
01/24 00:16, 17F
→
01/24 00:19, , 18F
01/24 00:19, 18F
想請問這邊 change log 是什麼意思? CVS 可以自動比對並記錄 commit 內容清單嗎?
我對版控系統的了解還很有限, 只會基本操作而已...
推
01/24 00:36, , 19F
01/24 00:36, 19F
→
01/24 00:37, , 20F
01/24 00:37, 20F
→
01/24 00:38, , 21F
01/24 00:38, 21F
→
01/24 00:58, , 22F
01/24 00:58, 22F
→
01/24 01:07, , 23F
01/24 01:07, 23F
→
01/24 01:08, , 24F
01/24 01:08, 24F
推
01/24 01:29, , 25F
01/24 01:29, 25F
→
01/24 01:29, , 26F
01/24 01:29, 26F
→
01/24 01:31, , 27F
01/24 01:31, 27F
→
01/24 01:31, , 28F
01/24 01:31, 28F
→
01/24 01:32, , 29F
01/24 01:32, 29F
請問 stage build 大概是什麼樣的做法呢?
→
01/24 02:16, , 30F
01/24 02:16, 30F
→
01/24 02:16, , 31F
01/24 02:16, 31F
→
01/24 02:16, , 32F
01/24 02:16, 32F
→
01/24 02:17, , 33F
01/24 02:17, 33F
→
01/24 08:01, , 34F
01/24 08:01, 34F
推
01/24 09:11, , 35F
01/24 09:11, 35F
推
01/24 09:14, , 36F
01/24 09:14, 36F
→
01/24 09:55, , 37F
01/24 09:55, 37F
推
01/24 11:56, , 38F
01/24 11:56, 38F
→
01/24 11:57, , 39F
01/24 11:57, 39F
→
01/24 11:58, , 40F
01/24 11:58, 40F
→
01/24 11:58, , 41F
01/24 11:58, 41F
推
01/24 12:20, , 42F
01/24 12:20, 42F
→
01/24 12:24, , 43F
01/24 12:24, 43F
→
01/24 12:24, , 44F
01/24 12:24, 44F
推
01/24 13:20, , 45F
01/24 13:20, 45F
→
01/24 13:20, , 46F
01/24 13:20, 46F
→
01/24 13:21, , 47F
01/24 13:21, 47F
推
01/24 23:50, , 48F
01/24 23:50, 48F
→
01/24 23:50, , 49F
01/24 23:50, 49F
→
01/24 23:51, , 50F
01/24 23:51, 50F
→
01/24 23:51, , 51F
01/24 23:51, 51F
公司每天定時 build 好像也是這樣做,但是有異常好像都會影響考績,
這做法目前我看來是對系統長期的穩定有幫助,可是對基層工程師的更新和同步
過程沒助益,自己負責更新的東西一多,等到要自動 build 的時候都心驚膽跳的。
推
01/25 00:11, , 52F
01/25 00:11, 52F
→
01/25 00:11, , 53F
01/25 00:11, 53F
→
01/25 00:11, , 54F
01/25 00:11, 54F
→
01/25 00:12, , 55F
01/25 00:12, 55F
→
01/25 00:15, , 56F
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
01/25 00:25, 58F
→
01/25 00:26, , 59F
01/25 00:26, 59F
→
01/25 00:27, , 60F
01/25 00:27, 60F
→
01/25 00:28, , 61F
01/25 00:28, 61F
→
01/25 00:29, , 62F
01/25 00:29, 62F
討論串 (同標題文章)
以下文章回應了本文:
完整討論串 (本文為第 1 之 12 篇):