維基百科:像好的程式設計師一樣

維基人里本來就有一部分是程式設計師或者做過程式設計師，而軟件開發業界有一個有趣的現象就是可以看到各種各樣的論述和實踐。當然了，隨着時代的變化，上網的人群越來越大眾化，維基人里程式設計師的成分也自然會降低。

不論如何，從軟件開發業界搬運一些思想方法和實踐，是值得嘗試的。比照軟件開發業界的思想方法和實踐，也可以印證和修正中文維基百科的一些慣常認知和實踐。舉例來說，中文維基百科曾經長期普遍誤用鴨子測試，但一個好程式設計師自然知道鴨子測試不是用來「一望而知」的，所以WP:鴨子測試解釋為一望而知顯然是錯誤的。

並非所有的軟件開發業界的思想方法和實踐都適合維基百科，但如果一個人實際掌握了那樣的方法，不妨嘗試在維基百科應用。畢竟維基百科的內容雖然不是軟件，但在線協作這件事難道不是軟件業界所擅長的嗎？

可以借鑑軟件開發方法的例子

• WP:鴨子測試
  • 其實鴨子測試是一種認知（打標籤）的方法。基於鴨子測試，可以用行為、特徵屬性來定義類型。如果說特徵的屬性是關於特定條目主題的知識，那麼如何確認特徵的屬性就是關於知識的知識，可以指導人如何寫條目。
  • 比如鴨子「有兩隻腳」，「會嘎嘎叫」，「會游泳」，那麼所有繼承/擴展鴨子類型的類型都具備這些行為/屬性。A是一種B，那麼A擴展B，A具備B的行為、屬性。這種認知是歸納性的。寫條目時，類似地，自然會想到，「騰訊是一家公司」，那麼一般而言公司的屬性騰訊都該有。在寫騰訊這個條目的時候自然應該先列舉所有一般而言公司的主要屬性，比如業務內容、規模、歷史、資本來源、產品等。實際情況可能不是單獨一次擴展，而可能是多重擴展，比如「騰訊是一家軟件公司，一家軟件公司是一家公司」，「騰訊是一家中國公司，一家中國公司是一家公司」等。
• 測試驅動開發
  • 什麼？這也能用到寫條目上？當然能。在編寫出條目內容之前，先想好寫出來的條目應該包含什麼樣的內容。再具體一些就是：寫條目之前先準備好一些問題，條目寫出來之後看看能不能清晰地回答這些問題。問題當然是因條目類型而異，比如對一個政治人物條目來說，通用的問題可能是：「這人有什麼成就和影響」，「這人作為政治人物有所成就和影響時屬於哪個政治團體」，「這人的人生經歷是什麼，此人怎樣成為了後來為人所知的樣子」。如果一個條目是以從來源複製粘貼文字、潤色而敷衍而成的，就算能夠回答上面的問題，在回答上面的問題之後剩餘的內容很可能是比例不當的。比如「用了過多篇幅描述此人在尚不是政治人物之前的經歷」，「描述了太多對世人而言影響不大但是可以誇讚、吹捧傳主的細節」。
• 豬與雞
  • 這個不是方法而是思想。讓做具體事的人有更多的ownership。
• review
  • 軟件行業的review本身倒不是說沒有很多有趣的有用的方法，但對於中文維基百科而言，最需要借鑑的是「誰來做評審」這件事：你不能找不干正事的人來評審。如果軟件行業的評審像中文維基百科一樣充斥着不負責任的(＋)支持和不負責任的(－)反對，如果像中文維基百科一樣有不少人對評審意見敷衍推搪，軟件早就爛得沒法用了。當然了如果中文維基百科是個軟件，它確實一直質量爛得不行。只不過中文維基百科人很多根本不在乎中文維基百科爛不爛而已。