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è)夢(mèng)想脫穎而出為使命，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)去，以后也可以吹牛說(shuō)自己是個(gè)Go的Contributor，但事情并不順利，今天就來(lái)分享一下這次失敗的代碼提交。

第一次提交

在我意識(shí)到Bug時(shí)，就迫不及待想去修復(fù)，于是有了這一次提交。

在說(shuō)代碼前，先說(shuō)點(diǎn)關(guān)于Go倉(cāng)庫(kù)的問(wèn)題，Go并沒(méi)有直接托管在github，而是自建的Gerrit Code Review，github上只是個(gè)鏡像倉(cāng)庫(kù)，所有在github上提交的issue和代碼都會(huì)被一個(gè)機(jī)器人搬運(yùn)到Gerrit上。

而且Go對(duì)提交代碼的要求是必須關(guān)聯(lián)一個(gè)issue，于是我就提了一個(gè)，自問(wèn)自答了屬于是。

描述了一下遇到的問(wèn)題，但隔天被一位大佬認(rèn)為是重復(fù)問(wèn)題，并且關(guān)閉了這個(gè)issue

但我點(diǎn)進(jìn)去仔細(xì)看了下，和我說(shuō)的應(yīng)該沒(méi)有關(guān)系，他們討論的是單測(cè)超時(shí)不生效的問(wèn)題，于是我狡辯了一下。

果然狡辯是有用的，另一位大佬同意我的觀點(diǎn)，于是我給他點(diǎn)了個(gè)贊，但他也指出我的代碼存在問(wèn)題。

下面進(jìn)入今天的正題，為了便于講解，我先把有問(wèn)題的代碼段摘出來(lái)：

func (b *B) launch() {
   ...
    // n（int64）可能會(huì)溢出
   n = goalns * prevIters / prevns
   ...
}

既然知道n會(huì)溢出，還不簡(jiǎn)單？加個(gè)判斷就完了。

溢出考慮不全

這位大佬說(shuō)我的代碼在防止int64溢出時(shí)不夠安全，難道溢出不是這樣判斷嗎？

不過(guò)還好，大佬給了一點(diǎn)點(diǎn)指導(dǎo)

同時(shí)也發(fā)來(lái)一段演示代碼

果然 「show me the code」 最好使，簡(jiǎn)單點(diǎn)來(lái)說(shuō)就是正數(shù)溢出成了負(fù)數(shù)，再溢出就又是正數(shù)，只要溢出足夠多，結(jié)果可正可負(fù)。

得有測(cè)試

大佬還指出了另一個(gè)問(wèn)題，兄弟，你寫的代碼得有有測(cè)試啊！

雖然我給開(kāi)源項(xiàng)目提交代碼不多，但也知道這點(diǎn)，為什么這次沒(méi)寫呢？主要是我覺(jué)得單測(cè)不太好寫，既然大佬提出來(lái)，硬著頭皮也得寫了。

第二次提交

第二次提交，改掉了之前判斷int64溢出的方法，用逆運(yùn)算還原回去和原值做對(duì)比來(lái)看是否溢出，這個(gè)方法上次用到還是在大學(xué)的C語(yǔ)言課程中

還附加了一個(gè)單元測(cè)試

這個(gè)單元測(cè)試稍微解釋下：

設(shè)置了150s的單測(cè)時(shí)間，每次試探單測(cè)時(shí)，次數(shù)都加1，如果試探次數(shù)超過(guò)6次，就說(shuō)明有問(wèn)題，終止單測(cè)。

這段代碼在上述溢出判斷加之前執(zhí)行，一定是失敗的，溢出判斷加了之后，則可正常執(zhí)行。

接下來(lái)就是等待回復(fù)，等了很久很久，Go的研發(fā)周期是以半年記，等得我都差點(diǎn)忘了這件事了，直到一天郵件提醒我。

前方高能，來(lái)看看另一位大佬是如何review我的代碼的。

commit message不規(guī)范

首先，commit message不規(guī)范，我的commit message是這樣的，我是在github上提交的，被機(jī)器人搬運(yùn)過(guò)去。

給出的意見(jiàn)是

原來(lái)Go的commit message是有一個(gè)文檔專門介紹的，之前沒(méi)注意到，點(diǎn)進(jìn)去看了下

翻譯下就是commit message的第一行應(yīng)該是簡(jiǎn)短的摘要，并且要指出影響了哪些包，第一行后得有一個(gè)空行。

commit message的主要內(nèi)容應(yīng)該詳細(xì)說(shuō)明變更的上下文，并解釋其作用，語(yǔ)句完整、標(biāo)點(diǎn)正確，不要使用HTML、Markdown等標(biāo)記語(yǔ)言。相關(guān)的信息，如基準(zhǔn)測(cè)試數(shù)據(jù)等也需要寫進(jìn)來(lái)。

最后需要有關(guān)聯(lián)的issue，如果是修復(fù)某問(wèn)題，需要用Fixes #來(lái)關(guān)聯(lián)號(hào)問(wèn)題，如果只是解決部分問(wèn)題，使用Updates #，如果修復(fù)的是golang.org/x/庫(kù)，使用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

看來(lái)我得好好改下commit message。

可以考慮集成測(cè)試

單測(cè)提了不少問(wèn)題，首先是這個(gè)

我把Benchmark的單測(cè)包名改了，改這個(gè)是為了能調(diào)用包內(nèi)未導(dǎo)出的方法，確實(shí)不太好，但當(dāng)時(shí)沒(méi)想到別的方案。

接著是不應(yīng)該直接調(diào)用未暴露的cleanups和內(nèi)部的一些變量，和上面呼應(yīng)。

可以用flag.Lookup來(lái)set flag，這點(diǎn)沒(méi)用過(guò)，所以不知道。

或者可以考慮使用集成測(cè)試來(lái)代替單元測(cè)試，Go的集成測(cè)試在cmd/go/testdata/script，這個(gè)之前也沒(méi)接觸過(guò)，所以也不知道，這個(gè)集成測(cè)試具體怎么用可以看cmd/go/testdata/script/README

這點(diǎn)可以看出我真是個(gè)Go新手，需要多看多學(xué)，測(cè)試不光只有單測(cè)，Go還支持集成測(cè)試。

缺少注釋

再接著看

這里模擬150s的單測(cè)，大佬就提問(wèn)了，這個(gè)單測(cè)真的會(huì)跑150s嗎？如果是的話，那也太長(zhǎng)了！

如果不是，也沒(méi)給我解釋清楚啊~

還有這個(gè)

你咋知道執(zhí)行次數(shù)一定小于6呢？Go可沒(méi)保證這個(gè)。

對(duì)于這兩點(diǎn)的疑問(wèn)，核心問(wèn)題在于沒(méi)寫注釋，別人不知道你的想法呀，如果開(kāi)源的代碼里面充斥著這種看不懂的玩意，那不是要命。

首先對(duì)于第一個(gè)，模擬150s，實(shí)際上不會(huì)真的跑那么久，因?yàn)楹竺嬗性囂酱螖?shù)的限制，如果超過(guò)6次，就終止了，這個(gè)6次是怎么得到的呢？答案其實(shí)在《我好像發(fā)現(xiàn)了一個(gè)Go的Bug》中。

Benchmark在一個(gè)方法上跑的最多的次數(shù)是1e9次，也就是次，如果待測(cè)試方法執(zhí)行時(shí)間非常短，且在Benchmark時(shí)間比較長(zhǎng)的情況下，計(jì)算需要執(zhí)行多少次一定會(huì)溢出，所以試探的執(zhí)行次數(shù)會(huì)是這個(gè)增長(zhǎng)序列：

100、、、、、......

實(shí)際可能>4就完事了，可能是我之前測(cè)試的有問(wèn)題，emm...

溢出需要重新考慮

別判斷n是否溢出，如果判斷上一層，即goalns是否大于等于 int64最大值 * prevIters是否更合理呢？

n = goalns * prevIters / prevns，goalns 是設(shè)置的執(zhí)行時(shí)間（單位納秒）

看來(lái)是我格局小了，別急，還有

怎么知道100 * last是不是也溢出了呢？所以我們是不是全程的計(jì)算都用float64更合理呢？

測(cè)試了下，float64范圍大的離譜，感興趣可以試試，就不貼數(shù)據(jù)了，太長(zhǎng)！

最后說(shuō)一句

雖然這次提交比較失敗，但還是有點(diǎn)收獲，等我忙完這陣，抽空出來(lái)再改改，說(shuō)不定就被Merge了，大家祝我好運(yùn)吧，今天的分享到這，我們下期再見(jiàn)！對(duì)了，文中的issue參考

• https://github.com/golang/go/pull/

---

搜索關(guān)注微信公眾號(hào)"捉蟲(chóng)大師"，后端技術(shù)分享，架構(gòu)設(shè)計(jì)、性能優(yōu)化、源碼閱讀、問(wèn)題排查、踩坑實(shí)踐。

網(wǎng)頁(yè)題目：慘，給Go提的代碼被批麻了
文章路徑：http://chinadenli.net/article48/dsoisep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、、網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、電子商務(wù)、搜索引擎優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)