CodeGym University
學習
課程
任務
問卷及小測驗
遊戲
幫助
學習提醒時程表
社群
使用者
論壇
聊天
文章
成功故事
活動
評論
訂閱
亮色主題
課堂
評論
關於我們
開始
開始學習
現在就開始學習
探索地圖
課堂
所有探索
所有等級
良好軟件架構的標準
Module 3 a ɛto so abien
等級 14,
課堂 3
效率 有經驗的程序員可以很容易地分辨出架構的好壞,但如果被要求用幾句話來描述它,他們不太可能做到。好的架構沒有單一的標準,也沒有單一的定義。 然而,如果你仔細想想,你可以寫出一些好的架構應該滿足的標準。一個好的架構首先是一個邏輯架構,它可以讓程序的開發和維護過程更簡單、更高效。 當程序具有良好的體系結構時,總是很容易理解它是如何工作的以及在何處編寫代碼。一個結構良好的程序更容易更改、測試、調試和開發。聰明人制定了以下優秀架構的標準: 效率; 靈活性; 可擴展性; 可擴展性;
不良軟件架構的標準
Module 3 a ɛto so abien
等級 14,
課堂 4
不良設計的標準 生活很簡單:通常,要聰明,你只需要不做傻事。這也適用於軟件開發:在大多數情況下,要想把一件事做好,你只需要不把它做得不好。 大多數程序員都有過設計糟糕的系統部分的經驗。但更可悲的是,你們中的大多數人都會有悲傷的經歷,意識到自己是這樣一個系統的作者。我們想要最好的,但結果一如既往。 大多數開發人員並不渴望糟糕的架構,對於許多系統來說,他們開始說它的架構很糟糕。為什麼會這樣?架構設計是從一開始就不好,還是隨著時間的推移變得不好? 這個問題的根源是缺乏“壞”設計的定
模塊化軟件架構
Module 3 a ɛto so abien
等級 14,
課堂 5
6.1 分解 儘管標準多種多樣,但大型系統開發的主要任務是降低系統的複雜性。為了降低複雜性,除了分成幾部分之外什麼也沒有發明。 有時,為了簡單起見,這被稱為“分而治之”原則,但是,從軟件架構師的角度來看,我們談論的是層次分解。 一個複雜的系統必須由少量較簡單的子系統構建而成,每個子系統又由較小的部分構建,依此類推,直到最小的部分足夠簡單,可以直接理解和創建。 好消息是這個解決方案不僅是唯一已知的,而且是通用的。除了降低複雜性之外,它還通過複製關鍵部分同時提供系統靈活性、良好的
正確的軟件分解
Module 3 a ɛto so abien
等級 14,
課堂 6
層次分解 您永遠不應該立即開始為您的應用程序編寫類。首先需要對其進行設計。設計應該以深思熟慮的架構結束。要獲得此架構,您需要始終如一地分解系統。 分解必須分層進行——首先,系統被分成大的功能模塊/子系統,以最一般的形式描述其操作。然後對生成的模塊進行更詳細的分析,並將其劃分為子模塊或對象。 在選擇對象之前,將系統分成基本的語義塊,至少在心理上是這樣。在小型應用程序中,這通常很容易做到:幾個級別的層次結構就足夠了,因為系統首先分為子系統/包,而包又分為類。 這個想法並不像看起來
如何鬆散軟件模塊之間的耦合
Module 3 a ɛto so abien
等級 14,
課堂 7
8.1 分解就是一切 為了清楚起見,一張來自一篇好文章“面向對象系統的解耦”的圖片說明了將要討論的要點。 您還認為設計應用程序架構很容易嗎? 8.2 接口,實現隱藏 降低系統耦合度的主要原則是OOP的原則和其背後的封裝+抽象+多態的原則。 因此: 模塊應該是彼此的“黑盒子”(封裝)。這意味著一個模塊不應該“爬升”到另一個模塊並且不知道它的內部結構。一個子系統中的對像不應該直接訪問另一個子系統中的對象。 模塊/子系統應該僅通過接口(即不依賴於實現細節的抽象)相互交互。因此,每個
依賴倒置
Module 3 a ɛto so abien
等級 14,
課堂 8
9.1 依賴倒置 請記住,我們曾經說過,在服務器應用程序中,您不能只通過創建流new Thread().start()?只有容器應該創建線程。我們現在將進一步發展這個想法。 所有對像也應該只由容器創建。當然,我們不是在談論所有對象,而是在談論所謂的業務對象。它們通常也被稱為垃圾箱。這種方法的支柱源於 SOLID 的第五條原則,該原則要求擺脫類並轉向接口: 頂級模塊不應該依賴於低級模塊。那些和其他人都應該依賴於抽象。 抽像不應依賴於細節。實現必須依賴於抽象。 模塊不應該包含對特
鏈接軟件模塊的替代方法
Module 3 a ɛto so abien
等級 14,
課堂 9
用消息傳遞代替直接依賴 有時一個模塊只需要通知其他人它發生了一些事件/變化,而這些信息以後發生什麼並不重要。 在這種情況下,模塊之間根本不需要“相互了解”,即包含直接鏈接並直接交互,但只需交換消息(messages)或事件(events)就足夠了。 有時似乎通過消息傳遞的模塊通信比直接依賴要弱得多。事實上,因為沒有調用方法,所以沒有關於類的信息。但這只不過是一種錯覺。 邏輯開始與消息類型、它們的參數和傳輸的數據相關聯,而不是方法名稱。這些模塊的連接性被抹黑了。 它曾經是這樣的
軟件生命週期
Module 3 a ɛto so abien
等級 15,
課堂 0
軟件產品生命週期的階段 高質量軟件的開發需要許多因素:合格的團隊、工作流規劃、產品符合客戶期望、按時完成。 1.需求分析 這個階段可以被認為是最重要的階段之一。項目的成功取決於它。這一切都始於項目目標的形成。然後列出要完成的任務和未來軟件的範圍。之後,明確了項目的條件、期限和預算。在第一階段的最後階段,開發團隊的技術任務得到批准。 2.設計階段 設計從定義應用程序架構、功能、功能要求和接口開始。然後在程序和用戶之間分配功能,考慮各種組件的要求。產品設計必須考慮客戶的期望及其實
瀑布 - 瀑布模型
Module 3 a ɛto so abien
等級 15,
課堂 1
級聯模型設備 瀑布模型,也稱為 Waterfall,是最著名的軟件開發方法之一。該模型的作者是溫斯頓羅伊斯。1970 年,他在一篇詳細介紹其優缺點的文章中描述了他的創新的本質。在同一個地方,他解釋瞭如何將這個模型細化為迭代模型。最初,在瀑布模型中,開發階段按以下順序進行: 需求的定義和協調; 立項; 編碼; 創建軟件產品的工作版本; 測試和調試; 軟件安裝; 支持。 根據瀑布模型,開發人員執行的操作是按順序發生的——逐點進行。首先,正在完成工作以確定並同意以待完成列表的形式的
敏捷開發方法論——敏捷
Module 3 a ɛto so abien
等級 15,
課堂 2
敏捷模型 靈活(敏捷)方法通過將工作流移動到幾個小周期中來幫助降低軟件開發的風險。這些週期稱為迭代,通常持續兩到三週。 迭代就像一個由任務組成的小型軟件項目,每個任務都會改進功能。其中包括:制定計劃、評估需求、就項目達成一致、編寫代碼、測試和創建技術文檔。 對於一個完整的軟件版本來說,一次迭代通常是不夠的。然而,敏捷的好處是項目的一小部分在每次迭代結束時都準備好進行評估。這允許團隊成員更改優先級以進行進一步的工作,而無需等待最終版本。 應用“敏捷”開發方法,您可以在每次迭代後
Scrum 簡介
Module 3 a ɛto so abien
等級 15,
課堂 3
Scrum 的歷史 自 1970 年溫斯頓·羅伊斯 (Winston Royce) 的“管理大型軟件系統的開發”報告發表以來,許多人都在嘗試尋找一種可以消除瀑布式開發模型缺點的方法。“瀑布”的替代方法是 Scrum 方法,現在將對其進行討論。 Scrum 於 1986 年得名於 Takeuchi 和 Nonaki 的著作《新產品開發的新規則》。本文檔認為,實現目標的最有效方法是為開發人員提供明確的行動計劃。 1995 年,Sutherland 和 Schweiber 出版了另
使用 Scrum
Module 3 a ɛto so abien
等級 15,
課堂 4
用戶故事 用戶故事是陳述開發中軟件需求的有效方式。這些故事包含代表軟件用戶的簡短建議。 由於在 Scrum 方法中,設定目標通常是客戶或軟件所有者的特權,因此它們被認為是影響開發過程的主要方式。每個用戶故事在文本量和呈現的複雜性方面都有限制。歷史通常寫在一張小紙上,這本身就限制了體積。 借助用戶故事,您可以記錄客戶的願望并快速響應市場需求。 用戶故事應該被視為一種簡單的需求度量,因為它不包括驗收測試程序。用戶故事的編寫必須符合准入程序。這將確保用戶故事實現其目標。 故事結構如
顯示更多
1
...
30
31
32
33
34
35
Please enable JavaScript to continue using this application.