一個與運算引發的事故

今天發生了一起事故，追查下去，找到了一段陳年老程式碼。

程式碼邏輯很簡單:

<?php
$a = 1;
$b = 8;
if ($a & $b) {
    var_dump('same');
} else {
    var_dump('not same');
}

這個程式碼的作用是什麼呢？判斷a與b是否相等。

為什麼能判斷呢？或者說什麼條件下這個邏輯是生效的？

聰明的你可能有了答案，當a和b都是2^n的時候。

在位與運算的時候，只有完全一樣a&b才能大於零，否則，每一位必然會有一個0，最終結果為0，表示不相等。

這個算是比較巧的寫法（這麼寫的人少），另外理論上這個操作比直接判斷相等是要快一些的。

但是卻隱藏了兩個極大的問題

1. 數值增長會很快，迅速達到越界的範圍，畢竟指數增長啊
2. 如果這個邏輯一直是由同一個人維護還好，知道賦值必須為2^n，如果程式碼交接給別的組或者換了一個新人，極有可能不知道這點，賦值的時候沒有遵循指數規則，然後就悲劇了

墨菲定律說的是個概率問題，感覺世上的事情沒啥能逃脫統計，然後果然就悲劇了。對於系統來說，一個&值多少錢，可能一文不值，也可能是天價。

後來我想了想，在程式碼層面至少有兩個問題

1. 如果接手別人的程式碼，一定要看一遍，另外對裡面不符合常理的地方一定要跟進，這些地方往往是定律的藏身之所
2. 寫程式碼的時候，通俗易懂是最重要的，不要去炫技，也不要為了炫技而埋了坑。就對上面舉例的程式碼而言，即沒有充分利用每一個數字，而且很可能引發錯誤，另外其實也提升不了多少效能，優化優化邏輯、改改演算法，效能不會比這個提升的多？

最後說一句：

<?php
$a = 1;
$b = 8;
if ($a == $b) {
    var_dump('same');
} else {
    var_dump('not same');
}

這個寫法不香嗎？

最後

大家如果喜歡我的文章，可以關注我的公眾號（程式設計師麻辣燙）

我的個人部落格為：https://shidawuhen.github.io/

往期文章回顧：

技術

1. 秒殺系統
2. 分散式系統與一致性協議
3. 微服務之服務框架和註冊中心
4. Beego框架使用
5. 淺談微服務
6. TCP效能優化
7. 限流實現1
8. Redis實現分散式鎖
9. Golang原始碼BUG追查
10. 事務原子性、一致性、永續性的實現原理
11. CDN請求過程詳解
12. 常用快取技巧
13. 如何高效對接第三方支付
14. Gin框架簡潔版
15. InnoDB鎖與事務簡析
16. 演算法總結

讀書筆記

1. 敏捷革命
2. 如何鍛鍊自己的記憶力
3. 簡單的邏輯學-讀後感
4. 熱風-讀後感
5. 論語-讀後感
6. 孫子兵法-讀後感

思考

1. 專案流程管理
2. 對專案管理的一些看法
3. 對產品經理的一些思考
4. 關於程式設計師職業發展的思考
5. 關於程式碼review的思考
6. Markdown編輯器推薦-typora