什麼是遊戲陪玩app原始碼開發的過度設計，如何避免？

雲豹科技程式設計師發表於2021-09-26
遊戲APP原始碼
軟體設計(架構)往往在遊戲陪玩app原始碼開發中起到非常關鍵性的作用。良好的軟體設計包含了：靈活性、可伸縮性、可行性、可複用性、安全性,通過該一系列的定義,使我們影響到了遊戲陪玩app原始碼功能的設計和特徵。

一、什麼是過度設計

過度設計一詞在英文中稱為"over design",over意思是太多,design意思是設計、構思,通過教科書上面的解釋,意味著遊戲陪玩app原始碼設計的或構思的太多了,即為過度設計。
什麼是過度設計？設計出來的遊戲陪玩app原始碼比恰到好處要複雜或臃腫的多,過度的封裝、繼承、介面或是大量的無用配置方法,其實就是使用者需要一把殺雞的刀,而你卻設計出了殺牛刀或是電鋸。
過度設計通常來自於開發者將問題過於複雜化或是前瞻性欠缺。
在我們日常所犯的錯誤中,大部分是來自於前者,至於後者的欠缺,需要一定的遊戲陪玩app原始碼經驗和洞察力來支撐,能夠合理的預判和考慮需求會哪個方向發展。
在前者,問題複雜化會引入大量額外的代價,如成本上升，遊戲陪玩app原始碼缺陷增大、提升維護成本、降低系統效能。而高效能和可維護性都是系統的隱性需求,如果這些也沒實現好,那就可能屬於設計錯誤。
但是從客觀角度來看,能夠進行過度設計的，多半設計能力高於設計不足的,過度的設計改回來的成本也比設計不足的改過去的成本低的多,在此需要更多地去權衡"利與弊"。

二、過度設計案例

以遊戲陪玩app原始碼系統充值為例,最初你設計的系統只需要一個支付寶功能,你的資料庫設計如下:
id primary key int  //主鍵
user_id int//充值使用者
status  int     //-1充值失敗,0充值中,1充值成功
order_no string //第三方支付系統訂單號
amount  decimal //金額
但是沒過多久,你的遊戲陪玩app原始碼需要接入另一個支付系統-微信,需要區分使用者是通過微信還是支付寶充值的,於是你的資料庫設計便成了以下模樣
id primary key int  //主鍵
user_id int//充值使用者
status  int     //-1充值失敗,0充值中,1充值成功
order_no string //第三方支付系統訂單號
platform string //第三方交易平臺
amount  decimal //金額
但是你想了下,感覺可能以後需要接入銀聯支付,需要記錄是哪張銀行卡支付的,然後你又想了下,既然已經接入了銀聯支付,那順便就再完善以下,支援國際支付,如美元充值,港幣充值,然後需要記錄上當地充值的匯率及當地支付時間,最終你花了一天的時間,將遊戲陪玩app原始碼資料庫改成了這樣
id primary key int  //主鍵
user_id int//充值使用者
status  int     //-1充值失敗,0充值中,1充值成功
order_no string //第三方支付系統訂單號
platform string //第三方交易平臺
amount  decimal //金額
currency string  //貨幣:CNY USD HKD 
bank_id int //銀行卡ID
rate   decimal // 充值匯率
local_pay_time  //當地支付時間
完成基本設計後,你花了4周的時間完成遊戲陪玩app原始碼編碼和測試,最終交付了上去,然而系統的初衷只是需要簡單區分的是微信充值或支付寶充值,而因過度設計帶來的額外成本和缺陷是非常巨大的,為此我們需要盡力讓自己做的恰到好處並且避免過度設計。

三、如何避免過度設計?

避免過度設計的最佳方法就是“不要設計的太遠”,未了解實際未來,就做出了各種預設和判斷,為遊戲陪玩app原始碼增加了額外的負擔。
正如scrum(敏捷開發)所倡導的Evolutionary Design(演進式設計),將每一次的重構和迭代都對映和更新到最新的設計中來，從而最大限度的滿足遊戲陪玩app原始碼的功能性需求和非功能性需求。
當你手裡握著一把錘子時,不要把所有看到的,都當成釘子。
本文轉載自網路，轉載僅為分享乾貨知識，如有侵權歡迎聯絡雲豹科技進行刪除處理


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69996194/viewspace-2793829/，如需轉載，請註明出處，否則將追究法律責任。

相關文章