如何避免做 Python 後端只會 CRUD？

公司的架構單一，就是一套django + vue，感覺還是只會CRUD？感覺前途一片渺茫？主要遇到的問題是技術提升慢的問題。

我不知道你說的，只會crud是哪種級別。

但是，不管什麼語言的後端，絕大多數開發應該都是從crud開始吧，只是有些人學的越來越多，不僅僅是crud了，有些人會在crud上重複很多年。當然，我也是應該算是只會crud的人吧。

我覺得這個原因，一方面是公司最大的需求就是基於框架的crud，另一方面，一些好的項目，python實現並不多，java居多吧。

但是我還是十分願意分享一下我的工作經驗，到目前為止從事python開發三年了。

當然，是小公司，所以接觸的東西蠻雜的，試著學精，但是能有多精，也沒人能衡量，我自己也不能。

最開始進入的公司，是supervisor+tornado+mysql+centos做的架子，我一度以為後端就是crud，沒啥難的（會的越多，才會知道不會的越多，我太菜了）

但是當時寫了一個確實很耗時的東西，tornado這種單進程單線程的問題就出來了，雖然是非同步加協程。

不知道如何解決。

百度之下，接觸了celery，開始接觸生產者消費者模型，開始知道http協議的一些東西，開始理解隊列的用法，開始理解rpc的概念。

這個開始，大概是做開發3個月之後了。

再之後，新的問題就出來了，當時我接手的代碼，沒有採用orm，也有可能是沒有合適的非同步orm可以供tornado使用，手寫sql很頭疼，於是我接觸django，開始了解orm的用途。

開始去思考django和tornado的適用場景——雖然會思考，但是也養成了我設計表用django，項目開發用tornado的混合做法。orm現在用的peewee，有非同步的擴展。

期間，對python的非同步算是花了功夫，以至於我不喜歡用線程，我喜歡用單進程+workers的模式來做。後來公司所有基於tornado的項目幾乎都是我在負責，因為我對非同步的用法確實專研了一些的——當然也是另外一家公司了。

至此，雖然我覺得在python的非同步的應用上，很熟悉了，但是底層原理，我學不來。

再後來開始放棄django和tornado的模板語法，使用了前後端分離，不管項目大小。

最大的原因是，當時公司有個前端，負責寫頁面，用node.js那套打包。然後每次改完我都得改成模板語法。

頻繁的改動，比寫crud還累人，徒勞無功的感覺，所以為了根本上杜絕這個問題，我更願意前後端分離。

當前後端分離開始後，我能更關注後端的問題——這比全棧關心的點就少了很多。

然後逐漸開始關注的是後端的性能，linux，存儲，部署，測試，等等，總結起來就是亂，但又每個領域都值得花功夫。

以至於我一直想找到tornado的qps很高的證據，但一直沒啥好結果——雖然協程非同步確實很快，但python本身很慢，所以它在非同步io上只能說是很好（能解決C10k，但是現在已經出了更大的挑戰，它應該不行，源自於python本身的速度），但離那種極端的好，還有一段距離。

關心性能之後，首先接觸到的，是分散式部署——基於nginx

負載均衡演算法有哪些，隨機，加權隨機這類的。

在後面開始了解帶寬和請求量，直到最後，我的觀點是：性能提升的難點，最後都很容易落在資料庫或者帶寬上，因為nginx帶來的橫向擴展，以及rpc的使用，讓單台伺服器的處理壓力分解到了多台伺服器。

所以我還在用python，一方面是覺得他的慢不是問題，另一方面是，一些東西學好了之後，語言只是實現手段，而python是在我學會一個東西後用於實現的。

也去看過關於資料庫方面的書，重點看的是索引。

當然也看了一些資料庫多節點的書。

以上很多部分是看了書，但是沒有實操的經驗，比如mongodb集群。

當然linux的書也看。

再後來，我發現項目的部署很頭疼，代碼拷貝，發布，測試，等等，有時候很容易出現弄錯或者發布錯的東西出去——對，公司沒測試崗位，開發就是測試。

所以我開始了解項目的測試部分，比如tornado自帶的測試部分。

再後來學習docker。

再後來學習微服務，再學習API網關。

再後來學習jenkins。

零零散散的就是現在的狀態了，就算差點什麼應該也不是很重要的技能點吧（redis緩存這種東西學了，但是並不是時時刻刻都會用，一般是覺得有資料庫讀寫壓力或者確實出現壓力了，再採用）

自己用tornado寫了一個和api網關類似功能單精簡很多的項目，結合資料庫維護所有的小項目的介面，庫表分離一開始就弄了。（嗯，它只做從資料庫中讀數據然後轉發，也有緩存。很簡單的一個小項目，大概算是我對http協議數據格式，tornado這種框架用法，兩者的結合吧）

這裡面涉及到的東西回想起來並不多，沒涉及到深領域的技術。

現在，基本上就是以後端為主，django和tornado結合，寫各個小項目，然後通過jenkins+docker進行自動化測試，發布，走API網關，全流程了。

到現在為止，我覺得我不能算是一個純粹的crud了，因為我確實看了很多東西並且嘗試把它們用起來。

但是，這些看了的，或者用了的東西都是屬於應用層面的，我並不太明白他們底層是如何實現的，可能在資料庫索引部分稍微好點，因為不去理解它的數據結構，我完全沒辦法理解為什麼要這樣或者那樣建立索引。

這大概就是我工作三年所學所用，想想，和只會crud也沒啥差別吧。

只是，從原本一個遇到問題不知道如何解決的自己，變成了一個，遇到問題很容易知道問題出在哪裡，不管是去治標還是去治本，還是去百度，都知道該看什麼，大致該用什麼，大致該搜什麼——更像是，廣度和深度的問題。

比如三年前的問題，做爬蟲，遇到頻繁更新的網頁時該怎麼辦？

嗯，肯定是頻繁抓取，例如分散式爬蟲，正則或者beautifulsoup巴拉巴拉的。

但是現在我可能會說，好好利用http的304和Etag的值，我能省下很大一部分算力，關於判斷它是否更新（大概是看了一些tornado源碼的結果吧，我相信這種知識，tornado有，其他語言的其他web框架應該也有，這是對瀏覽器緩存的理解吧）

自己以後應該會專註於，devops這個領域，基於python+jenkins+docker，走自動化，然後有時間去學習更多的東西，偏代碼設計，或者項目流程設計，項目規範，資料庫設計，等等的。

或者沒有這些機會的話，就試著從錯誤入手，珍惜開發過程中遇到的每一個錯誤，能學多少算多少吧。

反正，還年輕，乾坤未定。

ps：

1，我不知道我看的書夠不夠多，大概一個月一本（包括一些電子的文檔或者框架文檔）左右，有些書是翻來覆去的在看，因為每次我會先看目錄，選擇我要看的，然後閑暇之餘重新看目錄，看已有的，最近好像接觸到的有用的概念，然後試著用。

2，我對數據結構這塊也看，但是真的差，那種沒有自己親自寫過的差，但是大致知道該不該用。比如python有個基於隊列的rpc框架，用字典來存（非同步的await），只是測試版，但我知道我不會去輕易用，因為字典這種結構，當拋出裡面的數據後，佔用的內存不會少，得用其他的結構。

3，我已經在現在工作的地方幹了近2年，屬於靠近學校老師的那種工作內容，所以工作量不大，時間很多，所以，也就看書看得，我覺得比較多了。

4，聽說後面django會出非同步的框架，我想到時候我會試著直接在tornado中使用django的orm，估計會更順手。

5，最後，希望有前輩們能分享一些他們的進階過程，感謝！我也只是一個crud層面的人，想知道我進一步該如何學習。

筆芯～

前兩天 hacker news 上有篇文章說的挺好: Dont learn to code, learn to automate.

編程的初心是什麼？是為了讓電腦替代人工的重複工作，從而更加準確高效。比如說記賬這件小事兒。最開始的時候，人們在紙上記賬，容易出錯而且費時費力。後來有了 Excel 等電子表格，於是人們可以在電腦上記錄，以前需要手工來的『求和』等操作只需要輸入公式就可以，而且也不會犯錯。但是，慢慢地，管理散落的 Excel 文件又成了一項重複性的工作，於是人們可能又開發了多種多樣的 SaaS 化會計軟體。所以說自動化的層級是不斷推進的，在現在看來高度自動化的腦力工作在未來可能又變成了機械重複勞動。

回到 CRUD 這個事情上，如果你能感覺到每天都在做重複性的工作而沒有提升，這是好事兒，說明你當前工作的抽象層級需要提升了。具體到編程來說，你需要嘗試提高元編程能力，不管是通過代碼來生成代碼，還是利用語言本身的高階函數等抽象能力。

舉個例子來說吧。公司里某個比較簡單的後端服務之前是使用 Django Rest Framework 做的 Restful API，每個模型都需要寫 Serializer/ViewSet 這些東西，但是其實並沒有什麼複雜的邏輯，基本就是原封不動複製粘貼，偶爾有一些需要加幾個特殊欄位。最近要改用 Flask 了，發現這些重複的代碼貌似沒有什麼作用，相比資料庫的 schema 沒有提供更多地信息量，其實完全可以直接從資料庫的 schema 生成模型文件和 restful 介面，於是寫了一個工具直接搞定了。後來感覺這個工具還挺好用的，就放在 GitHub 上了：https://github.com/yifeikong/flask-lab

總之，提高自動化能力，提高抽象層級。

新技術如果有業務需求，學起來是很快的，而且很牢固。

但是，沒有業務支持，你就不學了么？

比如，我就總結了寫api的一些經驗，自己搞了一套更方便的api庫

https://pcloth.github.io/api-shop/?

pcloth.github.io