今年3月以後，世界上很多國家都因為新冠疫情的肆虐封鎖了邊境。英國政府曾提出“群體免疫”策略，不過在參考了一些學術機構的報告後，最終採取的還是封鎖隔離政策。而這些學術報告中最值得一提的，就是英國帝國理工學院（IC）的研究報告，該報告建議務必實施嚴格的封鎖。
人們的生活隨封鎖發生了天翻地覆的變化。當大家不能再隨意握手、擁抱，當很多禮節與風俗都需要改變甚至避免時，人們肯定想問，疫情真的有那麼嚴重嗎？
疫情就像是懷疑論的溫床。英國就有一個叫做“質疑封城”（lockdownsceptics.org）的網站，懷疑論者們會在上面釋出一些有關封鎖的新聞，並刊載一些反對封鎖的觀點與分析。
既然不願相信疫情的嚴重性，也不斷否定封鎖政策的價值，懷疑論者當然就要從政策所依賴的研究下手。如果帝國理工學院的研究不再可信了，據此施行封鎖還有什麼道理呢？
尼爾·弗格森（Neil Ferguson）是一位數學生物學教授，在帝國理工全球傳染病分析中心擔任疫情建模負責人，他也是整個封鎖政策的核心人物。今年5月，因封城期間被爆出破壞自己立的規矩，私會情人，弗格森教授被迫辭職。在他陷入風波的時候，不少懷疑論者更是利用弗格森教授信用危機的機會，對他主導的研究進行批評。
這是一場“帶風向”的爭論
今年5月初，一名自稱是谷歌前員工的人在“質疑封城”網站上發表了一篇文章，內容是對弗格森教授疫情研究所用的程式碼進行評審。
帝國理工學院會把他們的研究程式碼上傳到github。github 是一個開放原始碼、讓全世界程式設計師協作編寫軟體的網站。既然大家都能看到研究的程式碼了，那麼就可以針對程式碼進行評審。所謂的程式碼評審（code review），通常是程式設計師們你看我寫的程式碼，我看你寫的程式碼，互相挑錯，弄完之後專案質量就會變棒棒的一種活動。
而這篇文章並沒有對專案的核心部分提出什麼有價值的分析與質疑，結論卻是“只要用到這項研究程式碼的論文，都應該立刻被撤回”。這篇文章為“質疑封城”吸引了大量流量，網站月均瀏覽量從不到10萬增長到超過40萬。目前文章已經有快700條留言，其中一個使用者留言說，要去原始碼所在的地方釋出一個 issue，目的呢，也是要求撤回論文。
github issue 就像社群中的帖子一樣，是供大家討論事情的，不過得討論專案有關的問題，儘量別跑題。讓我們先來看下這個專案之前的 issue 是什麼樣的：
1）某個檔案第幾行的程式碼，關於每年有多少天的變數應該是365而不是364，還有會不會其實應該是365.25？下面的回覆解釋了為什麼要用364而不是365，大家都瞭解以後此 issue 被關閉。
2）某個部分的執行需要測試。回覆裡有人說，是的呢，但你提到的測試型別不一定合適，你有具體的測試策略嗎？之後又有人提出這裡有我寫的測試程式碼，若是合適的話請合併到專案裡。
也就是說，提出一個 issue ，主要目的在於對這個專案能有所貢獻，無論是指出它的問題，還是提出應改進的地方，之後大家圍繞專案程式碼你給點意見我提交下程式碼，最後這個專案就變得更好了。
可懷疑論者釋出的這個 issue 說了些啥呢？“這些程式碼的測試太爛了，無法用於科學目的，不符合科學方法”，“因為這項研究，幾十億人的生活被打亂”，“作為公共政策，是以此研究非常準確為前提的，這真是個災難”，“程式設計師們，請簽名以表贊同吧”。
帝國理工學院從3年前就在 github 上釋出其各項研究所使用的程式碼，但並沒有什麼人看。可這樣的一個 issue 一經發表，卻吸引了很多不明真相的人前來圍觀。點選收藏此專案的人數從不到300快速增加到了接近900。
弗格森教授其實是重用了13年前用於流感大流行建模的程式碼，而在釋出前它已經在 github 與微軟的幫助下大大改進了，參與改進的人還包括傳奇程式設計師、自由軟體倡導者約翰·卡馬克（John Carmack）。13年在軟體工程領域算是不短的時間，並且經過了這麼多人的努力，目前的程式碼已經比較符合現代規範。而事實也證明，英國政府採取帝國理工學院建議的封鎖策略後，死亡人數下降為預期的1/28。
故事到此就很清晰了，這個issue明顯是要帶風向，去否定研究得出的結論。懷疑論者是在利用程式設計師的身份與專業背景去挑戰弗格森的研究，進而表達自己的政治訴求。他們之前就一直在指控是帝國理工學院與弗格森教授讓大家倒了黴，整個西方經濟都因此停滯。“程式碼釋出在 github 上了？太好了，公開了就好辦了，集中炮火打擊”，這就是他們的想法。
“程式碼風格”很重要，卻不一定影響結果
可為什麼很多程式設計師這麼容易就被人利用了呢？因為上面提到的issue還提到了專案的程式碼風格很爛，大家一尋思，這種情況下的軟體一般都問題不斷。據此推測，這項研究也肯定漏洞百出了。
程式碼風格究竟重不重要其實在軟體行業裡也是一直受爭論的話題。良好的程式碼風格，特點是使程式碼易讀，比如一個人的名字被用作變數，那麼起名叫 name 就比 x 強很多，這不僅利於專案進行中的協作，對之後的維護工作也至關重要。對程式碼風格的追求主要是因為在現代軟體行業中，協作是無法避免的事兒，你寫完的程式碼還得給其他人看，也無可避免地需要修改其他人遺留下的程式碼。一個專案以後再想加點什麼、減點什麼、改點這裡、修點那裡，要是看不懂可就沒招兒了，這也就是對軟體行業的重構有所幫助。
不過話說回來，很多時候，程式碼寫得漂不漂亮也不見得就跟最後的結果有直接關係。比如之前大火的遊戲《太吾繪卷》，它的作者就不咋懂寫程式碼，整得一團亂，但也沒礙著作品創意。科研工作怎麼寫程式碼，寫什麼樣的程式碼，是科研人員為了得出結論所用到的手段罷了。這種情況下，可能過程就真沒有結果那麼重要。
事實上，不少重要的數學程式碼庫都是由科研人員編寫，若有意願的話，他們有能力寫出優美健壯的程式碼。但現實中，不少科研人員都需要迅速發表論文，這時候他們的程式碼在專業程式設計師眼中就沒那麼專業或者嚴謹了。人人都希望看到質量良好的程式碼，把程式碼公開可能是幫助其改進質量的第一步。
公開程式碼，需要善意的環境
在專業人員的指導下，透過專業方法，科研領域的程式碼風格應該會越變越好。
當然，一切的前提是善意。都是程式設計師，有些呢，對緩解新冠疫情作出了自己的貢獻，他們根據公開的原始碼，提出問題和建議，改進專案。可另一些呢，比如那些懷疑論者們，基本就是在添亂了。立場和偏好會先入為主地影響對事情的判斷，即使很多程式設計師明白程式碼風格不等同於軟體質量或科研成果，還是會因為以上原因去攻擊對方。
這些舉動是很危險的，它可能會減少科學家們公開程式碼的動力，甚至還會使得正當的同行評審更加困難。
每項公共政策乃至每項科學研究都可能有爭議，很難讓所有人滿意，也很難令所有人信服。今年的疫情或許讓社會氣氛變得更加緊張，什麼政策都會被用放大鏡檢視。
其實之前英國 “氣候門”（Climategate）事件就與這次反對封鎖的情況有些相像。當時英國東安格里亞大學氣候研究小組的郵件往來被駭客入侵，隨後該小組被指控操縱資料、偽造科學流程。最終英國獨立調查人員在徹底調查後指出：科研人員誠信完好，方法健全，但缺乏透明度，建議公開所有相關的資料與程式碼。
在此之後，公開研究使用的程式碼在氣候學領域已被普遍實踐，那麼在其他領域的科學研究中，這種舉措是否值得參考？在今年疫情中，把相關研究的程式碼公開，程式設計師們或許也能更好地理解科研是如何進行的。與此同時，因為參與開源，所有人都可以為科研程式碼質量的提高貢獻自己的一份力量，建議與批評也都會更加有理有據。
作者：iou90
編輯：黎小球
