【StackOverflow】StackOverflow 一些入門技巧

因為突然很想要 upvote 跟 comment 的權限，所以這個月花了點時間衝 SO 的 reputation，發現還真是沒有想像中的容易，今天終於達成低標，心情好寫篇最近學習到的技巧紀錄下，內文為初學知識跟個人看法，歡迎留言分享討論。

Upvote (按讚、正評)別人的貼文，也就是

需要 15點的 reputation 門檻 (就是你在上面看到我頭像旁邊的點數，代表社群貢獻。)
按讚不會消費你的點數，但你必須達到門檻才能按讚，留言亦同。

Comment 文章，也就是在任意文章下留言

需要 50點的 reputation。

其他點數可以給你的權限像 125 點可以 downvote(負評、噓) 等，參考 Privileges
我個人是覺得有 50點可以留言就夠用了，不能留言真的還蠻痛苦的。

點數的取得

1. 回答被提問者接受，可以得到 15點
2. 貼文被按讚，問題可以得 5點、回答可得 10點
3. 針對別人的貼文修改被接受可得 2點 
4. 更多請參考 Reputation

由上述可知，基本你的點數都是來自問答，但是為賺點數隨意的濫問或濫答反而會收到一堆負評，而每一個負評會扣掉你 2點。

我個人的使用經驗，SO 用戶在給新手負評真的是毫不手軟，非常不友善；如果你點數很低，回答被負評不解釋(downvote without comment)可以說是稀鬆平常，你只能盡你所能的提高回答與提問的品質，隨著點數提高沒理由被噓的情況就會慢慢減少。

相對的，你可以透過刪文來拿回因為負評而被扣掉的點數；例如，如果你有個回答收到三個負評，-6點，你把那篇回答砍掉就可以拿回那 6點，不過太常砍文好像會有別的處罰機制(這是聽說的，我自己也只砍過兩三篇)，基本還是希望大家謹慎 PO文，真的被噓的太嚴重、太莫名，或知道自己的貼文真的是有問題會誤導人之類的再砍。

以下列出我個人觀察容易收到負評的貼文狀況

1. 格式沒處理好
這個理論上是小問題，但實際上很容易招致負評破窗，凡舉 code block 沒括好、圖片沒顯示、超連結沒標對，都可能變成人家不耐煩直接負評你的因素。

這個部份請詳讀這份 編輯指南，並善用即時編輯器下方的即時預覽功能，還有注意編輯器給的提醒。

另外，貼圖功能有 10點評價門檻，才能把圖片顯示出來，不然你的圖會只有一個超連結，這個也是我覺得蠻囧的一個地方，特別建議如果你沒有顯示貼圖的權限就不要貼圖，想貼圖結果只有一個超連結被噓文的機率蠻高的，不知道為什麼。

2. 重複的問題
你的問題以前有人問過，而且很容易可以搜尋到；基本上如果不是為問而問，有先搜尋過，這項不會很容易發生。

3. 不明確的問題
這個是最常被噓爆的原因，比方，沒貼錯誤訊息、沒貼你實作的 code，或者只說 it didn't work，但沒說你的預期跟實際的差異等，這項最容易被噓的是，應有 code 但沒貼 code，其次是標題或內文無法表達明確的單一問題，例如

I have an Error please help
從標題完全無法得知問題相關內容，非常差。

I have a XML problem using C#
比上面好一點，但對於表達問題仍然十分不足。

Error deserializing XML in C#
還算可以，其他人至少可以大致猜下你的問題。

How to deserialize XML with preifx namespace using C#?
通常你能把問題明確化到這種程度，普遍會直接找到現成的解答，如果以前沒人問過，那就會是一個有價值的問題。

4. 討論性質的問題
沒有標準解答的問題，比方 C# and Java which is better? 這種幾乎是閒聊的問題。
在這項裡面比較模糊的是問效能與設計的問題，比方

StringBuilder, string.Contact or just use + which is better?
或 Difference between StringBuilder, string.Contact or just +
後者幾乎必定是重複問題，早期問這類問題的人就點數爽賺。

前者，先說結論，我建議不要問，就算沒有重複也別問；如果你要問就一定要提供 Context，交代你是在什麼情境下比較這些作法，然後要比速度、資源耗用度、可讀性、擴展性，還是比什麼別的都要交代清楚，最好還要講下要比這些的理由。

基本 SO 是讓你問有正確答案、可行解法問題的地方，討論性質的問題大多是點數破表的人在提的，點數低還是不要討噴比較明智。

如果你想問的是設計問題，比方在你專案的某個業務邏輯使用某設計模式是不是對的，你可以考慮用 code review meta。

※ 補充參考1，可能被 put on hold(凍結、保留)的問題類型。
※ 補充參考2，提問守則 how to ask。

※ 補充參考3，是否離題(比較深入的可能被噓文理由) on topic。
這個還蠻重要的，特別獨立講下

一、debug
debug 型的提問應包含輸入與預期輸出，非邏輯型錯誤應包含 exception message，不能只寫 it didn't work；bug 應是可重現的，即使是機率性重現，提問也應包含能造成此機率性重現的程式碼或相關資訊。

二、問作業
提問應包含你目前為止已做的程式碼跟具體的困難點，而非一個空泛的題目，比如
An ajax post in asp.net mvc
As title, any help?
是不行的

How to do jquery ajax post with viewmodel property as data?
附上 jq 程式、viewmodel property 結構,值 和預期在 Controller 收到的內容，會比較被接受。

※ 補充參考4，最小有效範例。

三、問書, 工具, API(Software lib)與其他資源
我覺得禁問工具跟 API 真的還蠻怪的，查了下主要是這類回答會偏向連結，而連結會失連，還有這屬於意見性問題，而 SO 尋求的是有正解的問題，但我個人覺得比起重複造輪子，上面的問題都還好。

四、硬體, 網路, 伺服器, 權限設定等非程式問題
非程式問題只能提問其與程式相關部分。

5. 抄襲的回答
你的解題跟別人的方法太雷同，畢竟是解同樣的問題，還蠻容易發生的，討厭的是很多時候其實你真的也是自己想的，但你送出的時戳就硬是比較慢，這時候也只能默默自己刪掉，不刪幾乎肯定會被噓。

這項要特別注意的是問題下面的註解，有些人懶得打一篇回答，只在留言處給些關鍵字或連結，如果你的解是一樣的做法就不要答了。

6. 文不對題的回答
通常會發生在問題很長，你略讀覺得自己有捕捉到問題的主旨，但其實沒有。 或者提問者問的不清楚，在補充時才大幅度的更新甚至修改問題，但你沒追蹤更新你的回答，後來讀的路人也沒仔細看就噓你。

7. 具誤導性的回答
也就是你的回答真的存在瑕疵，這種被噓我覺得值得；比如，問一個 SQL 查詢的串接，你提出一個可以正確運行的命令提議，但它存在某種被 inject 的風險。 通常這類型的負評，留的人會留言給你，也算是上一堂課。

8. 回古文
回答已被解答一段時間或已有多個正評回答的問題，會受到比較嚴格的檢視，如果你的答案不是特別有創見或因為技術推陳的新解，被噴的機率也是蠻高的。

9. 因為你菜!
好吧，或許這是我個人的感覺，如果你也碰到沒理由的負評，你留言問也沒人鳥，那還是只能默默吞下去，除了點數之外或許你可以考慮刷些徽章，讓自己看起來菜味不要那麼重。
徽章的取得參考 Badges。

那所以要怎麼比較有效率的取得評價點數呢?

首先我建議不要想靠問問題拿點數。
基本上你可以想到的比較通泛、簡單的小問題，幾乎可以肯定有人問過了；相對的，如果是非常深入、專門的具體問題，會答的人很少、對你問題有興趣或會因你問題受惠也很少，也就是不太有機會拿讚，所以提問真正有需要知道的事就好。

回答的部分，鎖定剛出爐的問題與自己專精的領域
在 Questions 選擇 newest tab 與自己擅長的 tag 去篩選問題，就可以比較快速的找到適合自己回答的有效問題。

有些時候也可以做做苦工，幫新來的人修 code block、讓圖片可以顯示或 quote 錯誤訊息之類的，提問者或權限很高的用戶接受你的修改後，你也可以賺個 2點貼補家用。

最後附上 SO 官方的入門導引，你可以在結尾的地方連到 help center 看更多。