作為一個程序員，我們最經常的感覺就是每天的時間除了開發需求就是在查bug，每天都過得很累，但是一年過去，反而覺得自己沒有什么提升。最近有一個熱門的詞匯，叫做知識恐慌，特別是程序員，更加恐慌，這個世界發展得太快了，技術的迭代日新月異，很害怕若干年后，就跟不上時代的腳步，盡管35歲之后可以轉行送外賣，但萬一到時候不需要外賣老哥了呢。

[[325285]]

在過去的一年，手里的業務經歷了快速迭代，有一些業務甚至有數百倍的增長，很多業務都出現了不少問題，隨之而來的是各種投訴，每天除了開發開發各種需求，還要處理各種bug。越干越累，惡性循環。

和大部分公司相似，我們公司是需要開發及時給客戶反饋的，所以QA會一直催促你幫用戶看投訴單，畢竟這是他們的KPI，但是查投訴的大多數情況對開發其實是沒有成長的，都是機械性的查日志，修數據。那么，如何在這些枯燥無味地工作中得到成長呢?一個很重要的事情，就是做總結。

投訴大概分為幾類，首先是當然是產品邏輯或者是用戶理解的問題，有些人可能會說這應該是產品經理的問題，開發只是按照產品的需要去設計而已。對于大部分人來說，他們的職業規劃當然不是做純技術人員，更多的人，是想做管理，甚至想出去創業的。那么更要珍惜這些寶貴的機會，一款產品如何設計得更加合理，是你必須考慮的問題。當然，并不是優秀的產品就投訴少，就像每天都有1億人想交張小龍做產品一樣。

第二類的投訴是代碼的bug。有些人很忌諱bug，覺得這個就是自己能力不足，其實是程序就會有bug。我們應該從bug中去進一步反思，是設計的問題，還是開發流程上不規范造成的。我們還需要對bug舉一反三，去思考同類型的業務是否也有同樣的問題，舉一個例子，最近我們有一個業務，需要從數據庫里面讀取大量的臨時數據，使用了C++的vector去存儲，我們知道，這種不定長的數據結構在申請內存的時候，是會翻倍申請的，在一些極端數據下就會內存不足。我們要反思我們所有的代碼里面是否有類似的情況，不僅是vector，類似stack，hashmap都有這樣的問題，我們要一起解決掉。

第三類的投訴往往是性能問題，如果你的程序遇到了性能問題，那么恭喜你。說明你的系統的用戶量到了一定的規模，系統遇到瓶頸，優化他，你會對你做的事情有進一步的提升。我們在日常使用APP的時候，我們經常會發現這么一個事情，很多APP的交互上面都不展示數據有多少頁，或者總的數據有多少條。這其實有時候是一種妥協，因為大部分的數據庫，對處理select count語句都不太友好，性能比較差。最近我們就遇到過這么一個例子，在一個超大的表里面，select語句可以快速的返回，但是select count卻不行。最終排查下來是因為索引沒有全覆蓋的問題，最后還是要回源到表中掃描數據，造成效率過低。

在出現了索引造成的性能問題之后，除了優化當前遇到的系統瓶頸，可以順路地把索引相關地知識再進一步地進行加深跟鞏固，可能以前你對索引的理解還不夠透徹，再出過一兩次問題之后，再結合書本上的知識，一定會有更深的體會。

我們常說，一個好的程序員不是要解決一個問題，而是解決一類問題，那么一類問題如何定義，首先要找到這類問題的業務特點。好的程序員要多總結，為什么先前的代碼設計沒有考慮到這些問題?核心的原因是什么，都要考慮清楚。只有做到這一點，才可以進一步的提升自我，成為某一個領域的專家。

遇到問題其實不可怕，關鍵是要想辦法從枯燥重復的生活中解脫出來，這才是程序員成長的優秀道路。