像所有設計模式一樣,Maven是構建軟件過程的可重用解決方案。
我認為偶爾討論的Maven作為構建設計模式的概念是一個強有力的隱喻。 它很有用,因為它強調Maven與所有設計模式一樣,是構建軟件過程的可重用解決方案。 這是一個最佳實踐解決方案,經過多年的大量使用,這些社區已經由聰明人改進。 利用設計模式構建軟件的最明顯好處與編寫軟件的好處相同。 即:
- 您無需手動編寫即可獲得大量功能
- 了解適用于一個項目的模式的工程師可以立即了解適用于另一項目的模式。
名義上,第一個是生產力,第二個是簡單。 顯然,每個人都希望提高生產力,即用更少的代碼行完成更多工作。 但是,我實際上認為第二點-簡單-更為重要。 我認為,整個工程領域可以歸結為“管理復雜性”的概念。 就復雜性而言,我直接指的是當您被成堆的意大利面條代碼轟炸時感到的頭痛。 設計模式通過以較高級別的注釋密封大量的復雜性,有助于消除這種智力上的矛盾。 萬一您忘記了,這就是我們騰出更多精力處理不可避免地駐留在下一個級別上的更大更酷的任務的原因。
正是這種觀點使我將學習新項目的臨時構建列為職業中最煩人的方面之一。 即使非常干凈地實施了ant或make build,遵循了本地化的最佳實踐,并且自動化了軟件生命周期的廣泛范圍,它仍然會用大量的原始數據(即腳本行)來懲罰新開發人員。 請注意,這只是臨時性 。 當然,這并不是敲響這些工具。 ant尤其擅長自動化任務并提供可重用的構建小部件集。 但是,它無助于為構建軟件的整個過程提供可重用的解決方案,因此,它也無助于新開發人員輕松理解其構建過程。
對于像Maven這樣的CoC工具,最重要的約定是
因此,正如我所看到的,對于像Maven這樣的CoC工具,最重要的是約定。 為了成功使用Maven,您必須了解并遵循假定的約定。 不遵循約定的項目很快就會與Maven發生沖突。 首先,他們很難使用一種假定自己的構建過程的工具來實現自己的構建過程。 您很容易就無法輕松完成自己所做的事情而感到不安,但是前面的段落旨在表明實際上是您需要改變的人,至少在您打算繼續使用Maven的情況下。 選擇Maven時,您需要接受約定。 我不能,我建議您堅持使用Ant,它足夠靈活,可以按您的條件滿足您。 請記住,您正在失去利用Maven的設計模式方面來管理構建復雜性的能力。 如果您認為自己的構建沒有復雜性問題,請向自己提出以下問題:
- 我們團隊中的每個工程師都可以輕松構建我們軟件系統的所有組件嗎?
- 我們的工程師有信心修改構建腳本而不會感到焦慮嗎?
- 當需要有人解決構建問題時,我們的工程師會逃離房間嗎?
因此,如果您到目前為止與我在一起,您可能會同意遵循Maven假定的慣例是進入Maven必殺技的關鍵先決條件。 這就是導致我得出Maven文檔糟糕的結論的原因。 它們不僅不足,而且可能有害。 他們大多記錄了配置,而根本沒有提到約定的關鍵主題。 我認為對配置的強調在很大程度上是偶然的,這使新手認為配置Maven是可以的,甚至是正常的。
Maven文檔不僅不足,而且可能有害。 它主要記錄了配置,而根本沒有提到約定的關鍵主題。
通過文檔,我主要是指訪問Maven或Codehaus插件頁面時發現的所有內容。 例如,考慮極核心的maven-assembly-plugin。 瀏覽Maven網站上的文檔 ,您會發現它幾乎完全與配置有關。 正如我已經陳述和重申的那樣,問題是您真的不想配置Maven。 您想遵循約定。 配置應僅是最后的選擇。
插件放東西,然后下一個插件找不到那個東西。 使用配置文件告訴Maven在哪里可以找到東西,然后沒有該配置文件,其他任何人都找不到該東西。 配置Maven會使您陷入配置反饋循環中,并且配置的幾何增長不會使其具有pom可讀性。 即使可以通過配置Maven使Maven滿足您的需要,您也會很快得到一個難以理解的構建。
使用配置更改一個插件放置東西的位置,然后下一個插件找不到該東西。
因此,請避免配置! 相反,請遵循常規路徑。 您的工程師會知道并喜歡他們的構建,并且您將輕松利用Maven生態系統提供的許多好處-從豐富的插件庫到存儲庫服務器和構建服務器。
但是如何學習Maven約定呢? 這全都與社區有關。 幸運的是,這是一個非常友好的社區。 這是我在嘗試確定應如何在Maven中完成工作時使用的一些最重要的資源。
- Sonatype博客
- 堆棧溢出
- Maven用戶列表
此外,為了成為一個友好的社區成員,我正在使用此博客條目作為一系列Maven條目的介紹。 這些條目中的每一個都會概述重要的Maven約定。 我將詳細介紹約定并提供示例poms。 因此,如果您想了解Maven約定,請保持聯系。
參考: Maven不吸。 。 。 但是我們的W4G合作伙伴 Chad Davis 的Maven Docs Do來自zeroInsertionForce博客。
翻譯自: https://www.javacodegeeks.com/2012/04/maven-does-not-suck-but-maven-docs-do.html