一般情況下，所有的公司舉行年會都會有一個抽獎的環節，這也應該是全部員工們最關心的一個環節了，都非常希望大獎能夠砸在自己的頭上，成為最幸運的人，除了運氣之外，不免也有的同事會討論一下這個抽獎程序的具體算法規則，會討論抽獎的公平性，當然抽獎程序不是什麼複雜的程序，一個碼農很快就能搞定，那麼寫這個程序的人會不會在裡面設置一些偏向自己的規則呢，總之，大家不免會議論一下這樣的情況，近期，一名網友就給我們分享了類似的情況。
據這名網友說，他們的公司的年會的中獎概率有點「耐人尋味」，CTO說決定回去review一下抽獎程序，然後這個倒黴的程式設計師就決定上臺主動展示抽獎原始碼，可據這名網友說，當時在臺下的人就有1000多個，這樣的情況下review代碼實在是太「壯觀」了，他想了解這名程式設計師的心裡陰影面積，關於這個事情，也有網友說是去年就發生的事情了，不管怎樣，針對這種情況，讓我們一起看下其他的網友們都是怎麼看的吧！
網友一：挖槽？namelist？
上世是朵花：果真, namelist引起了別人的注意，和我想的一樣。
網友二：雖然不是碼農，但這代碼絕對寫得爛，要是一萬人的公司，你這namelist得多大
上世是朵花：你這只是假設呀，不同級別的人數，讀取方法也自然是不一樣，反正就一個抽獎程序，沒什麼難度。
網友三：代碼寫的有點弱雞
上世是朵花：這名網友將關注點放在代碼的風格上，並不關心抽獎的規則。
網友四：哈哈，這員工列表好多。不能讀取配置文件麼？這是應屆生的水平都不如
上世是朵花：多倒是不多，反正能一眼能看到邊，其實用工號抽獎是個不錯的選擇，也不會碰見重名的問題。
網友五： 這個namelist難道不能是伺服器端吐的數據麼，別亂噴，真的是
上世是朵花：這名網友的意思是上面的一些網友對namelist的吐糟並沒有說到點上。
網友六：不同規模的業務用不同的解決方案，這個是成本比較小，比較合算的方案，沒必要寫庫什麼的。一段js代碼搞定。
上世是朵花：沒錯，就一個抽獎程序而已，沒必要寫庫，不過感覺用工號代替namelist會更好一點。
網友七：別意淫一些不存在的場景，因地制宜，沒毛病！
上世是朵花：沒錯，有的時候業務場景在那擺著，大談特談程序的效率也是毫無意義，這樣的情況根本涉及不到什麼效率問題。
網友八：不說別的，namelist碰上同名咋辦
上世是朵花：namelist的確有可能碰見同名問題，這樣這個獎還不好發了，不知道發給誰了，當然，除非事先已經排除了有重名的可能了。
從評論內容就很容易鑑別出這些網友們大概率都是程式設計師，因為他們並沒有把關注點放在這個程式設計師此時的心裡陰影，或者說抽獎的具體規則什麼的，而他們的關注點則是放在程序的寫法上，對程序的寫法進行吐糟，津津有味的討論起來這個點來了，果然不出所料，大家吐糟最多的就是namelist的這種做法，的確這種做法顯的比較不夠友好，一個個名字往上填，顯的方法比較笨拙，同時也有可能重名的可能，如果用員工工號抽獎的話，就顯的更友好一點，不管怎麼樣，這只是一個抽獎程序而已，用不了那麼的講究，相比大家關心的點，我想其他非程式設計師們關心的更多的是程序中有沒有一些不公平的規則對吧，我想既然這名程式設計師同志敢於在這麼多人面前主動的review自己的抽獎代碼，我感覺這個抽獎程序還應該是公平的，大家說是麼？
以上所有圖片均來之網際網路 大家好，我是「上世是朵花」。如果你有什麼好的看法或者觀點可以在評論區展現你的才華，互動交流，如果想進一步了解我，那就關注我吧！