課程回顧與總結

回顧提出的問題

​ 問題部落格：寒假作業2/2

產品使用技術的創新度

​ 當時我認為，我更傾向於富有創新意識, 開刀時突然想到一個新技術的專案之後在加上穩定的運營。但是在這次實踐中發現，如果一個專案使用了過多的還未經過驗證的新技術，專案反而更容易流產，即使專案上線後也會不穩定。在這次實踐中，我們使用的新技術主要是在攝像頭接入和人工智慧識別車輛這塊，而這兩塊在大部分時間中是較不穩定的部分，也花費了很多時間去修復bug。

白盒測試要知道程式的結構嗎？

​ 白盒測試的定義就是知道產品結構內部的工作過程的情況下進行測試的，所以答案是肯定的

創新與向後相容的平衡

​ 在這次實踐中因為並沒有長期的迭代更新，所以沒有遇到這種問題。但是我認為要找到創新與向後相容的平衡點，是整個團隊需要共同討論的問題，要衡量相容的代價、創新所帶來的收益等因素。

五個階段收穫

需求

​ 需求分析主要我參與的並不是很多，主要的參與點就是評估他們提出的需求以我們的技術能力來說是否可行。當然，在這個部分中，我也體會到了團隊協作的重要性，可以取長補短，可以讓合適的人在合適的位置發揮最大的功能。

設計

​ 設計部分我主要負責設計資料庫表以及類圖。這部分就相當於建房中打地基的過程，事實上在後期開發的過程中還是有遇到因為資料庫設計缺陷而導致實現部分功能較困難，甚至是無法實現，導致修改資料庫表結構而返工的情況。在這個部分，我意識到了設計部分會對後續開發有深遠影響。

實現

​ 在實現過程開始時，我作為後端組長，首先是分配後端工作內容。而在開發過程中，我也要負責稽核程式碼，保證程式碼的質量，同時也用了GitHub的Actions功能保證合併的程式碼可以編譯、執行以及通過單元測試。而我的開發的任務則是攝像頭接入的部分。

測試

​ 測試的部分和開發的部分是有重疊的，大部分bug是在集中開發中前後端聯調中發現的。雖然我們都有寫單元測試，但是在聯調時還是出現了很多bug，有的是單純的前端或後端設計的缺陷，但是也有的問題是因為前後端並沒有及時交流而出現的。所以我在測試中認識到了前後端交流的重要性，不但要明確各個介面的各個引數的意義，而且在任意一方因為技術或別的原因要修改介面時，要及時的溝通，不然後期返工的代價更大。

釋出

​ 我們以為經過了前面的測試部分後，釋出應該遇到的問題比較少，但是實際上還是在釋出中遇到了很多問題。舉個例子就是小程式要求釋出必須使用https，而這在開發和測試階段我們都是沒有考慮的。所以我認識到釋出後也要進行充分的測試，及時的修復bug

個人技術總結

​ 技術總結部落格：RtmpDiscovery-推流服務發現

​ 簡介：一個可動態拓展的nginx rtmp流發現服務，部署完畢後，可以動態註冊nginx rtmp 伺服器，並將伺服器資訊釋出到指定的redis上