對 Java 開發人員最有用的 10 個網站
來源：
Tarun Telang 下面列出了有關 Java 技術的最有效、最值得信賴的 Web 資源。它們對於經驗豐富的 Java 程式設計師和初學者都很有用。多年來我一直在使用這些資源來尋找有關 Java 技術的最新資訊。
![喝咖啡休息#52。 對 Java 開發人員最有幫助的 10 個網站，您應該了解的 7 種軟體開發模型 - 1]()
此資源包含您需要了解的有關 Java 的幾乎所有信息，包括新聞、文章、部落格、參考資料、職業選擇以及與 Java 專案相關的資訊。我建議定期訪問此網站，以了解有關 Java 平台的最新消息。
如果您想下載並安裝最新版本的 Java 開發工具包，則必須使用此資源。它還包含有關如何在各種平台上運行 Java 安裝檔案的詳細說明。
Oracle 站點的這一部分包含 Java SE API 的參考資訊。HTML 文件是使用 JavaDoc 工具從 Java 原始碼產生的。
4.Java教程
有大量關於 Java 程式語言的教學和參考資料。這些課程也以書形式提供，即《Java 教程》第六版（英文版）。您可以點擊此連結從亞馬遜購買。
該網站包含練習測試和有用的資源，用於學習從 Java、資料庫、Android 到認證準備等主題。這是透過實作練習學習Java的一個非常好的地方。
在這裡您可以找到與 Java EE 相關的項目，以及先前託管在 Java.net 上的項目。該網站包含許多不同的項目鏈接，其中包含有關這些項目的附加資訊以及與這些項目相關的聯繫資訊。
7.Java百科
造訪此網站以關注有關 Java 技術和框架的討論、問題和解答。Javapedia.net 對於經驗豐富的 Java 和 Java EE 開發人員以及初學者和準備面試的學生都很有用。
8.TheServerSide.com _
該網站包含有關 Java Enterprise Edition 最新技術的資訊。Java 開發人員在這裡討論與 Java、Java EE、程式設計、軟體和伺服器端開發趨勢相關的各種主題。這是一個面向企業架構師和 Java 開發人員的非常大的線上社區，您可以在其中找到每日新聞、技術討論、網路研討會和其他有用資訊。
9.Java.com_ _
您可以在這裡找到最新的 Java 軟體（遊戲、行動和桌面應用程式）。這是安裝 Java 外掛程式的合法且安全的資源。與許多其他網站不同，這裡沒有彈出廣告或與 Java 實際上無關的可疑安裝檔。
10.Go.Java _
在這裡，您將找到有關 Java 如何支援為數位世界提供動力的創新的最新資訊。該網站包含學生、愛好者、開發人員和 IT 公司高管的 Java 平台資源集合。儘管您可以在Internet 上找到許多帶有Java 連結的類似網站，但其中大多數都已過時，並且顯示僅在Java 5 之前相關的資訊。自Java 8 以來，該語言發生了重大變化，這需要開發人員採取新的方法用Java程式設計。語言的發展也非常迅速，Java 每六個月就會發布新版本。
您應該了解的 7 個軟體開發模型
資料來源：
DZone 軟體開發生命週期是指以盡可能低的成本（最好是在盡可能短的時間內）規劃、設計、開發、測試和部署軟體的過程。為了實現這一目標，開發團隊必須選擇正確的軟體開發模型，以滿足專案的要求和所有利害關係人的期望。
![喝咖啡休息#52。 對 Java 開發人員最有幫助的 10 個網站，您應該了解的 7 種軟體開發模型 - 2]()
您應該了解 7 種模型，從瀑布模型到 V 模型再到 Scrum。讓我們逐一看看。
1.級聯模型（Waterfall）
![喝咖啡休息#52。 對 Java 開發人員最有幫助的 10 個網站，您應該了解的 7 種軟體開發模型 - 3]()
瀑布模型被認為是最早的軟體開發方法之一。從名稱中就可以清楚地看出，該開發過程包括按順序線性進展：分析、設計、開發、測試、部署和支援。每個階段都由具體結果明確定義。瀑布模型是順序的，這意味著只有當前階段完成後才能開始下一階段。當目標已經實現並且有人同意繼續從事該專案時，階段就被認為完成了。此模型沒有彈性 — 您無法跳過、返回或變更步驟。因此，開發過程可能會變得不必要的複雜和昂貴。與其他模型相比，缺乏靈活性使得該模型更加昂貴且勞動力密集。如果需求不明確或被誤解，那麼使用這個模型是非常危險的。此外，該模型對於需要更大靈活性的長期、複雜或正在進行的專案來說並不理想。儘管模型的缺點是顯而易見且顯著的，但它對於需求有限且期限短的小型一次性專案非常有用，因為它的設定簡單且快速。然而，團隊必須確保所有需求都被明確定義、明確且將來不能更改。隨著 IT 團隊採用更敏捷的軟體開發以實現持續改進，瀑布模型已經不再受歡迎。
2.V型
![喝咖啡休息#52。 對 Java 開發人員最有幫助的 10 個網站，您應該了解的 7 種軟體開發模型 - 4]()
V 模型（即批准和驗證模型）透過新增測試計劃來擴展瀑布模型。V 模型不是在軟體開發階段線性向下移動，而是向下移動到編碼階段，然後轉身開始向上移動通過測試階段，形成 V 形。每個開發階段都對應一個特定的測試活動。這使得團隊能夠在專案早期發現規範、程式碼和架構中的錯誤。添加測試計劃使 V 模型比瀑布模型有更好的成功機會。然而，V 模型仍然是線性的，這使得它不靈活。與瀑布模型一樣，團隊只有在上一階段完成後才能開始下一階段。這使得改變變得困難、昂貴且耗時。因此，該模型最適合具有固定、明確定義和記錄的需求的短期項目，但對於長期、複雜或正在進行的項目並不理想。
3.迭代（增量）模型
![喝咖啡休息#52。 對 Java 開發人員最有幫助的 10 個網站，您應該了解的 7 種軟體開發模型 - 5]()
與其他軟體開發模型一樣，迭代（增量）模型旨在克服瀑布模型的一些缺點。它也以規劃開始，以部署結束。但與瀑布模型不同的是，該模型涉及整個過程中的重複循環。這些循環可以是迭代的（重複的）或漸進式的（逐步的）。開發過程從一小組需求開始，其中的每個週期都伴隨著一組新的需求。此模型的迭代性質允許軟體不斷發展和成長，因為在整個過程中可以進行微小的更改。發生這種情況是因為新的迭代建立在前一個迭代的基礎上。開發人員可以根據之前週期的經驗進行更改。由於所有需求都不是在專案開始時就列出來的，並且在此過程中進行了許多更改，因此工作可以很快開始。然而，由於過程經常重複，資源很快就會耗盡，更不用說管理變得更加複雜。儘管該模型允許進行一些更改，但它仍然由明確定義的流程組成，這有時會導致不靈活性。進行變更的成本低於瀑布模型和 V 模型，但對於迭代過程中需求可能改變的專案來說，該模型並不理想。由於頻繁的變更、未知的成本和資源需求以及不確定的時間表，迭代模型會帶來更多風險。
4. 原型模型
![喝咖啡休息#52。 對 Java 開發人員最有幫助的 10 個網站，您應該了解的 7 種軟體開發模型 - 6]()
原型模型著重於透過創建原型來提高開發團隊對客戶需求的理解。透過創建所需程序的小型工作副本，可以在全面開發開始之前消除誤解。原型的開發、測試和最終確定均考慮了客戶的願望和意見。一旦原型被接受，團隊就開始開發最終產品。原型模型可以顯著減少迭代次數。這節省了時間並增加了客戶滿意度的機會。但是，您需要考慮開發人員花在開發原型上的時間。如果客戶需要大量更改、經常改變主意或提出不切實際的要求，那麼原型開發很快就會變得複雜。因此，最好在原型被接受之前限制允許的迭代次數。一旦最終原型開發完成，就不能對計劃提出進一步的要求或更改。這是原型模型的一個顯著缺點。
5. 螺旋模型
![喝咖啡休息#52。 對 Java 開發人員最有幫助的 10 個網站，您應該了解的 7 種軟體開發模型 - 7]()
螺旋模型著重於風險評估。因此，任何希望使用此模型的團隊都必須擁有在特定領域具有知識和技能的專家。該模型由四個階段組成：規劃、風險分析、開發和評估。螺旋圈數取決於特定專案和管理者的要求。平均而言，使用此模型的軟體開發需要 6 個月的時間。螺旋模型結合了瀑布模型和原型設計的特點，強調設計，包括原型設計（在設計階段），並遵循與瀑布模型中類似的步驟。持續和迭代開發允許開發人員進行更改並添加新功能。另外，開發是系統化的，簡化了流程。客戶參與週期每個階段的審查，如果沒有與客戶持續溝通，這可能會對開發過程造成負擔。由於沒有定義週期或迭代的數量，因此存在超出預算和錯過最後期限的風險。因此，創造成品通常需要大量的費用和時間。
靈活的方法（敏捷）
敏捷是一種基於
敏捷宣言中概述的 12 項原則的方法論。它更多的是一種心態，而不是一套嚴格的協議。敏捷方法旨在比使用先前的模型（包括瀑布模型）更有效地開發軟體。敏捷模型的本質是注重協作、溝通和不斷變化。敏捷開發有多種選擇。他們都專注於團隊合作、跨職能協作、迭代開發和早期客戶回饋。測試、回饋和變更使團隊能夠開發和發布更好的軟體。讓我們來看看 2 個敏捷模型。
6. Scrum 模型
![喝咖啡休息#52。 對 Java 開發人員最有幫助的 10 個網站，您應該了解的 7 種軟體開發模型 - 8]()
Scrum 模型是最受歡迎的敏捷模型。其開發迭代稱為衝刺。在這 1-4 週的衝刺中，團隊評估先前的衝刺、增加新功能並規劃下一個衝刺。定義衝刺活動後不允許進行更改。每次衝刺之後，都會添加新的功能/元素，這些功能/元素將在下一個衝刺中進行編碼和測試。這一直持續到所有功能都已新增並且項目被視為準備好發佈為止。跨職能團隊之間以及組織與客戶之間加強協作，可以減少因溝通不良而經常產生的誤解和錯誤。此外，額外的步驟可以縮短上市時間。改進的溝通減少了排除錯誤所花費的時間，並增加了最終用戶對產品滿意的可能性。然而，這種合作需要客戶大量參與工作過程。您還需要考慮到，如果客戶要求添加太多功能，專案截止日期可能會被推遲。
7.看板模型
![喝咖啡休息#52。 對 Java 開發人員最有幫助的 10 個網站，您應該了解的 7 種軟體開發模型 - 9]()
與其他模型不同，看板沒有明顯的迭代。當團隊計劃迭代時，它們的衝刺時間非常短，有時短至一天。為了直觀地指示項目的狀態和其他細節，使用了帶有貼紙（貼紙）形式的註釋的板。這種視覺化使團隊能夠專注於目前開發中最重要的功能。此外，看板強調功能還有持續改進的空間。雖然便利貼方法可以幫助激勵團隊專注於重要任務，但這是定義和維護時間表的糟糕方法。因此，規劃長期專案非常困難。由於沒有固定的計劃階段，因此可以隨時進行更改。看板的常見缺點之一是缺乏時間框架。如果不斷進行更改，這個問題可能會變得更糟。
過渡到敏捷
這些模型中的每一個都是為了改進軟體開發和交付過程而創建的。任何開發模型都可以很好地適用於特定類型的專案。然而，舊的手動模型，例如級聯模型，很快就會成為過去。一般來說，IT 團隊和公司在創建軟體、滿足客戶需求並跟上競爭對手時必須採取更快、更有效率的行動。更快、更可重複和更安全的軟體開發流程是基於自動化。由於許多模型無法達到自動化水平和速度，因此敏捷方法最終變得更加流行。
您應該了解 7 種模型，從瀑布模型到 V 模型再到 Scrum。讓我們逐一看看。
瀑布模型被認為是最早的軟體開發方法之一。從名稱中就可以清楚地看出，該開發過程包括按順序線性進展：分析、設計、開發、測試、部署和支援。每個階段都由具體結果明確定義。瀑布模型是順序的，這意味著只有當前階段完成後才能開始下一階段。當目標已經實現並且有人同意繼續從事該專案時，階段就被認為完成了。此模型沒有彈性 — 您無法跳過、返回或變更步驟。因此，開發過程可能會變得不必要的複雜和昂貴。與其他模型相比，缺乏靈活性使得該模型更加昂貴且勞動力密集。如果需求不明確或被誤解，那麼使用這個模型是非常危險的。此外，該模型對於需要更大靈活性的長期、複雜或正在進行的專案來說並不理想。儘管模型的缺點是顯而易見且顯著的，但它對於需求有限且期限短的小型一次性專案非常有用，因為它的設定簡單且快速。然而，團隊必須確保所有需求都被明確定義、明確且將來不能更改。隨著 IT 團隊採用更敏捷的軟體開發以實現持續改進，瀑布模型已經不再受歡迎。
V 模型（即批准和驗證模型）透過新增測試計劃來擴展瀑布模型。V 模型不是在軟體開發階段線性向下移動，而是向下移動到編碼階段，然後轉身開始向上移動通過測試階段，形成 V 形。每個開發階段都對應一個特定的測試活動。這使得團隊能夠在專案早期發現規範、程式碼和架構中的錯誤。添加測試計劃使 V 模型比瀑布模型有更好的成功機會。然而，V 模型仍然是線性的，這使得它不靈活。與瀑布模型一樣，團隊只有在上一階段完成後才能開始下一階段。這使得改變變得困難、昂貴且耗時。因此，該模型最適合具有固定、明確定義和記錄的需求的短期項目，但對於長期、複雜或正在進行的項目並不理想。
與其他軟體開發模型一樣，迭代（增量）模型旨在克服瀑布模型的一些缺點。它也以規劃開始，以部署結束。但與瀑布模型不同的是，該模型涉及整個過程中的重複循環。這些循環可以是迭代的（重複的）或漸進式的（逐步的）。開發過程從一小組需求開始，其中的每個週期都伴隨著一組新的需求。此模型的迭代性質允許軟體不斷發展和成長，因為在整個過程中可以進行微小的更改。發生這種情況是因為新的迭代建立在前一個迭代的基礎上。開發人員可以根據之前週期的經驗進行更改。由於所有需求都不是在專案開始時就列出來的，並且在此過程中進行了許多更改，因此工作可以很快開始。然而，由於過程經常重複，資源很快就會耗盡，更不用說管理變得更加複雜。儘管該模型允許進行一些更改，但它仍然由明確定義的流程組成，這有時會導致不靈活性。進行變更的成本低於瀑布模型和 V 模型，但對於迭代過程中需求可能改變的專案來說，該模型並不理想。由於頻繁的變更、未知的成本和資源需求以及不確定的時間表，迭代模型會帶來更多風險。
原型模型著重於透過創建原型來提高開發團隊對客戶需求的理解。透過創建所需程序的小型工作副本，可以在全面開發開始之前消除誤解。原型的開發、測試和最終確定均考慮了客戶的願望和意見。一旦原型被接受，團隊就開始開發最終產品。原型模型可以顯著減少迭代次數。這節省了時間並增加了客戶滿意度的機會。但是，您需要考慮開發人員花在開發原型上的時間。如果客戶需要大量更改、經常改變主意或提出不切實際的要求，那麼原型開發很快就會變得複雜。因此，最好在原型被接受之前限制允許的迭代次數。一旦最終原型開發完成，就不能對計劃提出進一步的要求或更改。這是原型模型的一個顯著缺點。
螺旋模型著重於風險評估。因此，任何希望使用此模型的團隊都必須擁有在特定領域具有知識和技能的專家。該模型由四個階段組成：規劃、風險分析、開發和評估。螺旋圈數取決於特定專案和管理者的要求。平均而言，使用此模型的軟體開發需要 6 個月的時間。螺旋模型結合了瀑布模型和原型設計的特點，強調設計，包括原型設計（在設計階段），並遵循與瀑布模型中類似的步驟。持續和迭代開發允許開發人員進行更改並添加新功能。另外，開發是系統化的，簡化了流程。客戶參與週期每個階段的審查，如果沒有與客戶持續溝通，這可能會對開發過程造成負擔。由於沒有定義週期或迭代的數量，因此存在超出預算和錯過最後期限的風險。因此，創造成品通常需要大量的費用和時間。
Scrum 模型是最受歡迎的敏捷模型。其開發迭代稱為衝刺。在這 1-4 週的衝刺中，團隊評估先前的衝刺、增加新功能並規劃下一個衝刺。定義衝刺活動後不允許進行更改。每次衝刺之後，都會添加新的功能/元素，這些功能/元素將在下一個衝刺中進行編碼和測試。這一直持續到所有功能都已新增並且項目被視為準備好發佈為止。跨職能團隊之間以及組織與客戶之間加強協作，可以減少因溝通不良而經常產生的誤解和錯誤。此外，額外的步驟可以縮短上市時間。改進的溝通減少了排除錯誤所花費的時間，並增加了最終用戶對產品滿意的可能性。然而，這種合作需要客戶大量參與工作過程。您還需要考慮到，如果客戶要求添加太多功能，專案截止日期可能會被推遲。
與其他模型不同，看板沒有明顯的迭代。當團隊計劃迭代時，它們的衝刺時間非常短，有時短至一天。為了直觀地指示項目的狀態和其他細節，使用了帶有貼紙（貼紙）形式的註釋的板。這種視覺化使團隊能夠專注於目前開發中最重要的功能。此外，看板強調功能還有持續改進的空間。雖然便利貼方法可以幫助激勵團隊專注於重要任務，但這是定義和維護時間表的糟糕方法。因此，規劃長期專案非常困難。由於沒有固定的計劃階段，因此可以隨時進行更改。看板的常見缺點之一是缺乏時間框架。如果不斷進行更改，這個問題可能會變得更糟。
GO TO FULL VERSION