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

[sedgewick (三分熟的鬧鐘)]

※ 引述《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
推 lovdkkkk:很傳神...
推 momoCry:推一個!
推 typepeter:推一個
推 waterdisney:這篇回文好有畫面..
推 dream1124:推, 真的是這樣, 說了半天最後換新電腦還比較可能實現
→ dream1124:請問這邊toolchain是什麼意思呢? 有參考資料可以推薦嗎?
→ TonyQ:toolchain 指的是開發工具鏈...用來開發、編譯、版本控制、
→ TonyQ:發布等等的工具。
→ TonyQ:是啊 所以在什麼位置作什麼事啊～
→ sedgewick:哦對, toolchain 就是 TonyQ 說的...
→ sedgewick:也就是「你製造程式」的場景, 把「你」去掉...
→ sedgewick:剩下的東西就是 toolchain.
→ dream1124:前輩聽我抱怨同步專案很卡,第一句話居然也是提議換電腦
→ sedgewick:他說的沒錯（炸）
推 f1234518456:
→ dream1124:其實我覺得eclipse的同步工具可能寫得也不太好
→ dream1124:有時候CPU會忽然衝很高,還沒到滿,但就是會很卡
→ sedgewick:我曾經用過 eclipse RDT 這個鬼東西, 還用了一年...
→ sedgewick:最後我的心得是, 這種東西怎麼有人用得下去.
→ sedgewick:因為根本就不穩定...
→ sedgewick:也許現在有變好就是了, 但是我就記得 save 可能會當...
→ realmeat:所以我說原po沒有處在能解決這事的位置上
推 zanyking:這公司離開比較快
→ sedgewick:其實我想不管哪間公司都是這樣子的, 不是這樣的才該快逃
→ sedgewick:「工作環境」的舒適度, 這個可以商量也可以改.
→ sedgewick:但是「工作內容」的舒適度, 這個是工作人員要自己忍受的
→ sedgewick:我們總不可能為了技師抱怨焊槍如何如何, 就改用膠水吧
推 GoalBased:如果電腦是新的 連銀幕都是新的該怎麼半
→ TonyQ:不是每間公司都這樣的，至少如果你在對的位置就有機會改變
→ TonyQ:說到處都這樣是有點過度推論了
→ sedgewick:說得也是, 我這樣講每間公司也是太武斷...
→ sedgewick:不過「成功而且運作良好的專案」應該都有很難改變的特性
→ sedgewick:但是「成功且運作良好」跟「專案體系優美」幾乎是沒關係
→ sedgewick:所以大家就會看到一大堆架構有問題的東西持續存在...
→ sedgewick:能不能改？當然可以, 但是每次一更動, 大家就會想死一次
→ sedgewick:其實一句話說完也很簡單...
→ sedgewick:「你所要改變的東西, 其實是集眾人之力所形成的最佳解」
→ sedgewick:哦對, Goal 兄問得很好, 如果都已經是 i7 八核了.......
→ sedgewick:這也沒關係, 既然 CPU 頂級了... 接下來可以升級咖啡豆.
→ TonyQ:我同意成功跟運作良好跟專案架構體系優美沒有直接相關，但
→ TonyQ:無關也是有點過度推論。這主要的理由在於每個專案需要的架構
→ TonyQ:健康度不一，有的專案就是搶山頭的自然就不用管這些。
→ TonyQ:成功的專案雖然跟專案體系優美只是間接相關，但失敗的專案
→ TonyQ:或被重新啟動的專案理由裡面，有不少是專案體系做的太爛造成
→ TonyQ:以台灣現在的狀況，所謂的「眾人之力」常常也就是技術長帶頭
→ TonyQ:其他人想都沒想就接受的架構，如果有更好的 plan，作點嘗試
→ TonyQ:是不應該被 limit 的。當然，為了團隊著想這種嘗試應該只在
→ TonyQ:自己環境慢慢自己作實驗，不要干擾到他人。
→ TonyQ:我的意思是不要把團隊智慧看的太高，團隊人數越多智商是會越
→ TonyQ:低的。我在美國看過我們 team 很白痴的把 dev 環境 server
→ TonyQ:cache 預設啟用。導致每次開機之後就無法善用 hot deploy 特
→ TonyQ:性，加上開機 default service server preload 導致啟動要
→ TonyQ:十分鐘。整個團隊就維持改 code 要等十分鐘的節奏在開發。
→ TonyQ:這個團隊有快一百多人，大家都嘴巴幹譙這件事情手上繼續作。
→ TonyQ:事實上要改變這件事情很簡單，找到 properties setting 改對
→ TonyQ:就好了，但很多人根本就沒興趣去找。architect 也沒注意到這
→ TonyQ:事，就造成團隊的浪費。
→ TonyQ:這種例子其實還不少。雖然我知道看新人在團隊裡面橫衝直撞提
→ TonyQ:新的方法論對大家來講困擾其實大於這些事情造成的改善，而且
→ TonyQ:有時這些方法論根本沒改變什麼又要增加習慣負擔。但直接把方
→ TonyQ:法論的演進這條路封殺並不是件好事就是了。
→ sedgewick:離封殺還很遙遠啦, 大家給意見也都給得勤啊... 科科.
→ sedgewick:團隊的智商並不高, 這個我知道...
→ sedgewick:問題出在大部分不了解狀況的人會「嚴重低估團隊智商」
→ sedgewick:stackoverflow 的名言: "avoid premature optimization"
→ sedgewick:中間這個 premature 其實也就是類似的意義...
→ sedgewick:而且哦, 如果只是調個設定可以搞定的話, 那當然很好...
→ sedgewick:但是前面回文所牽扯到的, 其實已經遠超出這種技術問題了
→ sedgewick:工程技巧能解決的問題, 跟必須倚賴管理階層的問題...
→ sedgewick:實務上的差別應當是非常大的, 但只有問題時會很難分別
→ sedgewick:通常必須等到真正的答案, 然後回顧才知道如何分類...
→ TonyQ:是啊，所以這類型的建議或討論的答案得看他在什麼位置，
→ TonyQ:如果他不是不瞭解狀況的人甚至是該解決這個問題的人，那就很
→ TonyQ:難說了～
→ TonyQ:畢竟不知道問題之前，也很難知道到底是不是調個設定就好～
→ TonyQ:至於原題在我眼中是有靠工程技巧解決的空間，就算不要求別的
→ TonyQ: team 改變作法，自己先做 stage build 其實還是有機會的。
→ TonyQ:反正我相信在團隊裡的基本心法，就是先改自己再改別人。
→ TonyQ:這個共識有剩下的都是怎麼作的問題～