Re: [問題] 專案很肥大重新build,需要很多時間

[dream1124 (全新開始)]

※ 引述《supercygnus (......)》之銘言：

  我猜你的問題跟我公司專案一樣，都是老專案而且我們 eclipse 版本還比你舊，
  記憶體吃更多，改個設定重啟一次伺服器就要 15 分鐘.... 久到非常消磨士氣...

  但原始碼很大一包其實不是錯，大是因為要做很多事情，只要不是大而無用就好。
  可是你會說... 專案一大，IDE 就卡，然後開發就慢，該怎麼辦？

  仔細想想平常開發功能時，IDE 真的需要載入那麼多原始碼，
  不斷建置、不斷完整檢查語法有錯嗎？  很多類別明明就用不到吧？
  既然這些類別的原始碼根本用不到，為什麼不先編譯好才引到專案中呢？

  因此改善開發效率的可行做法是把系統模組化或是分層，
  然後各層各模組分別建置，再用執行套件的管理伺服器統一建檔保管。

  等到開發時再用相依性管理工具 (ant ivy, maven, gradle) 宣告
  要開發的程式會依賴在哪些函式庫，接著讓相依性管理工具在建置的時候
  自動幫你從管理伺服器取回函式庫，這樣就不用每次 IDE 一打開
  就必須抱著一堆原始碼，不停的檢查語法有沒有錯、不停的建置，永遠都在卡。
  引入相依性管理後，IDE 的反應才會快，你開發速度也會跟著快，
  生產效率就會大幅提高。

  但殘酷的是，通常若沒有足夠權限的高階主管支持你改革，
  要在長時間維護的舊專案引入這種管理專案的機制幾乎是不可能的。
  光是上面不寫程式的長官能感受到有這種問題就不容易，
  發現了往往也只會介定「IDE 讓開發人員一直等」只是感覺問題而不用優先解決，
  卻未必會細想 IDE 很卡其實是專案管理方式不佳的徵兆，這會明顯拖累開發效率。
  此外還有太多政治和技術問題，一般基層只能期盼未來新專案能一開始就有好規劃。

  其實這也是我最後決定做的事，在因緣際會下我調到另一個研究新開發技術
  以推廣到其他部門的團隊，而我也趁這機會以「典範轉移」號召大家引入好的機制。
  運氣好的是團隊成員既願意接納我的想法又很可靠，
  讓我們能一口氣換掉一堆腐爛的東西，導入好方法。

  檔案庫從完全不敷日常使用的極舊版本 CVS 換成 git、
  持續整合從公司人員自行開發，服務範圍很小又沒人會維護的伺服器換成 jenkins，
  建置從全公司都幾乎沒人想也沒人會維護的 ant 換成 gradle，
  相依性開始用 gradle 管理，還引入 Nexus 管理執行檔，工作環境煥然一新。

  如果你也想改善開發環境，升級大家的開發方法，就努力研究新技術新方法，
  找機會革新吧，不然這種開發方法落後又沒有主管在意的舊專案，
  還真的建議快逃，留下來往往是消磨鬥志罷了....

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.231.187.127
※ 文章網址: https://www.ptt.cc/bbs/java/M.1436275898.A.ED0.html
※ 編輯: dream1124 (61.231.187.127), 07/07/2015 21:34:41
推 felixgugu: 是很理想，但大多數時候太難了.....
推 qrtt1: 真是個好消息，寧靜革命終於開花結果了
→ qrtt1: @felixgugu 不要灰心，只需要持續做 http://bit.ly/1MbnR6o
→ qrtt1: soft_job 相關的系列「前輩拒絕導入任何其他工具」也蠻值得
→ qrtt1: 去回顧一下當下的困境與版友的建議的.
 寫那篇舊文的時候是初牲之犢不畏虎，那時候我在板上也被批得很慘，
 後來我也能體諒前輩說那些話背後的苦衷。

 不過我想可能是有自信，賭定新團隊要靠我研究新技術，不敢完全不理我的意見，
 然後也不怕黑不怕死吧，到新團隊以後還是有什麼想法都勇敢地用正用的方式提出來。

 運氣不錯的是團隊成員剛好各司所長，開發時程又能配合，導入新工具就比較順利。
 我有一樣是怪人，支持我理念的技術研發前輩跟我一起橫衝直撞，省很多溝通成本。
 前輩規劃新開發環境的硬體、選用作業系統和伺服器並調教設定，解除我的後顧之憂。
 而我則規劃應用程式要套用的框架，設計整合各框架的架構，然後選用並整合開發工具。
 此外還有適應公司文化，會用「公司慣用方法」和更上級溝通，潤滑兩方的 PM，
 以及善解人意又有耐性的同事幫忙我處理來不及做完的事情，驗證我設計的架構。
 最後我們就慢慢做到現在的狀態。

 雖然我們都很認真引入新工具，但這些事情能走到這步其實超過 40% 的比例是運氣，
 剛好天時地利人和都具備。目前革命也還不算完成，後續還有很多細節要規劃。

 另外我覺得自己經過這一陣革新之後應該也很黑，但我其實不是很在意更上層的看法，
 因為一來雖然不討厭政治，但我本來就不喜歡整天鑽研應對進退搞政治；
 二來有些高層的想法太舊又僵硬，只願意從他接受的管道用認同的方法溝通，
 我覺得自己沒有耐性花很多年慢慢跟他們磨合，升遷到有權限之後才來做這些事，
 到時候我早就年紀不輕又沒有熱誠了。

 他們願意接納提議，改善我受不了的環境問題... 很好，我們就來衝鋒陷陣
 他們不願意接納提議，又講不出好理由... 沒關係道不同不相為謀，適當時機分道揚鑣
 我是本著這種態度向他們推廣新事物的。

推 yfr: 哈，我想起那時候那篇文章了，你真是不簡單
→ yfr: 可以用一些先進的工具來簡化工作流程真是一件很棒的事
→ yfr: 我好奇的是為什麼選擇gradle而不是maven呢 ?
  因為我們專案建置過程複雜，用 maven 這種 xml 語法作為建置檔的工具較不易實現。

※ 編輯: dream1124 (61.231.187.127), 07/08/2015 01:51:43
推 yfr: 了解，大概懂你考量的點，我之前也曾經試過從ant升上去maven
→ yfr: 即便那時那個專案不大卻也有許多非正規maven建置流程的步驟
→ yfr: 那時就遇到許多挑戰了，有機會我會試著玩看看gradle
→ qrtt1: 所以，你是換了公司嗎 xd?
推 andymai: 推，上面和同事支持很重要，不然會心力交瘁，到最後一樣
→ andymai: 只好選擇離開
→ qrtt1: 其實只要同事不反對，沒有明顯抗拒就蠻容易成事了。
→ qrtt1: 因為導入新方法會有顯著的改善困境，享受過就「回不去了」
 其實我覺得某種層面來說，我是長期壓抑的開發人員之宣洩口。
 全公司只要還有在碰程式或技術的人幾乎都想改變，只有少數高層還是狀況外。
 職級差不多的人都滿支持我運用這些新工具和新方法。

→ realmeat: 從一個makefile換成另一個makefile.. 世界會變的更美好?
 試著從 Ant (不含 ivy 唷) 跳到 gradle 一次你就知道了
※ 編輯: dream1124 (118.160.99.40), 07/08/2015 21:26:45