hello大家好，我是小樓。
創(chuàng)新互聯(lián)從2013年成立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都網(wǎng)站建設(shè)、成都網(wǎng)站制作網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢想脫穎而出為使命，1280元確山做網(wǎng)站,已為上家服務(wù),為確山各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18980820575
不知道大家還記不記得我上次找到了一個(gè)Go的Benchmark執(zhí)行會(huì)超時(shí)的Bug？就是這篇文章《我好像發(fā)現(xiàn)了一個(gè)Go的Bug？》。
之后我就向Go提交了一個(gè)PR進(jìn)行修復(fù)，本想等著代碼被Merge進(jìn)去，以后也可以吹牛說自己是個(gè)Go的Contributor，但事情并不順利，今天就來分享一下這次失敗的代碼提交。
在我意識(shí)到Bug時(shí)，就迫不及待想去修復(fù)，于是有了這一次提交。
在說代碼前，先說點(diǎn)關(guān)于Go倉庫的問題，Go并沒有直接托管在github，而是自建的Gerrit Code Review，github上只是個(gè)鏡像倉庫，所有在github上提交的issue和代碼都會(huì)被一個(gè)機(jī)器人搬運(yùn)到Gerrit上。
而且Go對(duì)提交代碼的要求是必須關(guān)聯(lián)一個(gè)issue，于是我就提了一個(gè)，自問自答了屬于是。
描述了一下遇到的問題，但隔天被一位大佬認(rèn)為是重復(fù)問題，并且關(guān)閉了這個(gè)issue
但我點(diǎn)進(jìn)去仔細(xì)看了下，和我說的應(yīng)該沒有關(guān)系，他們討論的是單測超時(shí)不生效的問題，于是我狡辯了一下。
果然狡辯是有用的，另一位大佬同意我的觀點(diǎn)，于是我給他點(diǎn)了個(gè)贊，但他也指出我的代碼存在問題。
下面進(jìn)入今天的正題，為了便于講解，我先把有問題的代碼段摘出來：
重慶分公司
重慶分公司
func (b *B) launch() {
...
// n（int64）可能會(huì)溢出
n = goalns * prevIters / prevns
...
}
既然知道n會(huì)溢出，還不簡單？加個(gè)判斷就完了。
這位大佬說我的代碼在防止int64溢出時(shí)不夠安全，難道溢出不是這樣判斷嗎？
不過還好，大佬給了一點(diǎn)點(diǎn)指導(dǎo)
同時(shí)也發(fā)來一段演示代碼
果然 「show me the code」 最好使，簡單點(diǎn)來說就是正數(shù)溢出成了負(fù)數(shù)，再溢出就又是正數(shù)，只要溢出足夠多，結(jié)果可正可負(fù)。
大佬還指出了另一個(gè)問題，兄弟，你寫的代碼得有有測試?。?/p>
雖然我給開源項(xiàng)目提交代碼不多，但也知道這點(diǎn)，為什么這次沒寫呢？主要是我覺得單測不太好寫，既然大佬提出來，硬著頭皮也得寫了。
第二次提交，改掉了之前判斷int64溢出的方法，用逆運(yùn)算還原回去和原值做對(duì)比來看是否溢出，這個(gè)方法上次用到還是在大學(xué)的C語言課程中
還附加了一個(gè)單元測試
這個(gè)單元測試稍微解釋下：
設(shè)置了150s的單測時(shí)間，每次試探單測時(shí)，次數(shù)都加1，如果試探次數(shù)超過6次，就說明有問題，終止單測。
這段代碼在上述溢出判斷加之前執(zhí)行，一定是失敗的，溢出判斷加了之后，則可正常執(zhí)行。
接下來就是等待回復(fù)，等了很久很久，Go的研發(fā)周期是以半年記，等得我都差點(diǎn)忘了這件事了，直到一天郵件提醒我。
前方高能，來看看另一位大佬是如何review我的代碼的。
首先，commit message不規(guī)范，我的commit message是這樣的，我是在github上提交的，被機(jī)器人搬運(yùn)過去。
給出的意見是
原來Go的commit message是有一個(gè)文檔專門介紹的，之前沒注意到，點(diǎn)進(jìn)去看了下
翻譯下就是commit message的第一行應(yīng)該是簡短的摘要，并且要指出影響了哪些包，第一行后得有一個(gè)空行。
commit message的主要內(nèi)容應(yīng)該詳細(xì)說明變更的上下文，并解釋其作用，語句完整、標(biāo)點(diǎn)正確，不要使用HTML、Markdown等標(biāo)記語言。相關(guān)的信息，如基準(zhǔn)測試數(shù)據(jù)等也需要寫進(jìn)來。
最后需要有關(guān)聯(lián)的issue，如果是修復(fù)某問題，需要用Fixes #來關(guān)聯(lián)號(hào)問題，如果只是解決部分問題，使用Updates #，如果修復(fù)的是golang.org/x/庫，使用Fixes golang/go#159。
一個(gè)好的例子如下：
math: improve Sin, Cos and Tan precision for very large arguments
The existing implementation has poor numerical properties for
large arguments, so use the McGillicutty algorithm to improve
accuracy above 1e10.The algorithm is described at https://wikipedia.org/wiki/McGillicutty_Algorithm
Fixes #159
看來我得好好改下commit message。
單測提了不少問題，首先是這個(gè)
我把Benchmark的單測包名改了，改這個(gè)是為了能調(diào)用包內(nèi)未導(dǎo)出的方法，確實(shí)不太好，但當(dāng)時(shí)沒想到別的方案。
接著是不應(yīng)該直接調(diào)用未暴露的cleanups和內(nèi)部的一些變量，和上面呼應(yīng)。
可以用flag.Lookup來set flag，這點(diǎn)沒用過，所以不知道。
或者可以考慮使用集成測試來代替單元測試，Go的集成測試在cmd/go/testdata/script，這個(gè)之前也沒接觸過，所以也不知道，這個(gè)集成測試具體怎么用可以看cmd/go/testdata/script/README
這點(diǎn)可以看出我真是個(gè)Go新手，需要多看多學(xué)，測試不光只有單測，Go還支持集成測試。
再接著看
這里模擬150s的單測，大佬就提問了，這個(gè)單測真的會(huì)跑150s嗎？如果是的話，那也太長了！
如果不是，也沒給我解釋清楚啊~
還有這個(gè)
你咋知道執(zhí)行次數(shù)一定小于6呢？Go可沒保證這個(gè)。
對(duì)于這兩點(diǎn)的疑問，核心問題在于沒寫注釋，別人不知道你的想法呀，如果開源的代碼里面充斥著這種看不懂的玩意，那不是要命。
首先對(duì)于第一個(gè)，模擬150s，實(shí)際上不會(huì)真的跑那么久，因?yàn)楹竺嬗性囂酱螖?shù)的限制，如果超過6次，就終止了，這個(gè)6次是怎么得到的呢？答案其實(shí)在《我好像發(fā)現(xiàn)了一個(gè)Go的Bug》中。
Benchmark在一個(gè)方法上跑的最多的次數(shù)是1e9次，也就是次，如果待測試方法執(zhí)行時(shí)間非常短，且在Benchmark時(shí)間比較長的情況下，計(jì)算需要執(zhí)行多少次一定會(huì)溢出，所以試探的執(zhí)行次數(shù)會(huì)是這個(gè)增長序列：
100、、、、、......
實(shí)際可能>4就完事了，可能是我之前測試的有問題，emm...
別判斷n是否溢出，如果判斷上一層，即goalns是否大于等于 int64最大值 * prevIters是否更合理呢？
n = goalns * prevIters / prevns，goalns 是設(shè)置的執(zhí)行時(shí)間（單位納秒）
看來是我格局小了，別急，還有
怎么知道100 * last是不是也溢出了呢？所以我們是不是全程的計(jì)算都用float64更合理呢？
測試了下，float64范圍大的離譜，感興趣可以試試，就不貼數(shù)據(jù)了，太長！
雖然這次提交比較失敗，但還是有點(diǎn)收獲，等我忙完這陣，抽空出來再改改，說不定就被Merge了，大家祝我好運(yùn)吧，今天的分享到這，我們下期再見！對(duì)了，文中的issue參考
搜索關(guān)注微信公眾號(hào)"捉蟲大師"，后端技術(shù)分享，架構(gòu)設(shè)計(jì)、性能優(yōu)化、源碼閱讀、問題排查、踩坑實(shí)踐。
