在選擇進行Python培訓之前，很多同學都會比較糾結。一方面是因為Python培訓機構良莠不齊，另一方面Python培訓的脫產、學費又是一個比較高的代價。為了讓自己的學習達到最佳效果，很多同學都會選擇七天做好培訓準備，自己進行復習、預習等，這樣才能保證自己的每一分學費都不浪費。

人生苦短，很高興你選擇了Python，這是我比較喜歡的語言。如果你是想做Python web相關的話，可以看看這個指南Python web 入坑指南 - Python-web-guide 0.1 文檔,都是根據我的工作經(cai)驗(keng)總結的。主要涉及Python網站和爬蟲相關的開發，還有一些工程性的東西。入行不久，經驗有限，希望能給你指條路。下邊列舉了計算機基礎、開發工具、代碼規范、軟件工程相關的東西，恕我沒法像李笑來老師那樣讓你倆月速成，不過這些知識都掌握（或者大部分入個門）找個工作應該是沒問題的。

Python語法：《Python核心編程》

算法和數據結構： 隨便一本參考書，了解基礎概念，幫你寫出高效程序

http協議：做web http協議是基礎，推薦個入門的《圖解HTTP》

Linux：《鳥哥的Linux私房菜》，因為項目部署一般用Linux系統，所以需要了解Linux

mysql：隨便一本參考書都可以。做后端項目肯定需要數據庫

版本控制：git，目前最流行的版本控制工具

代碼風格：pep8標準

測試：pytest，正規項目需要單元測試

開發工具：Pycharm等。

web框架：django/flask/tornado等。實際上如果可以參照flask文檔教程獨立寫個博客就算入門了，至少基本的知識都涉及了。數據庫什么的最好親自安裝，善用google、stackoverflow、github。就算去培訓班估計知識點也不會超過我以上列舉的這些，這些都是工作中最緊密相關的部分。我之前練習tornado寫了個簡單的小網站微閱讀，專門閱讀我感興趣的微信號，爬蟲和網站都涉及到了。學有所用就是最好的練習方式。初學者一開始不要害怕，我列舉的很多也是我工作中才慢慢學到的，一開始學Python的時候我sql語句都不怎么會，隨著你的學習做出成果了會不斷給你正反饋，入門可能會有一段困難期需要你克服（比方說編碼問題、包導入問題、性能問題）。Python相對其他語言入門算是容易的，而且生產力高，又能干很多事（自動化、web開發、爬蟲、數據分析等等），算是性價比很高的一門語言，號稱偽代碼語言（易讀）和黑客語言（黑客工具），隨著大數據和人工智能火起來，Python再次展現出活力。

上面這些列舉我覺得這已經是一個合格開發者比較基礎的東西了，如果這個你還覺得掌握不了，那我覺得你可能不太適合入行（這些知識至少要有入門級的水平）。說Python很簡單的人可能只是把它當個玩具或者業余用用，而我是要靠它吃飯的。如果你希望深入學習，下邊我引用了很多書籍和參考資料。正像很多知乎技術牛人說的，語言只是個工具，你要掌握的是相關技術棧（數據、后端、運維、爬蟲等），而不是僅僅會使用一些Python語法糖。另外我只是個技術一般的Python后端（工作一年多點的初級工程師），我不是技術牛人，我的優點在于我持續學習總結吧。我覺得編程有時候不需要特殊的天賦，但是興趣和學習能力還是很重要的。除非你天賦異稟，不然沒有捷徑（要靠持續看書和針對性練習），這一行里牛人、聰明人、勤奮者太多了，你要怎么與他們協作or競爭？公司里的也不都是技術牛人，很多是靠編程手藝混個飯吃（所以要靠規范、流程、測試、codereview防止程序員捅婁子）。我發現現在Python慢慢火了，很多人開始學習，但是業余選手太多，正規軍比較少，而目前關于Python工程實踐方面的資料并不多，我記錄了很多工程相關的東西只是希望國內的Python學習者可以越來越專業，有越來越多有才智的人為Python社區貢獻力量。Python web入門一年(附Python web入坑指南)最后這個是我大四開始學習Python找工作的經歷和一些學習方法論，有興趣的可以看看。

以下是長文，慎入，高手請無視。沒毅力或沒興趣的建議還是跟著輪子哥看看美胸和大腿吧，程序員可能不適合你：

入門基礎

編程語言: Python

Python入門相對容易又可以干很多事(網站,運維,數據,爬蟲等），是一門方便的工具語言。2016年TIOBE排名顯示Python已經名列第四，成為腳本語言之首。 國外的Youtube，Instagram，Pinterest，Reddit， Quora等知名應用一開始都是基于Python構建，國內的豆瓣，知乎，果殼，餓了么等也是Python應用的典型。這也給了國內Python開發者一陣強心劑，Python的生態環境可以支撐起重量級的 產品。這里不想挑起語言之爭，php，nodejs，java，ruby等都有豐富的生態環境。不過目前來看，技術選型用Python在招聘、學習、培訓、敏捷開發等方面還是一個比較折中的選擇（主要在于人，而不是語言）。 Python，ruby之類的語言優勢在于其生產力，你能在極短時間內就搭建出原型從而贏得產品競爭。當然Python也有其缺點，比如Python2編碼問題，性能問題，易開發，難維護，Python3激進地舍去了很多語言不好的特性導致無法兼容Python2等。 推薦一下幾本個人認為比較好的Python書籍:

• 《Python-guide》 requests作者寫的guide
• 《A Byte of Python》 一百多頁的小書，可以快速熟悉Python語言。
• 《Python核心編程》 比較全面的Python書籍，介紹了Python語言的方方面面。
• 《Fluent Python》 Python進階，涉及了很多Python高級主題。
• 《Python3 Cookbook》 Python進階讀物。
• 《Python高級編程》 小明明的Python高級編程

當然還有Python的官方文檔作為參考，不過有些文檔有些地方比較晦澀，還是推薦書籍入門。網上目前也可以搜到很多免費的電子書。 如果有時間可以看看國內廖學峰寫的Python教程。

算法與數據結構

編寫良好的代碼需要了解常用的算法和數據結構，雖然你可能很少會自己實現，但是對于Python語言中一些常用數據結構如list, tuple, set, frozenset, dict和collections模塊中的OrderedDict, defaultdict, deque, namedtuple, Counter等應該知道什么時候用。最主要的還是了解算法中遞歸，二分等常用思想，寫出高效易用的代碼。如果你想在線練習，可以做一些Acm基礎題或者去leetcode等網站刷題。 推薦書籍:

• 《算法導論》 你可以挑選感興趣的章節啃一啃，也可以去網易公開課看下視頻教程。如果不是計算機專業的可以看下《計算機科學導論》這門公開課，正好也是以Python語言講解的。

計算機網絡

對于應用開發者來說大部分時間可能不太會接觸特別底層的問題，但是了解網絡的運行原理還是必要的。網上有個面試題 從輸入URL 到頁面加載完成的過程中都發生了什么事情？ 如果對其中大部分的概念都了解就算是入門了。網絡相關書籍可以隨便找一本看看。Http協議對于web開發者來說比較重要，需要深入了解。推薦書籍:

• 《圖解Http》 一本小白入門Http協議的好書，有大量圖片示例。
• 《Http權威指南》 Http協議最權威的講解，大部頭著作，可以看看最基礎的部分。

Linux系統

大部分Python應用都是跑在Linux服務器上的，大部分開源軟件使用的也是Linux系統，即使日常工作不使用Linux，一些基本的Linux命令也要了解。 比如常用的文件操作，目錄操作，進程操作等。你可以使用類unix系統mac或者Linux版本ubuntu作為學習環境。 推薦：

• 《Linux工具快速教程》
• 《CONQUERING THE COMMAND LINE》 掌握這上面的命令基本就可以滿足日常需求了。
• 《鳥哥的Linux私房菜.基礎學習篇》 淺顯易懂，入門Linux命令的好書。

數據庫

現在用得比較多的有三種類型的數據庫，關系型數據庫（mysql等），文檔型數據庫（mongodb等），和內存型數據庫（redis等）。三種數據庫各有優勢和特色，后端程序員需要了解下不同類型數據庫的使用方法和應用場景，靈活應用到后端代碼中。關于各種數據庫網上已經有不少資料，讀者可以自行搜索學習。

版本控制

目前最流行的應該就是git了。版本控制工具是多人協作必不可少的工具，入門的程序員需要掌握基本的git命令，可以把github作為個人練習的工具。

專業性

公司做項目不是自己過家家，需要你具備寫文檔，注釋，單元測試的能力。如果你現在還不了解一個正規Python項目都有哪些組件構成，請去github克隆一份知名的代碼倉庫，花點時間仔細分析下它的項目結構和源代碼。github上很多優秀資源你可以自己去探索。

軟技能

程序員和計算機打交道比較多，我在大學的時候就喜歡一個人悶頭啃書。但是工作了你會和很多人交流協作，你的同事（前端、測試、運維、產品經理、客戶等）、上司甚至老板，你要學會如何有效溝通和表達，拋棄一些學生思維，從一個學生轉到職場人士，這其實是一次很好的鍛煉。筆者剛入職場的時候就不太會表達協作，而且情緒易激動，甚至一意孤行導致項目延誤過，這些虧我都是吃過的。希望后來人吸取教訓，代碼之外還有很多需要學習的。

后端技術棧

對于技能需求可以在拉勾上搜一下Python的職位，看看各個公司對Python的要求。或者你可以寫個拉勾網的爬蟲，對數據做一個簡單的統計，筆者當初找工作就是這么干的。 另外，真正做項目還需要你熟悉Python的各種庫和框架，比如django/flask/tornado/requests/sqlalchemy/unittest/pytest/celery等等，掌握了合適的工具才能快速上手做東西，公司恨不得你第一天入職第二天就能寫項目。 所以，在你入了門以后請盡快熟悉Python web的技術棧。公司不管你會什么算法，只在乎你的生產力。 推薦一些文章供參考:

• 《全棧增長工程師指南》
• 《web開發路線圖》
• 《后端都要學習什么？》
• 《PYTHON招聘需求與技能體系》
• 《PYTHON后端相關技術/工具棧》

代碼風格

不一致的開發風格會給協作開發帶來困難，同時也妨礙代碼閱讀，讀代碼的時間是多于寫代碼的，所以有必要統一編碼規范。推薦使用pep8或者其子集作為代碼規范，使用vim插件Python-mode開啟pep8和pylint對代碼就行檢測。如果使用其他編輯器或者IDE工具最好也使用相關插件使代碼符合規范。工程上的代碼應該盡可能保持清晰易懂，推薦看看requests等優秀的開源庫學習下。強烈建議新手看看以下參考寫出格式規范的代碼，強烈建議打開pep8和pylint，pylint可以幫助你干掉很多低級錯誤。建議使用py的公司都指定好自己的代碼規范并且嚴格遵守，同時做好code review，防止造成以后的維護噩夢。

• 《PEP8.org》
• 《PEP 8 – Style Guide for Python Code》
• 《Google開源項目風格指南-Python風格指南》 google風格的docstring比較贊
• 《API_coding_style》
• 《code-example》
• 《編寫優雅代碼》 新浪微博的培訓課程，可以學習一下
• 《爛代碼的那些事》 Axb的自我修養，大神的文章
• 《三種docstring示例》

一個簡潔的代碼規范：

• 格式請遵守pep8,務必開啟編輯器的pylint和pep8檢測。vim請試試Python-mode插件。
• 模塊、類和函數請使用docstring格式注釋，除顯而易見的代碼，每個函數應該簡潔地說明函數作用，函數參數說明和類型，返回值和類型。對于復雜的傳入參數和返回值最好把示例附上。如有引用，可以把jira，github，stackoverflow，需求文檔地址附上。 良好的文檔和注釋很考驗人的判斷（何時注釋）和表達能力（注釋什么）。
• 動態語言的變量命名盡量可以從名稱就知道其類型，比如url_list, info_dict_list，降低閱讀和理解的難度。(我的感覺就是動態語言易編寫，寫不好后期更難維護)。比如經常用date命名，有時它是個datetime.date對象，有時候是個字符串，還有人喜歡用info結尾，有時候是個dict，時候是個string，看得我暈頭轉向，總不能所有地方都用instance判斷吧，怪不得Python3加上了type hint。沒有注釋和文檔看得我想罵人。命名在動態語言里頭十分考究，希望你可以注意。
• 風格上衡量不了請參考知名開源項目的做法。以可讀性和維護性作為標準。

編程范式

Python支持多重編程范式，過程式(Procedural)，面向對象(OOP)，簡單函數式(Functional)編程。不同人，不同語言轉過來的人，Python老鳥和菜鳥等寫出來的代碼風格迥異。筆者之前的同事有對OOP挖掘較深的，一般習慣寫OOP風格的，但現在的項目卻很少用類，之前的代碼都是用一個個函數來實現各種功能。對個人風格喜好不予評判，但是個人感覺還是需要深挖一些Python的特性，雖然Python容易入門，但是有些語言特性還是需要一段時間才能了解深入的。使用各種風格的時候要酌情判斷，比如一個過程需要維護大量的中間狀態時，單純的使用函數會寫得很冗長，這時候可以用類和子函數的形式簡化它。當你無法判斷哪種方式比較好的時候，請在解釋器里邊 import this看看。當可以實現一樣的功能時，往往簡單易懂的方式就是最好的。一些參考:

• 《requests》 requests庫是接口設計的典范，可以參考參考。
• 《Python3 面向對象編程》 關于Python面向對象和一些設計模式。
• 《OOP vs Functional Programming vs Procedural》

何謂Pythonic?

Python的世界里你會聽到這個詞”Pythonic”，大概就是指代碼符合Python的慣用法，使用的都是Python的語法糖。比如從其他語言轉到Python 的寫出來的代碼很可能受到以前思維方式的影響，寫出來的代碼不夠Pythonic: 比如:

# 不夠Pythonic
if a < b and a > c:
    pass

# Python里卻可以這么寫
if c < a < b:
    pass

# bad
i = 0
while i < mylist_length:
    do_something(mylist[i])
    i += 1

# good
for element in mylist:
   do_something(element)

# bad, 不要使用默認可變對象作為默認參數
def f(a, b=[])
    pass

# good
def f(a, b=None):
    if b is None:
        b = []

Python有一些語法上的坑，比如默認參數只計算一次，不要使用可變類型作為默認參數等，看多了寫多了就知道了。尤其是可變類型作為函數參數傳入后被改變的情況（函數盡量不要有副作用），尤其要注意。 一些參考幫助寫出Pythonic的代碼:

• 《Pythonic到底是什么玩意兒？》 賴勇浩的博客
• 《Python-guide Code Style》 Python-guide關于代碼風格的介紹
• 《Learning the Pythonic Way》 一個cmu的課件
• 《Writing Idiomatic Python3》 一本免費小書
• 《編寫高質量代碼：改善Python程序的91個建議》 給國人的書捧捧場^_^，類似《Effective Python》
• 《好好寫代碼》 豆瓣工程師董偉明的文章

敏捷與TDD

筆者非計算機科班出身，對于軟件工程的東西也不是很懂，最近掃了一本《敏捷軟件開發-原則、模式與實踐》，感覺有些東西還是挺有啟發的。在這里稍微提一下敏捷中的TDD(Test-driven development)吧。因為Python是動態類型語言，不像靜態語言可以編譯期檢查，很多問題運行時暴露出來，而且動態語言語法靈活也容易刨坑。用TDD是可以提升代碼質量的，雖然有時候完全用TDD可能有些死板，但是TDD的一些思想還是很值得借鑒：

• 測試最重要的是對架構和設計的影響，不是為了測試而測試。一般難以測試的代碼往往是設計不好，耦合嚴重的代碼。沒有測試的代碼同時也給重構帶來壓力和隱患。

編碼的時候想著如何測試它，甚至都可以改善設計。對于動態語言，一直有『動態語言一時爽，代碼重構火葬場』這種說法，說明動態語言如果沒有良好的設計和測試，以后是會埋下不少隱患的。 當你發現debug的時間甚至比寫代碼長很多的時候，當你發現總是返工對代碼修修補補的時候，或者可嘗試下TDD。 你可以學習使用下Python的unittest或者pytest等進行單元測試，以保證代碼質量。個人工作經驗也表明，難以測試的代碼往往是設計不太好的代碼。 update: 經驗表明，TDD未必是必要的，但是單元測試是很必要的。如果是新項目建議為所有的復雜函數寫單元測試，為項目質量保證。 下邊是一些參考書籍:

• 《Tips for agile developers》
• 《pytest: helps you write better programs》
• 《代碼整潔之道》
• 《編寫可讀代碼的藝術》
• 《重構-改善既有代碼設計》
• 《軟件調試修煉之道》 了解下調試和跟蹤技術
• 《代碼大全 (豆瓣) 》板磚書，從小白快速邁入職業程序員
• A simple example of Python OOP development (with TDD) - Part 1

開發工具（很多只列舉個名字，具體使用請自行google）開發和編程工具 - Python-web-guide 0.1 文檔

• Pycharm。專業的Python ide，功能很強大，特別喜歡它的代碼merge工具，不想被編輯器折騰死的推薦直接使用。
• vim。本人比較喜歡，配上各種插件編輯效率很高。Vim Awesome 可以到這個上面安裝排名靠前的那些插件，能夠大大提高編輯效率，替代IDE。其他編輯器sublime，atom，vscode，emacs等不熟，根據個人喜好來吧。(在google搜索Python awesome等可以在github上搜索到一些awesome項目，總結了該語言很多技術工具)。炫酷的效果圖：7ktuty.com1.z0.glb.clouddn.com
• 使用vim+tmux+zsh+autojump高效工作
• tmux。比screen好用，可以用來分屏等，ubuntu下基本就不用使用terminator之類的分屏工具了
• zsh。替代原生的bash shell，提供了好多方便的特性。Linux/mac下vim+tmux+zsh簡直是絕配，甚至可以直接在服務器上方便地擼代碼。
• item2(mac)。替代原生的終端。
• brew(mac)。類似ubuntu下的apt-get，可以方便安轉各種軟件和工具。
• autojump。方便在命令行里來回跳轉。

日志收集工具

• Sentry.
• Fluentd

管理及運維工具

• Supervisor.進程管理
• Fabric.應用部署
• docker.最近比較火的容器技術
• SaltStack和Ansible. 配置管理
• StatsDGraphite等web監控

調試工具

• curl
• http
• postman

一些常見原則

對于什么是好代碼，什么是壞代碼我現在還沒有太多經驗，但是最近工作接手別人的代碼感覺困難重重，還是too naive啊。每個人實力不同，風格不同，一起協作的時候確實會遇到很多問題和分歧。感覺code review啥的還是很有必要的，可以讓菜鳥學習下老鳥的經驗，也可以讓老鳥指導下菜鳥的失誤，同時避免過于個人化的糟糕風格（比如讓人想立馬離職的高達成百上千行的復雜函數，比如上來一堆不知道干啥的幻數，比如上來就 form shit import * 導致俺的編輯工具找不到定義，比如整個項目沒有一行測試代碼，比如不知道用logger，全用print+眼珠子瞅，一個bug找半天，比如沒有pep8檢測導致你的環境打開別人的代碼彪了一堆警告......)。說好的規范呢，說好的設計模式呢，說好的高內聚低耦合呢？說好的KISS原則呢？說好的DYR原則呢？其實俺只是想多活幾年，至少不要到三十歲頭發掉光。啥設計模式的可以不用，能干活的代碼就行，牢記幾個原則，沒事的時候對復雜的東西重構下，代碼不能自解釋的搞搞文檔，不被隊友坑同時不坑隊友，俺就心滿意足了。最后還是列舉一下常用原則、思想和注意事項吧(最好import this看看Python之禪，很多思想是通用的):

• KISS原則，Keep It Simple, Stupid。能簡單的絕對不要復雜，不要炫耀代碼技巧，簡單可讀最重要，后人會感謝你的。
• DRY原則。就算咱不懂設計模式，只要代碼復雜重復了就及時抽取出來，至少不會碰到大問題。
• YAGNI(You Aren’t Gonna Need It)，不要猜測性編碼。
• 快速失敗，靈活使用斷言。契約式編程(先驗條件和后置條件)
• 及時清理技術債務，防止『破窗』。
• 一次只做一件事。盡量避免復雜度過高的邏輯，盡量做到代碼簡單，意圖明確。
• 高內聚，低耦合。意義相近的東西應該放到同一個地方。寫代碼的時候想著怎么測試它就能避免過度復雜，耦合嚴重的代碼。
• 代碼應當易于理解。 《代碼大全》、《編寫可讀代碼的藝術》、《代碼整潔之道》啥的都是告訴你代碼最好自解釋，好理解。記住代碼首先是給人看的，其次才是讓機器執行的，不要過度設計。
• 不要過早優化，最小可用原則。先測量，后優化。根據二八定律，大部分性能瓶頸只在20%的部分，這些才是真正需要優化的地方。
• 不要炫技，可讀性最重要。合適的地方使用合適的技巧，不要過度炫耀語法糖導致維護和理解困難。
• Think about future, design with flexibility, but only implement for production. 盡量設計良好，避免繁雜和冗余。好的架構和設計都是不斷演進的。
• 文檔化。哪些東西該文檔化，哪些該注釋需要做好，以便新手可以盡快上手。盡量做到代碼即文檔，tornado的文檔和代碼就是典范。
• 不要直接吞掉任何錯誤和異常，一定要做好記錄。血淚教訓，使用Sentry或其他工具記錄好異常發生的信息，為定位bug提供便利，web端的bug一般不好復現。
• ......還有的大家可以自己補充

還有OOP那一套:

• 開閉原則(Open-Closed Principle)
• 依賴倒置原則(Dependence Inversion Principle)
• 接口隔離原則(Interface Segregation Principle)
• 里氏代換原則(Liskov Substitution Principle)
• 迪米特原則(Law of Demeter)
• 合成復用原則(Composite/Aggregate Reuse Principle)
• 單一職責原則(Single-Responsibility Principle)

Python代碼壞味道(新手經常犯的錯誤)

• 不Pythonic，寫得很業余，真就信了半天學會Python
• 上來就整一個不知道啥意思的magic number，大學老師沒教你不要濫用幻數？
• 上來就from shit import *
• 復雜函數沒有docstring，傳入了一個嵌套字典都不注釋，娘來
• 變量名亂起，看不出類型，加重理解負擔。我在想是不是動態語言用匈牙利命名法要好一些
• 不遵守pep8，沒有pylint檢測，打開代碼一堆語法警告，老子的編輯器滿眼都是warnning，編輯器用不好就老老實實用pycharm，用編輯器就老老實實裝好語法檢測和pylint檢測插件，沒有插件請考慮換一個editor
• 沒有單元測試，不知道怎么寫測試（print大法好？）
• 超長函數，沒有復用和拆分，我智商低，不能理解好幾屏都翻不完的，見諒。這么長居然還tm能工作，牛逼
• 到處print，debug的時候加上，上線再刪除（累不累親？），logging模塊很受冷落
• 上來就try/except了，把異常都捕獲了，吞掉異常導致排錯困難
• 沒注意可變類型和非可變類型，傳入可變類型并在函數里修改了參數，坑。。。
• 沒有邏輯分塊，沒有美感（這個就算了），就算不限制一行超過80列，也不能寫一行寫幾百列吧，左右轉頭腦瓜子疼

嗯，一開始就開啟pep8和pylint檢測能顯著提升代碼質量（各種錯誤警告逼著你寫出高質量代碼）。咱寫不了詩一樣的代碼，也不能寫shǐ 一樣的代碼。 可能很多東西對老鳥來說都是顯而易見的，不過菜鳥和高級菜鳥們還是需要多多練習積累經驗。慢慢摸索吧騷年。。。。。。

小白的踩坑記錄

文檔化

很多程序員是懶得寫文檔的，仿佛牛逼的程序員不需要寫。但是看人家真正牛逼的開源項目比如flask和tornado等，無論是代碼還是文檔都做得相當棒。對于一些項目，有些東西如部署步驟；常用命令等還是可以記錄下來的，可以使用wiki或者readthedoc，gitbooks等文檔工具記錄一下，方便新人上手。如果不知道記錄啥，就把你發現不止一次會用到的東西文檔化。個人認為需求文檔也應該有歷史記錄，方便接手的人可以快速了解業務和需求變更。數據庫字段的含義也應該及時記錄和更新。

注釋

有經驗的人都知道看別人的代碼是一件很痛苦的事情，尤其是沒有任何注釋的代碼。代碼除了完成需求外，最重要的就是維護和協作，除非你覺得你做的項目活不過仨月(或你自己玩玩的項目隨便你怎么艸)，否則就一定要重視代碼質量，防止代碼腐化(破窗)以至難以協作和維護。有時候比寫注釋更難的是知道何時寫，寫什么注釋？Python里有規范的docstring用來給類和函數進行注釋，除了說明功能外，關于github,stackoverflow鏈接、復雜的傳入傳出參數（比如嵌套字典作為參數這種你都不注釋就很不合適了)，類型說明、需求文檔和bug的jira地址等都可以注釋。凡是你回頭看代碼一眼看不出來干啥的，都應該有適當的注釋，方便自己也方便別人。當然，最重要的是代碼清晰易讀，好的命名和編寫風格的代碼往往是自解釋的，看代碼大致就可以看出功能。建議就是給所有的模塊、類和函數都加上注釋，除非一眼能看出來這個東西干啥，否則都應該簡潔注釋下，讓別人不用一行行看你的代碼就大概知道你這個東西是干啥的。最后注意的就是一旦函數更改及時更新注釋。qiniu的sdk寫得就不錯，可以去github看看。總之，”Explicit is better than implicit.”, 代碼里不要有隱晦的東西，一時偷懶將來可能會付出幾倍的維護代價，請對將來的自己和他人負責。

• 《Python docstring》

Code Review

筆者認為code review是一件非常重要的事情，可以有效防止代碼腐化，同時方便同事了解業務。可以在公司搭建Phabricator（facebook在用）類似工具進行代碼review。