想象一下，在一個提交界面中有兩個以上的提交按鈕，對于用戶來說是一種不良好的用戶體驗吧！實事上每個產品經理都能把握住這一點，從來也不會犯如此低級的錯誤，以至于養成習慣，甚至當出現合理的冗余時，竟會因為“重復了”這個理由去拒絕重復，
在一次產品評審中就遇到了類似的場景，我們的界面提交的資訊比較多，用戶操作習慣有兩組：直接提交、瀏覽后提交，前者較多，于是提交按鈕被設計在界面前部，
眾所周知產品經理是不大能聽程式員關于產品方面的建議的，我所提出的雙提交建議就被否決了，好在我找到了一個合理的案例：“郵箱的郵件發送功能”一般都是上下各一個，在使用的時候沒誰會覺得重復吧，反而會覺得很實用，我們的功能極其匹配，這才得以說服，
所以說冗余、重復也是一種手段，當然也不僅僅單是這些簡單的體現，在資料庫設計的三范式中也要求不要冗余，但隨著架構的不斷變更，冗余有時也能帶來更高的收益，歸根結底設計是一項比較靈活的事情，只有墨守成規才是萬年不可采取的思想，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/243514.html
標籤：架構設計
上一篇：計網實驗c/c++ 電子郵件客戶端程式實作發送接收郵件
下一篇：軟體架構C4模型介紹