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

看板Soft_Job作者 (dk)時間12年前 (2014/02/07 19:09), 編輯推噓6(6020)
留言26則, 4人參與, 最新討論串10/12 (看更多)
我猜你應該是 一個專案樹中的一個模組中的某一小撮專案中的某個小組下的一個成員, 而不是三五人甚至一人掌握專案全局的情形, 以下回應以此為前提。 技術上可能可以處理,但是最好別做。 (結案) 就靠你一人實驗到全公司的環境都確定能整好流程都能跑很順, (這是必備,只要有一丁點小問題都很難有下一步) 算三個月好了,這已經算你 OOO 的你超強這樣。 然後你得先說服幾個同事 (不然要跟主管 PK?), 再向主管提出來,假設這也可以。 然後有可能別的 team 都不用改嗎?不行的話... ... ... 我也不知道能怎麼說服別的 team, 最主要我想是要靠你主管,不過他有那熱血有那 LP 的話, 就不會把問題擺到你來煩腦了。 這還是上面倒數第十個字起的 "某個小組..." 之下的範圍而已喔, 往上還有得推。 只能說什麼情況都可能,就是讓你推成功最不可能。 真的萬一推成功了又有什麼好處呢? 現在每次給他拉專案 build 可以有十分鐘空檔很好啊, 可以泡杯咖啡,背十個單字,看一篇 blog 或新聞, 養生又有成長空間。 總之,可以試試改善個人作業環境或做點實驗, 就當學習兼練功,不要想說能把整體環境做改變會比較好。 ※ 引述《dream1124 (全新開始)》之銘言: : 謝謝大家熱心的回覆! : 在發文前我就大概知道種種令人不痛快與焦躁的事情不只是依賴管理的問題, : 但因為這是我第一次的團隊開發經驗,遇上令人不滿的狀況時, : 還不知道怎麼介定和理解這些問題。 : 這種感覺就像當兵進去發現種種不適應的狀況時, : 總要花一段時間才知道哪些事情可以商量可以調整, : 而哪些事情只能鼻子摸摸認了習慣它的事.... : 另外就算知道哪裡有問題,要從哪裡下手,怎麼下手解決這些問題, : 也才會發文求助。 : 綜合大家的回答,我想了一些方法,針對不同問題,從手邊會做的事開始解決問題, : 請問可以參考一下大家的意見嗎? : 1. 因為開發環境沒有做套件版本管理,沒有用類似 maven 或 gradle : 那種 group id artifact id 的方法管理與分割自行開發的套件, : 而且不同類別的依賴又完全靠公司規範寫法的 spring 2.0 xml 做依賴注入, : 偏偏這些 spring xml 不是將不同功能寫在不同的 xml 檔案內, : 而是用 action service dao 以層級區分類別, : 將不同層的類別寫在不同設定檔上集中管理依賴的方法, : 以致於即便接到的任務只是調整幾個沒有多少依賴的類別, : 為了檢查五個左右的類別加一個 jsp 寫成的功能是否能運作, : 就要從 CVS 上同步很多很多類別下來,以免起伺服器時依賴注入失敗。 : 並要花五分鐘以上啟動伺服器,才能檢查寫的功能有沒有錯。 : (這時間包含啟動伺服器與 spring 初始化做依賴注入) : 但要是為了方便開發而自行建立開發環境用的 spring 設定檔, : 那麼在遞交時又得花不少時間同步要上傳的設定檔與開發用的設定檔... : 針對這問題我打算寫 xml 工具,解析伺服器上拿到的 spring 設定檔, : 根據每次的需求過濾不同任務中用不到的 bean,重新產生依賴注入的設定檔 : 供開發時期使用。 : 相信若這樣做,就算還要同步一堆類別才能開始工作, : 至少也可以減少啟動伺服器的時間,而且不用擔心在本地eclipse工作區 : 裡面用不到的類別若沒更新到最新版本有可能導致啟動伺服器時依賴注入失敗。 : 請問這個方法大家覺得還 OK 嗎? 不知道有沒有已經開發出的工具可以用呢? : 我猜過去應該也有人遇過這種問題,但我不曉得他們是怎麼處理的.... : 2. 看完大家回覆才知道有些問題是 CVS 與 CVS 的 eclipse plugin : 功能不夠強所致的,例如 change list 之類的 : 雖然我不能決定專案的檔案庫要擺在哪裡或是用哪種軟體, : 但如果我在本地使用 git 與 eclipse git plugin 管專案, : 遠端一樣是公司的 CVS,不知道可不可以讓同步檔案的過程比較不卡, : 或是對將要遞交的檔案產生 change log 方便我去公司的管理系統註記嗎? : 這些事情是以我微薄的功力所能想到的幾個改善流程方法, : 其他的想法會在完全成型之後補上,請問大家覺得目前這些方法可行嗎? : 再次謝謝大家! -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 36.226.184.134

02/07 22:33, , 1F
對啊, 事實上每個公司應該都有專案問題...
02/07 22:33, 1F

02/07 22:33, , 2F
但是解決專案問題未必會是重點.
02/07 22:33, 2F

02/07 22:34, , 3F
譬如說吧, 每次 build release 要三天...
02/07 22:34, 3F

02/07 22:34, , 4F
很浪費時間吧?但是... !!
02/07 22:34, 4F

02/07 22:36, , 5F
但是沒看到背後必須有一個月的 certification flow...
02/07 22:36, 5F

02/07 22:36, , 6F
那去改這個三天根本就不是重點, 因為到頭來還是會卡住.
02/07 22:36, 6F

02/07 22:37, , 7F
純軟體的公司當然很重視 software framework.
02/07 22:37, 7F

02/07 22:38, , 8F
問題在於台灣好像也沒這麼多真正的軟體公司...
02/07 22:38, 8F

02/07 22:39, , 9F
所以這樣就卡死啦, 因為資訊不足, 其實沒辦法動作.
02/07 22:39, 9F

02/07 22:40, , 10F
而且我自己的心得是, 每個案子裡面只要有一個擺爛的老鳥
02/07 22:40, 10F

02/07 22:41, , 11F
那就可以宣告結案了...
02/07 22:41, 11F

02/07 22:42, , 12F
這種老鳥別的本事沒有, 想藉口拒絕改變的能力特別厲害
02/07 22:42, 12F

02/07 22:44, , 13F
我說的不是主管哦, 一般而言主管拒絕都是另有原因...
02/07 22:44, 13F

02/07 22:45, , 14F
我說的是坐隔壁那個成天陪大家聊天打屁的好同事, 科科
02/07 22:45, 14F

02/07 23:06, , 15F
想要變革的人本來就該自己說服或拜託同事吧, 同事沒義務
02/07 23:06, 15F

02/07 23:06, , 16F
隨著革命家起舞啊。
02/07 23:06, 16F

02/07 23:26, , 17F
何謂純軟體公司@@?
02/07 23:26, 17F

02/07 23:35, , 18F
推, 謝謝你的經驗分享, 我的處境的確就如你所說的這樣
02/07 23:35, 18F

02/07 23:36, , 19F
然後最近感覺也如sed大說的,阻力最大反而未必是主管
02/07 23:36, 19F

02/07 23:37, , 20F
因此我的看法與大家類似,會以實驗試著改善個人的環境
02/07 23:37, 20F

02/08 00:01, , 21F
做雲端的寫 app 的應該都蠻軟的啊...
02/08 00:01, 21F

02/08 00:02, , 22F
不過提供大部分職缺的應該還是半導體產業中的軟體部門
02/08 00:02, 22F

02/08 00:02, , 23F
這種的就不純了... 科科.
02/08 00:02, 23F

02/08 00:09, , 24F
哦對啦, dream 板胞不必這麼絕望啦...
02/08 00:09, 24F

02/08 00:09, , 25F
就像我說的, 可以去挑「虧錢的、很鳥的、黑的」來練功.
02/08 00:09, 25F

02/08 00:10, , 26F
反正虧錢的案子絕對比賺錢的多, 不要去碰正在賺的就對了
02/08 00:10, 26F
文章代碼(AID): #1IzBxh3e (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容:
完整討論串 (本文為第 10 之 12 篇):
文章代碼(AID): #1IzBxh3e (Soft_Job)