別讓這種思考方式耽誤了你的前程-有解無憂

昨天發布了一條微頭條，內容是這樣的：

一朋友是做軟體開發，最近收到一家外包公司的offer，到廣州某知名銀行駐點辦公，上班時間朝九晚六，

HR說，辦公電腦不能上外網，開發程序如果遇到要查資料只能通過手機查，

作業發郵件必須得用英文，

專案溝通用粵語或是英語溝通，

朋友上網了解了下，有人說銀行外包專案很少有完整的檔案，要是接手別人的專案，排查問題會很費勁，

不知大家有沒有遇到類似的，有什么好建議，

今早起來，評論區挺熱鬧的，其中有兩個地方特別有意思，分享給大家：

不少讀者一眼就就猜測出是哪家銀行
吐槽代碼質量不好，

對于第一點，真的很佩服讀者，沒想到在資訊量這么少的條件下，竟然能第一時間就能推測出是哪家銀行，要知道廣州這么多家銀行，我自己都記不起是哪家銀行，有點尷尬了，印象中只記得是作業郵件必須得用英文，作業交流最好是用英文或是粵語，其他就沒有了，

對于第二點我覺得更有意思，有個別讀者吐槽配圖代碼質量不好，看了相關評論我有點哭笑不得，這里我把個人想法和大家分享下，首先宣告下，這個代碼不是出自于本人，

讀者吐槽點，我大致歸納下：

if else 太多
代碼邏輯不清晰
代碼質量堪憂，重復太多，可讀性差

說if 多的，可能是平時受業務邏輯if else 影響，一看到有多個if 就立馬否認了，有點太敏感了吧，這是資料結構，不是業務邏輯，

有幾個if 判斷不是一件很正常的事情嗎？

說代碼邏輯不清晰，估計他自己看都沒有看清楚，

說重復太多的了，估計這段代碼有幾個變數他自己都不知道，更別說這段代碼具體用處是做什么了，

最后我想說，沒經過自己獨立思考的事情，別輕易下結論，避免受從眾心理的影響，別人說什么，自己沒有思考，就急著跟風了，

凡事不要看表面，要是能更進一步深度思考就更好了，并不是if一多就需要吐槽，也要具體是在什么場景下，保持自己的獨立思考能力，對你的前程發展或多或少都會有所幫助，

關于配圖的原始碼出處是HashMap原始碼

 1    /**
 2     * Recursive invariant check
 3     */
 4    static <K,V> boolean checkInvariants(TreeNode<K,V> t) {
 5        TreeNode<K,V> tp = t.parent, tl = t.left, tr = t.right,
 6            tb = t.prev, tn = (TreeNode<K,V>)t.next;
 7        if (tb != null && tb.next != t)
 8            return false;
 9        if (tn != null && tn.prev != t)
10            return false;
11        if (tp != null && t != tp.left && t != tp.right)
12            return false;
13        if (tl != null && (tl.parent != t || tl.hash > t.hash))
14            return false;
15        if (tr != null && (tr.parent != t || tr.hash < t.hash))
16            return false;
17        if (t.red && tl != null && tl.red && tr != null && tr.red)
18            return false;
19        if (tl != null && !checkInvariants(tl))
20            return false;
21        if (tr != null && !checkInvariants(tr))
22            return false;
23        return true;
24    }

這代碼水平，能開多少工資？有讀者表示：寫這個代碼的至少可以千萬年薪，

值不值年薪千萬我不知道，但我知道，這原始碼邏輯清晰，鏈表有了，遞回也有了，沒什么可挑剔的，

如果你對評論區的內容感興趣，點擊下面原文閱讀，

-END-

往期推薦

面試了18家公司，終于找到作業，我把所有經驗都分享給你

一個有故事的程式員

微信公眾號：愛開發

微信號：hsp-88ios