最近專案裡涉及到交友的功能模組,一下子也下不了定論,正好看到網上有篇文章討論交友的單雙向模式,特來看看大家的意見,以下為網友文章,鏈結
白鴉很早就寫過一篇文章，《常見功能之「好友」設計》，**互動**中幾乎必配的 「好友」功能。文章中，白鴉的觀點是[b]：「張三認為李四是他的好友，那麼李四就是他的好友。。。。。。所以，張三如果加李四為好友無須李四同意」；因此白鴉說：「我基本不贊同99%的「需要對方驗證才能新增對方為好友」的做法」。[/b]
不過，雖然web模式下的好友不重要，但對於一些**，比如螞蟻網，因為某些特殊原因，雖然不是交友**，但好友設計也非常重要。所以在考慮螞蟻網的時候，我把好友的問題梳理了一下。
先說單向好友模式到底有什麼好？兩個字：「輕盈」。這兩個字解釋起來就是一篇長文，所以我只談一下其內在邏輯：單向好友的模式是符合web模式下，使用者交友特點的——除了我上面說的兩類特殊**，其他**的使用者壓根不在乎web模式下交友；所以乾脆站方就做乙個「輕」的應用：大家隨便加好友，你愛加誰是誰。打個比喻，這其實和貼吧類似：反正大家就是上去扯淡，乾脆也不註冊了，大家隨便扯。
再說單向交友模式有兩個問題：
第二，單向好友功能，其本質是一種「訂閱」關係，所以如果以「好友」之名，有點名不符實。這算是乙個真實的麻煩。有的**，比如豆瓣換成了「友鄰」。我認為這樣稍微換個說法，要比直接用「好友」好點。
所以到這裡，我還是基本同意白鴉的觀點；但我有個補充，「對於非專業的交友**，或者**主要業務不是建立在「好友」關係之上」；那麼，確實可以99%的好友關係是「單向」的——因為對他們來說，「好友」壓根不重要；那就不妨「輕盈」地處理它。
那麼，為什麼需要「雙向好友」模式呢？我剛才說了，「單向好友」模式其本質是「訂閱」，而不是真正的「好友」——只有「雙向好友」模式才能真正開始「好友」之間的互動，否則兩個人的關係只能是「訂閱」關係。
單向模式「輕盈」，但只是訂閱，不能建立好友之間真正互動；雙向模式能建立好友互動，但笨拙。那麼，我乙個站上，能否把這兩種模式同時都使用，讓使用者自由選擇呢？——我認為，這樣做產品的思路，是有問題的：表面上，你提供了乙個全面解決方案，但更大的問題出來了：你站方準備引導使用者使用哪種服務？本來100個人，要麼用單向，要麼用雙向，都能玩起來；但現在你潛在誘導讓50人用單向，50人用雙向，兩種模式都玩不起來。
那麼能否優化一下呢？比如，當「張三」加李四好友後，張三就完成了對李四的訂閱（單向）；同時李四收到需要確認訊息「你同意張三加你為好友嗎？」。李四如果「同意」，則張三和李四建立雙向好友；李四如果不同意，也不撤銷張三對李四的訂閱——這個方案比上乙個方案優化了一點，因為它弱化了兩條線的引導，還是只強調了單向好友這一條線；但又有了雙向補充。不過，我認為這樣的優化方案依舊不可取，因為這個方案還是會需要使用者在內心建立兩個模型：1，真正的好友（雙向）；2訂閱關係的好友（單向）。我認為，這樣會為使用者增加困擾，得不償失。
總結一下：
1，web模式下的好友關係，不是想象中那麼重要，多數情況下，單向好友足夠
2，使用「雙向模式」的條件是**的關鍵業務，需要建立在好友關係之上
3，要麼單向，要麼雙向，不要試圖同時單、雙，那是小聰明，會增加使用者困擾
買房應該全款還是貸款
一般都是發些技術博文,這篇隨性講點其他的內容 買房 首先我們簡化一下買房這個問題,不考慮買房賣出 通貨膨脹等問題,僅考慮最樸素的情況,假設我們有初始資金 f ff 50萬 500000 f 500000 f 500000 f 5000 00我們想要購買一套房子,p pp 也為 50萬 不考慮交易稅費...
無論如何，還是應該感激
畢業時，憑藉在一家頂級軟體企業面試中積累的經驗 雖經歷了漫長的面試，最後慘遭淘汰，但是還是獲得了不少面試的經驗 順利地進入了n公司，一家知名的網路公司的研發部門。懷著孩子般的感激，在進入公司的最初的日子，過得相當幸福，做著自己擅長和喜歡的東西，純粹而又高效。在很短的時間內通過試用期後，取得了稍高於預...
自動判斷應該Ajax還是return
最近回顧以前的 發現乙個偶爾會見到的現象。乙個類裡面的方法可能需要ajax返回，也有可能需要函式return。這個現象發生在 mvc中的 邏輯層 或模型層 示例如下。indexctrl是控制器負責渲染頁面，proctrl是邏輯器負責讀取處理資料，a函式是例項化乙個類，m函式是讀取資料表的意思。現在只...