※ 引述《willy69wu31 (小小吳)》之銘言：
: 以往都是用 Eclipse 隨便搞搞了事
: 不過開始有越來越多的需求，尤其是程式碼管理，所以想尋找一整套整合的方案
: 不然每次一有新專案，就會有很多事項必須手動自己搞出來，有些麻煩
: 希望有:
: 1. 版本控制 (Eclipse 的 workspace 好像囊括了雜七雜八不適合直接塞 git 的檔案)
: 2. 自動編譯/打包/發行成 jar (還是，各位發行公開的 java 程式時都怎麼做?)
1, 2, 5 項要合在一起看。
=================================================================
1. 版本控制系統的強項在管「純文字」的東西，
塞 binary data 不是不行，只是享受不到版本控制系統的大部分優點。
加上即使用了 git 這樣分散式的版本控制系統，
因為需要協作的原因，還是會架設一些管理 repos 的伺服器
（別因為自己離 server 近就送一大堆 binary，
總有一天也會因為離得遠而歷經漫長等待，山水有相逄）
2. 為了儘可能發揮版本控制系統的優點與有效率取得專案完整內容，
使用相依性管理工具是建議的做法。
例如：
Maven, Gradle 或 Ant IVY
或各種方法（每間公司也可能有自己的神奇配方）
配合相依性管理的效果就是讓函式庫由 binary data 轉換成 字串。
這是什麼意思？也就是透過「宣告使用的函式庫與版本」取代
在專案內持有「實體的 binary data」
所以，最終進版本控系統的是一些宣告字串，
而非函式庫 binary data
因為歷史的因素，嫌 Ant 太 free-style 又無法做相依管理的開發者
建立了 Maven。Maven 骨子裡是個巨大的 Template Method，
流程都定好的，要擴充就只能在各種 phase 上掛上 plugin。
要擴充得弄清楚蠻多細節的，
主要是這個 maven 指令(phase) 走下去會執行哪些 goal
而你打算在特定的 phase 裡掛上你想要的功能，或覆蓋一些參數。
由於 Maven 的學習成本較高又因為 Scripting On JVM 的興起，
各類的 DSL for build tool 興起，Gradle 是其中的一支。
學習起來相對 Maven 來說是較為簡單，但取其許多設計概念與
Maven Repo 基礎設施，現在各大以 Java based 的社群漸漸轉向。
: 3. 自動建立單元測試
: 4. 程式碼自動格式化、變數大小寫自動檢查之類
: 5. 相依性管理，最好可以自動下載缺少的 jar 等
: 前陣子搜尋了一下，Maven 好像是一個還不錯的方案，搭配某些工具之後可以幾乎自動化
: 不過有關 Maven 的討論好少 orz (莫非有專板?)
: 不曉得各位通常都怎麼做? 有什麼建議的方案或觀念嗎?
3, 4 二樣問題的重點其實不在於工具。
而是人員的心態，是被逼著做，或迫於社會壓力而做。
先鼓勵大家養成習慣不時寫 unit test。
先不論寫 code 的品質，與 test coverage。
至少先有能力寫出一些關鍵部位的 unit test，再來漸漸朝習慣養成走。
何謂關鍵部位！？
1. 出錯會死得很慘的地方
2. 自己沒有信心寫對的地方
3. 人工測試很沒效率的地方（例如：啟動 web server 要等很久）
重點概念要重於物件的獨立性，可相互隔離測試。
起手時常因為所有東西都「黏」在一起而無法測試，
在還沒有學會切割責任範圍前，其實寫不出什麼有意義的測試
擁有這幾個簡單的觀念後，才可能對於更正規的學習材料更有 fu。
（那些書看不太懂，即為對 OO 的本質不夠貼近）
內功心法漸漸提昇是必然的，但有些副作用是意外收穫：
1. 因為會寫測試，可以不用再依賴 System.out.println 或 Logger
用眼睛在茫茫的訊息中找到資料在腦中查核。
2. 因為有寫了測試，有新的問題時可以先補測試，
人工步驟的 debugger 追蹤執行期系統狀態機會可以少一些
（使用 debugger 仍是個重要的技能）
3. 少了人眼追蹤與手動測試，減少視力與手腕肌鍵的傷害。
先把良好的氣氛與工作循環養成，才能開始來推行自動化的內容。
===========================================================
另外，有一些件是不太需要養成觀念就能自動化的。
因為這是避免人做蠢事，特別是在做系統上線或程式部署。
（DevOps 內的一部分）
回想起剛進公司時，MIS 單位要負責協助系統上線。
編譯好的 Code 由 RD 提供的，上線是怎麼搞的呢？
1. RD 將 Dev Server 經 QA 認證的版本打包成 WAR 交給 MIS
2. Server Admin (以下簡稱 SA) 將 WAR 推到 s1 (第 1 台部署 Server)
3. 由 s1 開始做最後的 check list 檢查
(至少會對版本對不對，上錯版的杯具不是沒發生過)
4. SA 用 rsync 開始同步 s1 至其他台，
每一台都需操作 application server 的 web 介面進行 context update
5. 重複 4. 至每一台 Server 完成
由於 s1 -> 其他台 server 有不同的部分最佳速度，加上 s1 頻寬有限
由 sN -> sM 都是 SA 手工依經驗上的最短路徑 deploy 完成的。
這手工的作業歷經了 3 個 SA
（確實很苦逼，上錯版，或發現有 bug 都要重做一回）
為何我那麼清楚呢？
不知道是不是巧合，每回 SA 離職都是由我代理的 囧rz
第 2 回代理的時間很長，那時就覺得這手工的東西是個大坑。
Application Server 那麼高檔的東西，一定會有神奇的部署方法才是。
查了查果真有 API 可以用，所以我們趁機會完成了 1 個指令部署
這只是一個針對於自動化 OO 議題的一點小經驗，
能減輕人工負擔的自動化要早點做，
會增加生手心理負擔的自動化要先養兵再來推動。