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

看板Soft_Job作者 (三分熟的鬧鐘)時間12年前 (2014/01/24 22:42), 編輯推噓8(8071)
留言79則, 11人參與, 最新討論串5/12 (看更多)
※ 引述《dream1124 (全新開始)》之銘言: : 大家好 : : 想請問一下,板友們的公司是怎麼管理長期維護的大專案之依賴(dependency)呢? : 小弟我剛出社會,進了這間自行發展 ERP,以 Java 實現系統好幾年的公司。 : 系統經年累月下來,專案寫到很大,大到就算不把全部的檔案從 CVS 檔案庫抓 : 下來,桌上 i3 4g 的電腦 eclipse build workspace 都要超過五分鐘甚至更久, : eclipse 有時短時間操作太多還會當掉.... : : → TonyQ:我之前在一個一兩百人 CODE 也是分好幾個 team 寫的專案裡, : → TonyQ:他們也是切 project 上 maven,大家只載有需要用到的 source : → TonyQ:不需要的就直接用 jar include 就好了~ 其實我覺得大家都知道應該這樣做才對... 定好 release rule, 自己不能摸的東西就只拿 plain object 啊. (因為無可避免的天兵搗亂, 這未必容易執行, 但畢竟只是技術問題. ) 甚至包括苦主所待的公司在內應該也都知道這些事情. 那為什麼人家不這麼幹? 標準的鄉民答案是:「那些尸位素餐的主管不想學. 」 當然這是不對的... 身為一個老大幹嘛學這個?把工程師釘在十字架上叫他學就好了. 我們講個最簡單的, 很多推文都提到的「切專案」. 一開始做好分割的當然沒問題. 後來才補做的, 光是在大頭會議上就必須掐死一堆工程師. 一個賺錢的專案如果再分割, 勢必牽扯到「重新分配賺錢跟虧錢的區塊」. 就算檢查到後勤段, 也還有那種「爽區」跟「苦區」. 現狀通常都是歷史演變加上政治角力的結果, 這關係到部門是紅的還是黑的 把現狀攤開做 code/block/module/package review, 當然是互相攻擊翻了. 然而的然而, 大頭們是無敵的, 頂多有些皮肉傷而已... 至於會戰死幾個工程師則很難說. 所以說身為一個阿宅工程師, 去建議專案再分割幾乎不可能被採納. 最好的主管, 再加上專案確實也膨脹到快炸掉的時機(兩者都要成立哦. ) 或許「有可能」會回答: 「好, 我們來試試看. 」 好一點的主管會跟你打哈哈... 「唉呦, 你也不是不知道隔壁那個部門有多弱. 我們這樣一改下去, 他們一定沒能力應付. 」 中立一點的主管嘛... 「東西會動就好了, 趕進度比較重要. 」 壞一點的當然回答: 「你去亂改, 出事你要拿哪些器官負責?」 更壞的會把你的 code 秀出來給各大技術職主管 review, 這叫殺雞儆猴. 最壞最壞的主管會回答: 「好, 你來試試看, 我全力支持你. 」 這還只是分割專案哦, 該怎麼管理都還沒著手... 我再往下舉個例子... 譬如某個人提議把 CVS 轉換成 git. 讓我們問個簡單的問題: 「你知道你想改變的東西牽扯到哪些作業環節嗎?」 這時候這位倒楣蛋應該要開始禱告, 千保佑萬保佑不要遇上正妹部門... 「那個誰用什麼什麼東西撈出來的表格, 我們會貼成 excel 出給某某客戶. 」 槍斃... 結案. 身為鄉民工程師總會掙扎一下: 「我會寫 parser 把哪個哪個轉成這個那個. 」 很好, 鄉民有優待, 你可以選擇埋在哪裡. 總之能賺錢的案子就不要想動了. 「為了你一個人貪圖便利, 搞得大家沒有吃大鍋飯的空間, 不可饒恕!!」 我誠心建議練習泡咖啡比較實在, 不然真的會被風乾後掛在旗竿上示眾. 當然也不是說世界就這麼絕望. 有些專案還是可以練練功的: 虧錢的、很鳥的、黑的... 不過請捏著 LP 發誓:「我會很認真地對待眼前這個案子的!!」 有幾個人敢對著這種案子發這種毒誓?天知地知你知我知. 事實上就連能不能不要用 eclipse 當 toolchain 的一部份?我都很懷疑. 正常的公司都會有一套 toolchain under control 的規矩... 只是一線的程式人員未必知道這個東西(往往不會明文規範. ) 譬如你每天跟老大抱怨這個 eclipse 多難用又多難用. 然後每次老大都跟你今天天氣哈哈哈, 甚至可能陪你痛罵 eclipse 一頓. 但是最後一切不變. 你就要有心理準備大概是踩到某些底線了. 放心, 工程師踩這種底線倒不會有事, 它只是堅決地不改變而已. 總而言之, 會被迫泡咖啡聊天, 等 builder/maker 跑完... 這件事通常都是道道地地的政治問題, 科科. 去盧一台新電腦應該還比較簡單. 首先把眾鄉民的回答整理成漂漂亮亮的報表. 然後從 make/automake 講起, 一直到 gradle/maven 的好處. 中間穿插以 git 取代 CVS 的片段... 向大家描述美好的願景... 精明一點的, 還可以計算如此如此每個工程師每個月可以省下多少工時. 最後再拋下一句: 「一直要換新電腦才跑得動也不是辦法. 」 這樣就有機會拿到新的電腦. -- 新詩練習:新鮮。踩破初春裡的狗大便;不經意的滄桑,滿溢著嫩黃的喜悅。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 180.176.223.182

01/24 22:59, , 1F
很傳神...
01/24 22:59, 1F

01/24 23:06, , 2F
推一個!
01/24 23:06, 2F

01/24 23:12, , 3F
推一個
01/24 23:12, 3F

01/24 23:16, , 4F
這篇回文好有畫面..
01/24 23:16, 4F

01/24 23:22, , 5F
推, 真的是這樣, 說了半天最後換新電腦還比較可能實現
01/24 23:22, 5F

01/24 23:36, , 6F
請問這邊toolchain是什麼意思呢? 有參考資料可以推薦嗎?
01/24 23:36, 6F

01/24 23:40, , 7F
toolchain 指的是開發工具鏈...用來開發、編譯、版本控制、
01/24 23:40, 7F

01/24 23:40, , 8F
發布等等的工具。
01/24 23:40, 8F

01/24 23:42, , 9F
是啊 所以在什麼位置作什麼事啊~
01/24 23:42, 9F

01/24 23:43, , 10F
哦對, toolchain 就是 TonyQ 說的...
01/24 23:43, 10F

01/24 23:45, , 11F
也就是「你製造程式」的場景, 把「你」去掉...
01/24 23:45, 11F

01/24 23:45, , 12F
剩下的東西就是 toolchain.
01/24 23:45, 12F

01/25 00:01, , 13F
前輩聽我抱怨同步專案很卡,第一句話居然也是提議換電腦
01/25 00:01, 13F

01/25 00:17, , 14F
他說的沒錯(炸)
01/25 00:17, 14F

01/25 01:01, , 15F
01/25 01:01, 15F

01/25 01:07, , 16F
其實我覺得eclipse的同步工具可能寫得也不太好
01/25 01:07, 16F

01/25 01:08, , 17F
有時候CPU會忽然衝很高,還沒到滿,但就是會很卡
01/25 01:08, 17F

01/25 01:18, , 18F
我曾經用過 eclipse RDT 這個鬼東西, 還用了一年...
01/25 01:18, 18F

01/25 01:19, , 19F
最後我的心得是, 這種東西怎麼有人用得下去.
01/25 01:19, 19F

01/25 01:19, , 20F
因為根本就不穩定...
01/25 01:19, 20F

01/25 01:22, , 21F
也許現在有變好就是了, 但是我就記得 save 可能會當...
01/25 01:22, 21F

01/25 09:21, , 22F
所以我說原po沒有處在能解決這事的位置上
01/25 09:21, 22F

01/25 09:24, , 23F
這公司離開比較快
01/25 09:24, 23F

01/25 13:21, , 24F
其實我想不管哪間公司都是這樣子的, 不是這樣的才該快逃
01/25 13:21, 24F

01/25 13:22, , 25F
「工作環境」的舒適度, 這個可以商量也可以改.
01/25 13:22, 25F

01/25 13:22, , 26F
但是「工作內容」的舒適度, 這個是工作人員要自己忍受的
01/25 13:22, 26F

01/25 13:23, , 27F
我們總不可能為了技師抱怨焊槍如何如何, 就改用膠水吧
01/25 13:23, 27F

01/25 23:49, , 28F
如果電腦是新的 連銀幕都是新的該怎麼半
01/25 23:49, 28F

01/26 00:41, , 29F
不是每間公司都這樣的,至少如果你在對的位置就有機會改變
01/26 00:41, 29F

01/26 00:42, , 30F
說到處都這樣是有點過度推論了
01/26 00:42, 30F

01/26 13:06, , 31F
說得也是, 我這樣講每間公司也是太武斷...
01/26 13:06, 31F

01/26 13:07, , 32F
不過「成功而且運作良好的專案」應該都有很難改變的特性
01/26 13:07, 32F

01/26 13:08, , 33F
但是「成功且運作良好」跟「專案體系優美」幾乎是沒關係
01/26 13:08, 33F

01/26 13:08, , 34F
所以大家就會看到一大堆架構有問題的東西持續存在...
01/26 13:08, 34F

01/26 13:10, , 35F
能不能改?當然可以, 但是每次一更動, 大家就會想死一次
01/26 13:10, 35F

01/26 13:11, , 36F
其實一句話說完也很簡單...
01/26 13:11, 36F

01/26 13:12, , 37F
「你所要改變的東西, 其實是集眾人之力所形成的最佳解」
01/26 13:12, 37F

01/26 13:26, , 38F
哦對, Goal 兄問得很好, 如果都已經是 i7 八核了.......
01/26 13:26, 38F

01/26 13:27, , 39F
這也沒關係, 既然 CPU 頂級了... 接下來可以升級咖啡豆.
01/26 13:27, 39F

01/26 15:17, , 40F
我同意成功跟運作良好跟專案架構體系優美沒有直接相關,但
01/26 15:17, 40F

01/26 15:17, , 41F
無關也是有點過度推論。這主要的理由在於每個專案需要的架構
01/26 15:17, 41F

01/26 15:17, , 42F
健康度不一,有的專案就是搶山頭的自然就不用管這些。
01/26 15:17, 42F

01/26 15:18, , 43F
成功的專案雖然跟專案體系優美只是間接相關,但失敗的專案
01/26 15:18, 43F

01/26 15:18, , 44F
或被重新啟動的專案理由裡面,有不少是專案體系做的太爛造成
01/26 15:18, 44F

01/26 15:19, , 45F
以台灣現在的狀況,所謂的「眾人之力」常常也就是技術長帶頭
01/26 15:19, 45F

01/26 15:19, , 46F
其他人想都沒想就接受的架構,如果有更好的 plan,作點嘗試
01/26 15:19, 46F

01/26 15:19, , 47F
是不應該被 limit 的。當然,為了團隊著想這種嘗試應該只在
01/26 15:19, 47F

01/26 15:19, , 48F
自己環境慢慢自己作實驗,不要干擾到他人。
01/26 15:19, 48F

01/26 15:20, , 49F
我的意思是不要把團隊智慧看的太高,團隊人數越多智商是會越
01/26 15:20, 49F

01/26 15:20, , 50F
低的。我在美國看過我們 team 很白痴的把 dev 環境 server
01/26 15:20, 50F

01/26 15:21, , 51F
cache 預設啟用。導致每次開機之後就無法善用 hot deploy 特
01/26 15:21, 51F

01/26 15:21, , 52F
性,加上開機 default service server preload 導致啟動要
01/26 15:21, 52F

01/26 15:21, , 53F
十分鐘。整個團隊就維持改 code 要等十分鐘的節奏在開發。
01/26 15:21, 53F

01/26 15:22, , 54F
這個團隊有快一百多人,大家都嘴巴幹譙這件事情手上繼續作。
01/26 15:22, 54F

01/26 15:22, , 55F
事實上要改變這件事情很簡單,找到 properties setting 改對
01/26 15:22, 55F

01/26 15:23, , 56F
就好了,但很多人根本就沒興趣去找。architect 也沒注意到這
01/26 15:23, 56F

01/26 15:23, , 57F
事,就造成團隊的浪費。
01/26 15:23, 57F

01/26 15:23, , 58F
這種例子其實還不少。雖然我知道看新人在團隊裡面橫衝直撞提
01/26 15:23, 58F

01/26 15:23, , 59F
新的方法論對大家來講困擾其實大於這些事情造成的改善,而且
01/26 15:23, 59F

01/26 15:24, , 60F
有時這些方法論根本沒改變什麼又要增加習慣負擔。但直接把方
01/26 15:24, 60F

01/26 15:24, , 61F
法論的演進這條路封殺並不是件好事就是了。
01/26 15:24, 61F

01/26 16:17, , 62F
離封殺還很遙遠啦, 大家給意見也都給得勤啊... 科科.
01/26 16:17, 62F

01/26 16:17, , 63F
團隊的智商並不高, 這個我知道...
01/26 16:17, 63F

01/26 16:17, , 64F
問題出在大部分不了解狀況的人會「嚴重低估團隊智商」
01/26 16:17, 64F

01/26 16:19, , 65F
stackoverflow 的名言: "avoid premature optimization"
01/26 16:19, 65F

01/26 16:20, , 66F
中間這個 premature 其實也就是類似的意義...
01/26 16:20, 66F

01/26 16:24, , 67F
而且哦, 如果只是調個設定可以搞定的話, 那當然很好...
01/26 16:24, 67F

01/26 16:24, , 68F
但是前面回文所牽扯到的, 其實已經遠超出這種技術問題了
01/26 16:24, 68F

01/26 16:26, , 69F
工程技巧能解決的問題, 跟必須倚賴管理階層的問題...
01/26 16:26, 69F

01/26 16:27, , 70F
實務上的差別應當是非常大的, 但只有問題時會很難分別
01/26 16:27, 70F

01/26 16:28, , 71F
通常必須等到真正的答案, 然後回顧才知道如何分類...
01/26 16:28, 71F

01/26 22:45, , 72F
是啊,所以這類型的建議或討論的答案得看他在什麼位置,
01/26 22:45, 72F

01/26 22:45, , 73F
如果他不是不瞭解狀況的人甚至是該解決這個問題的人,那就很
01/26 22:45, 73F

01/26 22:45, , 74F
難說了~
01/26 22:45, 74F

01/26 22:45, , 75F
畢竟不知道問題之前,也很難知道到底是不是調個設定就好~
01/26 22:45, 75F

01/26 22:47, , 76F
至於原題在我眼中是有靠工程技巧解決的空間,就算不要求別的
01/26 22:47, 76F

01/26 22:48, , 77F
team 改變作法,自己先做 stage build 其實還是有機會的。
01/26 22:48, 77F

01/26 22:52, , 78F
反正我相信在團隊裡的基本心法,就是先改自己再改別人。
01/26 22:52, 78F

01/26 22:52, , 79F
這個共識有剩下的都是怎麼作的問題~
01/26 22:52, 79F
文章代碼(AID): #1IudkxBO (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 5 之 12 篇):
文章代碼(AID): #1IudkxBO (Soft_Job)