程式猿與架構獅有撒子思路區別？

在這裡我給大家剖析一下啦~

發現問題

▌有一天，程式猿寫了一條sql，發現執行挺慢的。想想也不是慢點太離譜吧，先提交上線吧。

▌有一天，架構獅寫了一條sql，發現執行挺慢的。想想，是不是索引沒加？explain一下看看。where欄位加上索引。還是不滿意，上google找方案。並且rtx找到DBA，跟他討論起這條sql怎麼優化，需不需要做表裡新增索引。

對待問題

▌ 有一天，DBA找到程式猿，告訴他發現了一條慢查詢。程式猿問：怎麼優化？DBA噼噼啪啪說了出來。程式猿屁顛屁顛把程式碼一改，編譯，上線。

▌ 有一天，DBA找到架構獅，告訴他發現了一條慢查詢。架構獅問：還有沒有發現其它慢查詢？DBA說暫時發現一條。架構獅說：請你幫我重點監控一週，把這個系統上的所有慢查詢和優化方案都一一列舉出來，然後我們建立一個優化專項，統一把整個系統慢查詢優化掉。之前，我們把這次專項作為案例，形成一門sql優化課程。無論新老員工，都應該接受這門培訓。

處理問題

▌ 有一天，程式猿接手一個老系統。發現，這個系統執行速度非常慢！程式猿經常聽到最近火熱的不行的大資料平臺、分散式計算，一拍腦袋，就用大資料框架解決！老闆問他，解決這個問題要多久？程式猿說：我要先了解大資料平臺、分散式框架，再搭建一套，怎麼都得一個月之後了。

▌有一天，架構師接手一個老系統。發現，這個系統執行速度非常慢！架構獅找來這個系統的日誌，仔細分析，發現系統處理的資料越來越多。看看系統所在的伺服器，cpu、記憶體、磁碟io樣樣未滿。看看程式碼，居然還是單執行緒單程序單連線。再看看日誌統計資料，發現增量資料的條數是非常多，但是資料大小並不算大。架構獅主動找到老闆，胸有成足的說：我會分幾步解決這個問題。第一步是改為併發模型，多程序多連線等等，充分用滿cpu；第二步把增量資料放記憶體上處理，充分用滿記憶體。如果資料量繼續增大，可以考慮再買一塊記憶體加上。第三步是逐步規劃研究實踐分散式，應對將來業務發展帶來的cpu、記憶體、硬碟等瓶頸。

寫在最後

▌培養技術深度：程式猿需要對面臨的問題，做出深入研究，做到知其然並知其所以然。

▌培養技術廣度：程式猿除了需要理解計算機系統原理、網路原理等，更多跳出舒適區去學習新的技術。

▌培養系統思維：一個問題的出現，意味著同類的問題正在潛伏，找到根源並且解決掉。

▍培養體系思維：架構獅不是一個人，而且需要帶領一幫程式猿去攻城略地。建立高效的體系，把程式猿培養為新的領袖--架構獅