參加Python培訓前應該做哪些準備?

在選擇進行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。

 

 

相關新聞

聯系我們

400-080-6560

在線咨詢:點擊這里給我發消息

郵件:[email protected]

工作時間:周一至周日,09:00-18:30

QR code
云南快乐10分开奖直播