第一次接受一個大工程，下面分大約15個大模塊，我自己寫了一個主邏輯（還沒寫完）
現在想根據每一個模塊的輸入輸出寫一個檔案，請問這樣的檔案叫什么？
我希望開發人員看到我的檔案之后就知道要怎么寫函式，然后我直接拿過來拼接到我的邏輯中就可以了
uj5u.com熱心網友回復：
函式級別的集成是顆粒度很小的集成了。按照你的“大工程‘理解，15個大的模塊，要從下面幾個方面考慮。如果你做的是一種基于網路的資訊化系統
1. 大工程的需求部分，是啥子。比如，遠程醫學，那就有各種作業臺位和職能，牽扯到化驗結果、影像、病案多種品類的資料互動和可視化呈現，還有管理層面的藥計、財務審批等等。承擔這些職能的GUI背后，是體現作業流中物體-物件約束的資料模型。因此，一般設計一個大的系統，可以從資料建模開始，把資料流程搞清楚，再考慮具體的呈現。
2.你的團隊使用的工具鏈。是采用WEB的，還是C/S的。資料庫本身選型，你的資料是關系的還是非關系的。團隊能不能Hold住這些工具鏈，解決各種坑。有沒有能力做獨立的事務介面隔離資料倉庫和前端？如果沒有，又是互聯網的公共環境，則額外要考慮安全問題。
3.如果不熟悉軟體工程的標準開發流程，對UML不是很熟悉也無所謂。找幾個妹子，深入到客戶那里共同作業幾個禮拜，和客戶一起，把各個臺位上應該有的界面的樣子、行為用WPS或者Office的幻燈片變成界面示意圖，按鈕就是矩形，串列敲一些視圖上去，按鈕的跳轉體現界面的跳轉。每頁的備注里，注明資料來源、提交結果的請求介面，或者直接標明SQL陳述句。
4.有了這些，就可以外包給各個團隊了。
如果你做的是桌面版本的開發工具，比如CAD、Photoshop之類的專業的生產工具，則：
1. 切分主體作業的演算法模塊、可視化模塊、資料后臺。
2. 演算法模塊，抽象出介面。比如把所有影像處理都抽象為濾波、變換之類的矩陣操作。這里要考慮到你的團隊的技術水平。一般用各種底層手段實作插件式可擴展的演算法介面比較好。如果水平差，直接代碼集成。如果水平好，或者幾個開發部門需要獨立保留知識產權，則進行一定的二進制封裝。簡單是DLL，復雜的可以做為本地服務或者RPC。考慮到工具鏈的兼容性，盡量使用標準CAPI介面，避免使用C++，以便未來升級時候，編譯器版本的兼容性。 如果害怕扯皮，最好做成獨立行程的后臺服務，用DBUS或者訊息總線通信，這樣一個行程掛了，錯誤容易定位，邊界清晰好測驗。
3.界面模塊，取決于你的工具鏈。基本現在主流的GUI都支持MVC，但如果把界面部分包給各個組，則存在風格、扯皮的問題。界面只做最基礎的資料收集，和最末端的顯示。所有非末端資料，都在演算法里做完。比如，你要顯示聲音的頻譜，則最后把要顯示的FFT后的資料提交界面即可。
4. 資料部分：采用與工具鏈比較合拍的資料引擎。考慮到升級與部署，是用輕量的檔案資料庫(Sqlite)，綠色版本的All in one，還是獨立的Sql Server。采用不同的結構，有可能影響到軟體在不同環境下的部署。
對跨行程、跨機器的網路化的應用，建議不要從頭開始設計你的互動協議，而采用資料庫、訊息佇列等成熟的技術來完成交換。除非有能力Hold住協議設計和維護。
uj5u.com熱心網友回復：
另外，作為團隊的Leader，準備一個基礎的版本控制工具，比如Git、SVN是有效的，要求大家做Doxygen檔案也是必要的。這樣團隊的進度，可以直接跟蹤、回滾。如果大家在一個辦公室，則很方便，直接當面溝通最有效。小團隊，避免采用標準的軟工的各種檔案，會大量牽扯精力。uj5u.com熱心網友回復：
得先學習專案技術管理，望采納，不懂的可以關注私信我。uj5u.com熱心網友回復：
好厲害看的我一愣一愣的uj5u.com熱心網友回復：
你這個就是概要設計說明書，專門用來規定軟體的架構、各組成部分之間的關系、各模塊的主要功能和輸入輸出。如果再把各模塊的詳細演算法邏輯寫進去，那就是詳細設計說明書。這兩種檔案的寫法在GB8567中都有說明。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/283859.html
標籤：C++ 語言
下一篇：求解！！！