作者 | 金色旭光
在過去的一個半月里我第一次作為后端開發組長角色參與公司項目從0到1的開發，記錄這一次開發的經歷。
1、背景介紹
首先說明一下背景。我所在的公司是做智慧社區相關業務，開發的項目是系統升級工具，方便公司實施同事安裝和升級系統。
參與后端開發一共四個人，包括我在內。其他三個同事有一個是應屆生、兩個做大數據的。按照公司的技術規劃，對內項目開發節奏要短平快，用Python語言完成，對外的項目一律用Java語言完成。
項目經過正常開發生命周期，包括需求采集、產品設計、系統設計、詳細設計、編碼、測試等過程。其中詳細設計就是針對接口做的詳細設計，一共用時3天完成，設計了45個功能點，包括40個接口和5個初始化準備工作。編碼用時計劃為3周。最終在時間點之內完成了相關的開發。
我在這次開發過程中擔任的是組長的角色，主要的任務包括：
（1）項目框架的搭建。本次開發是一個從0到1的過程，在此之前并沒有Python項目的框架。
（2）關鍵技術的實現。包括通用接口，復雜的技術點。
（3）任務分配。所有接口根據任務量分配給指定的成員，完成最多的接口開發。
2、項目框架搭建
Python做web開發常用的項目框架其實并不是很多，我的候選項有三個：
Django 前后端不分離框架、Flask 最容易上手的框架、FastAPI 異步高性能框架。
對比這三個框架，我從業務邏輯、公司技術棧、復雜度等三個角度出發，選擇了Flask。
業務邏輯
業務邏輯對性能并沒有特別要求，就是通過接口調用運維的ansible腳本，沒有高并發，計算密集等任務，所以三個都能滿足。
技術棧
公司技術棧是前后端分離，所以Django這種前后端不分離的框架并不適合，雖然Django也可以做純后端開發（防杠）。
復雜程度
復雜度來說肯定是Flask最簡單。Django號稱大而全，配置復雜。FastAPI是異步框架，需要學習異步編程，雖然用來做同步框架也很絲滑，但是學習成本需要增加很多。其他三個同事都沒有做過Python項目，所以盡量減少學習成本。
經過這三個方向的衡量，最終確定了Flask框架，搭配peewee orm數據庫框架。核心的技術包括：
（1）web框架 Flask
（2）數據庫ORM框架 peewee
（3）數據庫 sqlite
（4）運維腳本執行模塊 subprocess
（5）WSGI服務 Gunicorn
（6）代碼檢查工具pre-commit
在編碼前我已經準備好完整的項目框架，寫好了數據庫CRUD接口的demo，后續開發過程同事模仿相關接口，一定程度上提高了開發效率。
3、關鍵技術實現
帶團隊開發并且是帶領成員第一次做Python項目，自然要將有挑戰的任務安排給自己。在關鍵技術的實現上挑選三個有代表性的講解。三個分別是：系統命令執行通用接口、流式日志、sqlite 多線程寫問題解決。
系統命令通用接口
項目主要用于公司開發的其他系統安裝和升級，因此需要調用運維人員用ansible編寫的相關腳本。調用的ansible腳本格式如下：
ansible-playbook 03.mysql.yml
ansible-playbook 08.zk.yml需要到指定的路徑下執行如上的命令。在詳細設計階段就知道需要使用Python調用系統命令的工具，所以就讓應屆生同事調研了subprocess模塊，輸出相關文檔。一來是給新人一個學習方向，再則借這個機會熟悉項目需要的技術。
在開發階段根據對相關模塊的理解，完成了通用接口的開發。寫通用接口切忌朝令夕改，依賴它的代碼也要隨之變化。一兩次還能接受，次數多估計要被問候祖宗了。所以該接口實現程度不僅僅是寫完，而且是自己親自調用，確認沒有問題才宣告完成。
在沒有完成之前耐著性子調試，直到沒有任何問題才在群里告訴其他開發人員。整個系統中需要大量的調用該命令執行腳本，最終也都比較順利的完成，沒有因為接口造成的bug。
流式日志
按照產品的設計，當一個組件在安裝時需要在web頁面上展示日志，并且日志的格式要和終端中安裝日志一樣，也就是一行一行的滾動打印。產品對日志的要求是全量滾動展示，刷新頁面要能夠再次全量展示出來。為了實現該功能，調研了三個方案：
一、定時刷新。缺點：日志有幾萬行，每一次讀取全部日志給前端，前端會卡頓，而且打印也不連續，體驗不好。
二、websocket。可以完成后端向前端的主動推送，但是刷新頁面并不會從頭開始推送。
三、流式響應。可以將大塊文件切分成小塊分批傳給前端，刷新頁面時會再次從頭開始推送，符合要求。
經過對比最終使用了流式響應，也就是ChatGPT那種響應的方式。但是需要解決一個問題：什么時候結束推送？因為安裝一邊向文件中寫入日志，流式日志一邊讀出日志，如果日志已經讀完了安裝還沒結束，那這個時候肯定需要等待而不是停止響應。
解決辦法是在安裝完成之后插入標記字符，當流式日志讀取到標記字符時就表明結束了，沒有讀取到標記字符則等待。核心代碼如下：
def log_flow():
query = request.values
log_path = query["log_path"]
def generate():
with open(log_path, "r") as f:
while True:
chunk = f.read(800)
if not chunk or chunk.isspace():
time.sleep(0.1)
if chunk == 800 * "-":
break
content = json.dumps({"content": chunk})
yield f"event: message\ndata: {content}\n\n"
time.sleep(0.05)
return Flask_response(generate(), mimetype="text/event-stream"效果：
sqlite3 多線程寫問題
在數據庫存儲這一塊，領導欽定用sqlite3，咱也據理力爭過用MySQL，but無效。領導說該項目只需要一個輕量的數據庫即可，sqlite3輕量，所以就很合適。而且其他項目中已經使用的非常成熟了。好吧，既然領導堅持，我也只能硬著頭皮上了。
開始還沒問題，到了項目開發中后期就發現問題了，接口經常報錯：
File "/home/ljk/.virtualenvs/idt_dev/lib/Python3.8/site-packages/peewee.py", line 3246, in execute_sql
cursor.execute(sql, params or ())
File "/home/ljk/.virtualenvs/idt_dev/lib/Python3.8/site-packages/peewee.py", line 3014, in __exit__
reraise(new_type, new_type(exc_value, *exc_args), traceback)
File "/home/ljk/.virtualenvs/idt_dev/lib/Python3.8/site-packages/peewee.py", line 192, in reraise
raise value.with_traceback(tb)
File "/home/ljk/.virtualenvs/idt_dev/lib/Python3.8/site-packages/peewee.py", line 3246, in execute_sql
cursor.execute(sql, params or ())
peewee.OperationalError: database is locked查詢之后發現是sqlite3不支持多線程寫。sqlite3支持事務，是用庫鎖來完成的。當一個寫入開始后，整個數據庫都加鎖了，再次有寫操作就會報錯。
這個問題首先從技術上是不好解決的，sqlite3的架構設計就是如此，還能讓它支持多線程寫嗎？只能通過業務邏輯解決。經過一次會議討論之后，得出幾個解決方法：
- 分庫。將寫操作分到不同的庫里完成。既然寫操作會鎖庫，那就分出不同的庫，就能避免鎖庫的問題。
- 全局寫隊列。將所有的寫放到一個消息隊列里面，將多線程的寫變成串行的寫。
- 全局寫標識。所有的寫操作開始前判斷是否有可寫標識，能寫入就寫入，否則接口返回，告訴前端數據庫繁忙。
經過投票，大家一致決定用第三種方式實現，技術難度最小，代碼侵入性最少。因為第三種方案是我提出來的，所以最終由我來完成。具體的過程可參見另一篇文檔《peewee操作sqlite鎖表問題分析》。
最終是解決了該問題，雖然不是優雅，但是在目前的時間成本和風險控制上局部是最優解了。后續將調研peewee這個ORM框架提供的sqliteQueueDatabase實現寫隊列。
摘錄于peewee擴展插件playhouse：
SqliteQueueDatabase可作為常規SqliteDatabase。如果你想簡單點 read and write 從訪問sqlite數據庫多線程.
SQLite在任何給定的時間只允許一個連接寫入數據庫。因此，如果您有一個多線程應用程序（例如Web服務器）需要寫入數據庫，當一個或多個嘗試寫入的線程無法獲取鎖時，您可能會偶爾看到錯誤。
SqliteQueueDatabase 旨在通過一個長期存在的連接發送所有寫查詢，從而簡化操作。好處是，您可以看到多個線程在向數據庫寫入時沒有沖突或超時。但是，缺點是您不能發出包含多個查詢的寫事務——本質上，所有寫操作都在自動提交模式下運行。
4、個人感受
第一次帶團隊開發，才明白很多事情。
做項目的主人公
第一真正理解什么叫主人公意識。各種文章都說要對項目有主人公意識才能成長更快。我感覺只有站在這樣一個位置上才能感受到這種意識。
項目進度的第一責任人就是你，項目中出現了大大小小的問題都是找你。領導會問題項目進度如何，有沒有阻塞，能不能按期完成？隊員會問這個校驗框架是否ok？這個語法有沒有問題？測試會找你說這個bug該給誰的？所以你必須對這個項目了如指掌，小到代碼的一個配置項，大到工程進度的把控。開發過程中有任何問題都得及時頂上，組長就是一塊磚，哪里需要哪里搬~
團隊和諧
再說說團隊的和諧。以前做一個小開發，只要完成自己的任務就可以了，團隊的氛圍影響我寫代碼的速度嗎？帶團隊開發就不一樣。團隊中有各種特點的同事，有埋頭苦干不匯報進度的、有能力強脾氣差的、有脾氣好進度慢的。總之各種性格的人都會存在。
本次開發中就遇到了一個能力強脾氣差的，看到技術上小問題就直接群里開懟，誰不是熱血小青年？第一次遇到這種情況可想而知。領導不得不為此找我們談話一兩次，甚至驚動了大部門領導。那段時間團隊氛圍特別差，沒有人說話。我也不敢多說什么，害怕氣氛更差，項目不能如期完成，到那個時候不是我的問題也變成我的問題了。所以只能選擇忍一忍，盡量回避分歧。好在領導的談話起到很大的作用，該安撫的安撫，該批評的批評，后來也沒有發生語言的沖突，順利按期完成項目。
總結
第一次帶團隊做項目對我來說是一次挑戰和提高。從技術層面講讓我以后面對技術選型時能以更高的角度看待問題；從個人角度講這是一次難得的機會讓我負責開發團隊，對接測試團隊、前端團隊、運維團隊等。這對我的溝通交流都是一次鍛煉。
最后，希望下一次做的更好，讓所有組員都能有一些進步。
