python怎麼繞開問題

1. 怎麼提高編程能力邏輯思維能力

什麼是編程思維？

思考問題的方式，方向，解決問題的方法，也就是說應該從哪裡入手，從哪裡著手去解決問題。

每個人都是從零基礎開始接觸編程的，很多技術大牛總結了很多經驗、解決問題的方式。而現在作為一個編程初學者，我們不需要重新造輪子。我們只需要跟隨前輩們腳步，避免重復去走他們已經走過的彎路，也可以說我們現在做的一切都是站在巨人的肩膀來進行的。學習前輩們的經驗和解決問題的方式，然後結合自身來解決自己的問題，最終融會貫通為自己所用。

編程思維是培養出來的

建議大家，解決問題的時候，首先要把問題分解。大化小，很多小問題已經有了非常成熟的解決方案，搜索引擎可以解決大部分問題，我們直接拿來用就可以了，並且記住這種解決問題的方案。而剩下解決不了的小問題，我們在進行針對性解決，每一個小問題解決後，一整塊大問題就隨之解決。

編程思維的訓練就是要學習成熟的解決問題的方法：比如if

語句用來做分支判斷，循環用來解決反復運算的問題。窮舉法、遞推、遞歸、排序、回溯等等（如果需要當專業程序員，需要學習數據結構和演算法，設計模式等等，需要學的東西很多很多。但首先要解決的一個問題是自己能寫代碼解決一般問題。）

訓練函數抽象，類抽象解決問題。如對有序數組，查找特定數值，沒有經過訓練，初學者，直接用循環遍歷。如果經過二分法演算法的訓練，下次碰到這樣的問題，就用二分法求解。

做習題，要像開發項目的流程一樣

（需求－>需求分析->設計->編碼->測試->交付等）

拿到一個習題，還沒有進行分析，就馬上敲代碼，這個學習方式，是不好的學習方式。

首先分析題目

再設計，用哪種數據類型（數據結構）來組織或保存數據，用何種演算法來計算效率最高，用面向過程，還是面向對象的編程範式，還是用函數式編程等等。設計後，再編寫代碼，最後寫測試。

如果大家對於學習編程有任何疑問，可以隨時咨詢我，這是我的V：Zhanlaoshi71 從事IT行業16年，精通八種語言，多跟專業的人交流學習。

如何才能逐漸養成良好的編程思維思路

只有先經過訓練常見的演算法，分解問題，會做需求分析，慢慢訓練，才會養成自己的思路。沒有人一出生會編程，只有經過訓練，才會學會編程。很多牛逼程序員用vim，敲的啪啪響，一會兒一屏幕代碼，為啥那麼熟練使用vim，習慣成自然。當你訓練多了以後，學會一定的套路（解決問題的方法），養成獨立思考的習慣，假以時日，自然就有思路了。

養成獨立思考的習慣，養成切分問題，養成大問題化解小問題，養成套用學過的演算法，才會有思路。簡單的判斷、循環都不會寫，就想玩django，何來的思路？

萬丈高樓從地起，希望大家腳踏實地實地的從基礎訓練起，先達到獨立寫代碼解決一般的問題，再談項目。見過盲目上號稱牛逼項目的培訓班出來的程序員，

沒有學會獨立寫代碼解決一般的問題的能力，開發項目時如狗咬刺蝟無從下手。

2. 說說這篇我為什麼從python轉向go

恩看了這篇我為什麼從python轉向go，
看來作者也是 KSO 輕辦公/企業快盤團隊的。作為快盤從無到有時期的工程師之一（總是被瀟灑哥說他們改我留下的 bug ），又恰好是
Python/Go 雙修（大霧其實我是 Rust 黨），其實一開始我是拒絕的，ang ang ang，那就隨手寫一點把。

一段段來吧，首先作者說 Python 是動態語言

python是一門動態語言，不是強類型系統。對於一個變數，我們有時候壓根不知道它是什麼類型，然後就可能出現int + string這樣的運行時錯誤。

在python裡面，可以允許同名函數的出現，後一個函數會覆蓋前一個函數，有一次我們系統一個很嚴重的錯誤就是因為這個導致的。

事實上，如果是靜態檢查，pylint 和 pyflakes 是可以做這件事的，雖然不能和 go
那種靜態編譯型語言比，但也侍枯足夠了。如果沒記錯的話，阿通當年是要求全組都在提交前做靜態檢查的。我認為這種問題更多的應該是人員素質上來避免，畢竟蔥頭
也說過，代碼自己寫的就要多回頭看看，看能不能重構，能不能做更好。不是說偷懶不行，但是從中得出 Python
動態特性太靈活，Python：怪我咯？

另外，函數作為第一對象，在 Python 中是 feature，Go 要寫個 mock，簡直虐得不要不要的。

其實這個一直是很多人吐槽python的地方，不過想想，python最開始是為了解決啥問題而被開發出來的？我們硬是要將他用到高性能伺服器開發上面，其實也是有點難為它。

如果沒記錯，無論是輕辦公還是快盤，是重 IO 不重 CPU，最大耗時是數據塊加密老尺洞那塊，我在的時候是 java 寫的。另外高性能伺服器選 Go 也是虐得不要不要的，各種小心翼翼避免 GC。大多數極端情況下，pypy 的性能足矣勝任了，我認為這不算充分條件。

python的GIL導致導致無法真正的多線程，大家可能會說我用多進程不就完了。但如果一些計算需要涉及到多進程交互，進程之間的通訊開銷也是不得不考慮的。

其實，Python 有宏可以繞開這個 GIL，但是呢架構設計得好其實可以避免的，到非同步那塊我會說。

無狀態的分布式處理使用多進程很方便，譬如處理http請求，我們就是在nginx後面掛載了200多個django server來處理http的,但這么多個進程自然導致整體機器負載偏高。

但即使我們使用了多個django進程來處理http請求，對於一些超大量請求，python仍然處理不過來。所以我們使用openresty，將高頻次的http請求使用lua來實現。可這樣又導致使用兩種開發語言，而且一些邏輯還得寫兩份不同的代碼。

如果推測沒錯，你們現在還在用五年前寫的 Gateway？那個基於 django route
的流量分發層？四年前我離開的時候已經小范圍的使用 Flask+Gevent Demo 測試過了，無論是性能還是負載都比同步模型的 django
有優勢。如果還是 django
這套的話，我只能說比較遺憾，畢竟當年金山新員工大賽頭牌就是我和幾個小夥伴寫的實時同步在線文檔編輯系統，用的就是這套技術。

因此這是個工程問題，並非語言問題。 Python 提供給了你了這么多工具，硬要選一個傳統的，Old fashion 的，Python：怪我咯？

django的網路是同步阻塞的，也就是說，如果我們需要訪問外部的一個服務，在等待結果返回這段時間，django不能處理任何其他的邏輯（當然，多線程的除外）。如果訪問外部服務需要很長時間，那就意味著我們的整個服務幾乎在很長一段時間完全不可用。

為了解決這個問題，我們只能不斷的多開django進程，同時需要保證所有服務都能快速的處理響應，但想想這其實是一件很不靠譜的事情。

同步模型並非不行，因為 overhead 足夠低，很多業務場景下用同步模型反而會取得更好的效果，比如豆瓣。同步模型最大的問題是對於 IO 密集型業務等待時間足夠長，這時候需要的不是換語言 ，而是提醒你是不是架構要改一下了。

雖然tornado是困租非同步的，但是python的mysql庫都不支持非同步，這也就意味著如果我們在tornado裡面訪問資料庫，我們仍然可能面臨因為資料庫問題造成的整個服務不可用。

tornado 是有這個問題，但是 gevent 已經解決了。我在 node.js 的某問題下曾經回答過，對於 node
而言，能選擇的非同步模型只有一個，而 Python 就是太多選擇了。另外 pypy+tornado+redis
可以隨意虐各種長連接的場景，比如我給我廠寫過的一個 push service。

其實非同步模型最大的問題在於代碼邏輯的割裂，因為是事件觸發的，所以我們都是通過callback進行相關處理，於是代碼裡面就經常出現干一件事情，傳一個callback，然後callback裡面又傳callback的情況，這樣的結果就是整個代碼邏輯非常混亂。

這個還真不是，如果說沒有 ES6 的 JavaScript，可能真有 Callback hell，但這是 Python 啊！Python
早就實現了左值綁定唉，yield 那姿勢比某些天天吹的語言不知道高到哪裡去了，當然我說的是完整版的 Python3 yield。即便是不完整的
Python 2 yield 用於非同步表達式求值也是完全足夠的，tornado 的 gen.coroutine 啊。

同步形態寫非同步，在 Python 實力強的公司裡面早普及了，這是個工程問題，並非語言問題。當然把這種事怪在 Python 身上，Python：怪我咯？

python沒有原生的協程支持，雖然可以通過gevent，greenlet這種的上patch方式來支持協程，但畢竟更改了python源碼。另外，python的yield也可以進行簡單的協程模擬，但畢竟不能跨堆棧，局限性很大，不知道3.x的版本有沒有改進。

無論是 Gevent 還是 Greenlet 均沒修改 Python 源碼，事實上這貨已經成為了 Py2 coroutine 的標准，加上豆瓣開源出來的greenify，基本上所有的庫都可以平滑的非同步化，包括 MySQL 等 C 一級的 lib。自從用上這套技術後，豆瓣的 Python dev 各種爽得不要不要的。

當我第一次使用python開發項目，我是沒成功安裝上項目需要的包的，光安裝成功mysql庫就弄了很久。後來，是一位同事將他整個python目錄打包給我用，我才能正常的將項目跑起來。話說，現在有了docker，是多麼讓人幸福的一件事情。

而部署python服務的時候，我們需要在伺服器上面安裝一堆的包，光是這一點就讓人很麻煩，雖然可以通過puppet，salt這些自動化工具解決部署問題，但相比而言，靜態編譯語言只用扔一個二進制文件，可就方便太多了。

恰好我又是在開發基於 docker 的平台， docker 還真不是用來做部署這事的。首先， Python 是有 virtualenv
這個工具的，事實上對比包管理和包隔離，Python 比 Go 高得不知道哪裡去了。Python 跟 Git 談笑風生的時候， Go 的 dev
們還得考慮我怎樣才能使得 import 的包穩定在一個版本上（當然現在有很多第三方方案）。Virtualenv + Pip 完全可以實現
Python 部署自動化，所以這個問題我認為是，工具鏈選取問題。畢竟是個十幾年的老妖怪了，Python
啥情況沒見過啊，各種打包工具任君選擇，強行說 Python 部署不方便，Python：怪我咯？

python非常靈活簡單，寫c幾十行代碼才能搞定的功能，python一行代碼沒准就能解決。但是太簡單，反而導致很多
同學無法對代碼進行深層次的思考，對整個架構進行細致的考量。來了一個需求，啪啪啪，鍵盤敲完開速實現，結果就是代碼越來越混亂，最終導致了整個項目代碼
失控。

曾經知乎有個帖子問 Python 會不會降低程序員編程能力，
我只能說這真的很人有關。你不去思考深層次的東西怪語言不行是沒道理的，那好，Go 裡面 goroutine 是怎麼實現的，一個帶 socket 的
goroutine
最小能做到多少內存，思考過？任何語言都有自己的優勢和劣勢，都需要執行者自己去判斷，一味的覺得簡單就不會深入思考這是有問題的。另外，代碼混亂我認為
還是工程上的控制力不夠，豆瓣有超過10W行的 Python 實現，雖然不說很完美，大體上做到了不會混亂這么個目標。

還有，C 寫幾十行搞定的 Python 一行解決這絕對是重大 feature，生產力啊，人員配置啊，招人培養的成本啊，從工程上來說，Python 在這一塊完全是加分項，不是每個項目都要求極致的並發，極致的效率，做工程很多時候都是要取捨的。

雖然java和php都是最好的編程語言（大家都這么爭的），但我更傾向一門更簡單的語言。而openresty，雖然性
能強悍，但lua仍然是動態語言，也會碰到前面說的動態語言一些問題。最後，前金山許式偉用的go，前快盤架構師蔥頭也用的go，所以我們很自然地選擇了
go。

Openresty 用 lua 如果按照動態語言的角度去看，還真算不上，頂多是個簡單點的 C。許式偉走的時候大多數都是
CPP，蔥頭目前我還不知道他創業用的是什麼寫的，不過他肯定沒語言傾向。當年無論是 leo 還是 ufa，一個用 Python 一個用
Java， 他都是從工程實際來選擇使用什麼樣的語言。

error，好吧，如果有語言潔癖的同學可能真的受不了go的語法，尤其是約定的最後一個返回值是error。

這其實是 Go style，無論是 go fmt 還是 error style，Go 其實是想抹平不同工程師之間的風格問題。不再為了一個縮進和大括弧位置什麼的浪費時間。這種方法並不是不好，只是我個人覺得沒 rust 那種返回值處理友善。

GC，java的GC發展20年了，go才這么點時間，gc鐵定不完善。所以我們仍然不能隨心所欲的寫代碼，不然在大請求量下面gc可能會卡頓整個服務。所以有時候，該用對象池，內存池的一定要用，雖然代碼丑了點，但好歹性能上去了。

1.4 開始 go 就是 100% 精確 GC 了，另外說到卡頓啊，完全和你怎麼用對象有關，能內聯絕不傳引用大部分場景是完全足夠的，這樣 gc 的影響程度會最低。實在想用池……只能說為啥不選 Java。

天生的並行支持，因為goroutine以及channel，用go寫分布式應用，寫並發程序異常的容易。沒有了蛋疼的callback導致的代碼邏輯割裂，代碼邏輯都是順序的。

這是有代價的，goroutine 的內存消耗計算（當然1.3還是1.4開始得到了很大的改善，內存最小值限制已經沒了），channel
跨線程帶來的性能損耗（跨線程鎖），還有對 goroutine 的控制力幾乎為 0
等。總之這種嘛，算不上是殺手級特性，大家都有，是方便了一點，但也有自己的弊端。比如我們用 go 吧，經常就比較蛋疼 spawn 出去的
goroutine 怎麼優美的 shutdown，反而有時候把事情做復雜化了。

性能，go的性能可能趕不上c，c++以及openresty，但真的也挺強悍的。在我們的項目中，現在單機就部署了一個go的進程，就完全能夠勝任以前200個python進程乾的事情，而且CPU和MEM佔用更低。

我不嚴謹的實測大概 gevent+py2 能達到同樣邏輯 go 實現的 30%~40%，pypy+tornado 能達到
80%~90%，混合了一些計算和連接處理什麼的。主要還是看業務場景吧，純粹的 CPU bound 當然是 go 好，純粹的 IO bound
你就是用 C 也沒用啊。

運維部署，直接編譯成二進制，扔到伺服器上面就成，比python需要安裝一堆的環境那是簡單的太多了。當然，如果有cgo，我們也需要將對應的動態庫給扔過去。

我們現在根據 glibc 所處的 host 版本不同有2套編譯環境，看上去是部署簡單了，編譯起來坑死你。另外雖然說 disk 便宜，這幾行代碼就幾M了，集群同步部署耗時在某些情況下還真會出簍子。

開發效率，雖然go是靜態語言，但我個人感覺開發效率真的挺高，直覺上面跟python不相上下。對於我個人來說，最好的
例子就是我用go快速開發了非常多的開源組件，譬如ledisdb，go-mysql等，而這些最開始的版本都是在很短的時間裡面完成的。對於我們項目來
說，我們也是用go在一個月就重構完成了第一個版本，並發布。

3. 網路爬蟲 python 畢業論文呢

做爬蟲,特別是python寫說容易挺容易,說難也挺難的,
舉個栗子 簡單的:將http://paste.ubuntu.com上面的所有代碼爬下來
寫個for循環,調用urllib2的幾個函數就成了,基本10行到20行以內的代碼
難度0

情景:
1.網站伺服器很卡,有些頁面打不開,urlopen直接就無限卡死在了某些頁面上(2.6以後urlopen有了timeout)
2.爬下來的網站出現亂碼,你得分析網頁的編碼
3.網頁用了gzip壓縮,你是要在header裡面約定好默認不壓縮還是頁面下載完畢後自己解壓
4.你的爬蟲太快了,被伺服器要求停下來喝口茶
5.伺服器不喜歡被爬蟲爬,會對對header頭部瀏覽器信息進行分析,如何偽造
6.爬蟲整體的設計,用bfs爬還是dfs爬
7.如何用有效的數據結構儲存url使得爬過的頁面不被重復爬到
8.比如1024之類的網站(逃，你得登錄後才能爬到它的內容,如何獲取cookies

以上問題都是寫爬蟲很常見的,由於python強大的庫,略微加了一些代碼而已
難度1

情景:
1.還是cookies問題,網站肯定會有一個地方是log out，爬蟲爬的過程中怎樣避免爬到各種Log out導致session失效
2.如果有驗證碼才能爬到的地方,如何繞開或者識別驗證碼
3.嫌速度太慢,開50個線程一起爬網站數據

難度2

情景:
1.對於復雜的頁面,如何有效的提取它的鏈接,需要對正則表達式非常熟練
2.有些標簽是用Js動態生成的，js本身可以是加密的,甚至奇葩一點是jsfuck,如何爬到這些

難度3

總之爬蟲最重要的還是模擬瀏覽器的行為,具體程序有多復雜,由你想實現的功能和被爬的網站本身所決定
爬蟲寫得不多,暫時能想到的就這么多，歡迎補充

4. Python2.7 中文字元編碼，使用Unicode時，選擇什麼編碼格式

關於編碼和亂碼的問題，我簡單講一下。

通常問這類問題的人是混淆了若干個不同的概念，並且他們自己也沒有意識到自己混淆了這些概念的。

• 終端顯示字元的編碼（windows下終端是cmd，linux下是各種terminal，遠程登錄是putty或者xshell）

• shell環境的編碼。比如中文版windows用的是gbk（向下兼容gb2312），大多數linux發行版使用的是utf-8（LANG=zh_CN.UTF-8）。

• 文本文件的編碼。這個通常取決於你的編輯器，而且有的編輯器支持多種編碼的話，你可以在文本開頭位置指定編輯器使用特定編碼。比如# -*- coding: utf8 -*-，vim看到這行會默認將這個腳本認定為utf-8兼容編碼格式。

• 應用程序的內部編碼。一個字元串，作為數據只是一個位元組數組，但是作為字元的數組，就有一個解析方式。java和python的內部字元編碼是utf-16，python和java都支持用不同的編碼來對位元組數組進行decode來得到字元數組。




拿題主的問題來解釋一下。

我在ubuntu kylin中文環境下默認terminal中做了同樣的實驗，但是結果和題主恰好相反：



這個實際上是gbk(兼容gb2312)的字元「漢字」的真實位元組數組。這個實際上是gbk(兼容gb2312)的字元「漢字」的真實位元組數組。
所以對這坨數據做unicode("漢字","utf8")會失敗——因為不管你怎麼想，雖然看上去是一樣，但是實際上不是同一坨東西啊！

• 題主現在弄了一個文件，在開始加上了
  # -*- coding: utf8 -*-
  這下編輯器看到了，知道這文件是utf-8的了。所以編輯器對讀入的一坨坨位元組用utf-8來解碼，對於輸出到磁碟的漢字也用utf-8來編碼。所以你在文件裡面看到的看上去像「漢字」的東西，就和第一種情況下想同了，當然代碼就跑得通。
  順便說一下，如果編輯器無視行首這行編碼聲明，或者編輯器無法支持utf-8格式，那麼你弄好的文件在那個編輯器下就會顯示亂碼，多麼簡單的道理啊。



• 所以，要能夠正常的顯示中文（或者其他什麼亂七八糟奇葩的多位元組文字），以下條件缺一不可：



• 終端和環境的編碼一致（本機通常是一致的，不一致常常出現在遠程登錄）；如果不一致就需要有編輯器或者文本閱讀器做一個兼容兩者的轉換。

• 編輯器能夠認識文本編碼

• 系統擁有能顯示這種字元的字體。




這也就是我為什麼一直反對在程序文本中使用除ascii之外的所有編碼字元的原因。環境太復雜了，繞開問題遠比解決問題輕松。