乙個Java程式設計師的後台軟體設計流程

2021-09-20 03:06:28 字數 1369 閱讀 7508

個人見解,如有不足請批評指正。

需求分析 --》 概要設計 --》詳細設計 --》編碼 --》測試 --》交付 --》驗收 --》維護

了解基本業務需求

如何定義?(將自己定義成乙個黑盒,名字就根據業務自己編乙個)

這個黑盒存在的意義?(腦子讓屁憋了?當然是有人需要使用它才有存在的價值)

誰會用呢?(確定具體使用者及使用者組,這個要非常清楚,不然沒辦法繼續。換言之,都不知道有沒有或者有誰會用,用什麼功能,我還做這個幹嘛)

這群呆b需要什麼功能呢?(根據使用者抽取所有介面)

抽取之後呢?(內部/外部介面歸納、抽象、整理出乙個介面文件)

*************************=系統邊界已明確 ↑ ***日後如果有需求變動應該是這一環節出了問題

模組分析,根據介面設計分析一下,需要多少個模組(子系統),可以滿足使用者的需求

這些模組(子系統)如何組裝成乙個整體,之間的層級關係是怎樣?(整理出系統架構圖,可以畫圖說明)

繼續分析這些模組(子系統)之間的通訊方式(http、https、soap、mq等),以及對外的通訊方式

針對這些通訊方式需要有規範,建立通訊模型(可以用圖說明每種模型)

資料設計,大致設計即可,無需過細(例如,乙份資料對速度要求較高我可以存到記憶體或redis等非關係型資料庫,如果對安全性要求較高我可以存postgresql,如果需要輕量化儲存我可以存在sqlite)

根據已定內容進行框架選取(有的人是先選框架,後設計,這種方法是不可取的)

還可以完善一部分,測試、效能、部署、容災 等內容的說明,但是模組分析要做好

*************************=概要設計已完成↑*** 概要設計不能過度考慮細節實現和業務流程,這些內容應該在詳細設計中進行詳細設計和描述,如果多方面摻雜在一起考慮,就不能把一件事做好

細化概要設計中的業務流程和細節實現,概要設計之後的內容基本就是需要看著能落下**的內容了

針對每個模組進行實現的具體設計(可以使用類圖或包圖進行類描述有哪些功能或已經定義好的方法和依賴關係;使用時序圖描述每個類之間的呼叫關係、呼叫順序;使用流程圖進行具體流程、分支、異常的描述)

繼續細化流程圖,根據流程中使用到的資料型別,選定一些合適的演算法進行描述,反之針對一些特殊的場景需要指定一些特定資料結構以滿足系統要求

具體的資料庫選定,表結構,字段,關係的描述

根據模組(子系統)的難度進行工時估算

說明**版本管理工具(一般是svn和git)

*************************=詳細設計已完成↑ *** 這一步需要詳細,可以摳到具體實現邏輯,資料結構,演算法等碼人,開會分贓,講清楚工作內容,幹活,**評審,功能測試,壓力測試,交付

乙個年輕的JAVA程式設計師

我能抽象出整個世界 但是我不能抽象出你 因為你在我心中是那麼的具體 所以我的世界並不完整 我可以過載甚至覆蓋這個世界裡的任何一種方法 但是我卻不能過載對你的思念 也許命中註定了 你在我的世界裡永遠的烙上了靜態的屬性 而我不慎呼叫了愛你這個方法 當我義無返顧的把自己作為引數傳進這個方法時 我才發現愛上...

招聘乙個程式設計師

招聘乙個程式設計師,唯一對你有意義的是他能寫出好程式的能力。很少人像這樣去招人,他們更喜歡去挑剔程式設計師的個人癖好和性格缺點。你不如這樣說更合適 找不到那種技術上又好 又能適應企業文化的人,我就等著,一直找到為止。我們很少有敢這樣奢侈的公司,也許google可以這樣,就是google這樣的公司也一...

乙個程式設計師的忠告

諸位,咱當網路工程師也是幾年了,不算有出息,環顧四周,也沒有看見幾個有出息的!回顧工程師生涯,感慨萬千,願意講幾句掏心窩子的話,也算給咱們師弟師妹們提個醒,希望他們比咱們強!1 好好規劃自己的路,不要跟著感覺走!根據個人的理想決策安排,絕大部分人並不指望成為什麼院士或教授,而是希望活得滋潤一些,爽一...