背景描述：目前在一家**公司工作，2023年初研發中心部門改革，小組重組，被分配到了**平台的維護組。下面內容是對近期維護工作的乙個總結：
個人感受：以前也在老東家的團隊也做線上系統的維護和新產品的研發，由於大家的認真負責，leader的管理也很到位，線上的系統很少有bug反饋，不管是ui上迭代，還是系統邏輯的公升級都很順暢。
目前負責的平台執行了3年多，可能由於當時邏輯設計問題，也可能是執行問題，發現近期反饋的問題多是邏輯問題，在此對這些問題的原因不做**和深究，只是想講講面對線上問題的維護工作如何做，以及如何優化：
1， 對問題反饋流程的完善：面對客服、銷售、營銷中心不同部門的反饋，一定要建立反饋流程，不然5個人的支撐小組工作會很繁忙，並且介面人只有乙個人。
沒有流程就沒有規範，也就沒有後期調整的資料**。
對流程的建立，起初可能會讓以前沒有走流程的人心理上有點不舒服，但長期看對工作效率是有幫助的；
由於小組職責的定位不清晰，導致現在對很多問題反饋都做處理，本來應該客服去解決的問題，小組成員在解決。
3，對線上系統維護工作和新產品研發任務的時間平衡：
眾所周知，大家都喜歡做新產品，不喜歡維護舊有的系統，原因不言而喻，呵呵。
可是，線上系統的bug不修復，就是對使用者的不負責。1個月4周的時間，至多2周的時間、資源、精力解決線上bug，保證至少有2周的時間來對新產品的研發。
~~~~~~~~~~~ 華麗的分割線 ~~~~~~~~~~~~~~~~~~
今天剛好看了一本書：《**可用性測試及優化指南》，雖然是講可用性測試的內容，但是讀了2章發現對於線上系統的bug修復工作也有指導意義，下面摘錄了幾條觀點：
1，對問題做優先順序判斷，優先解決最糟糕的問題；
方法：開小組會議，在問題清單中找出最嚴重的10個問題，然後提出解決方案並執行；
2，越少越好：修復問題時，投入越少越好；在快速修復和完美修復之間做取捨，目前針對我們小組的情況，我選擇快速修復。
方法：1，微調，而不是重新設計；2，做減法；
對const的總結與思考
const修飾的資料型別是指常型別，常型別的變數或物件的值是不能被更新的。最初的目的是為了取代預編譯指令define，繼承define的優點並且擯棄它的缺點。舉兩個例子 1.從記憶體角度 define max d 10 const int max c 10 此時儲存在符號表，未分配記憶體 int m...
對Flex布局的總結與思考
閱讀本文之前最好對flex布局有基本了解，可以通過 參考資料 中列舉的資源來學習。一維布局模型 one dimensional layout model 元素項沿著水平或垂直方向來排列，就像一條沿著乙個方向的 流 與之對應的，css grid layout是乙個二維布局模型。兩者互為補充。空間分配 ...
DVR專案的維護與擴充套件工作的總結
不知不覺已經在dvr專案裡渡過了差不多5年的光陰了，最早由乙個測試員到乙個只做模組的程式設計師，再到管理乙個專案的管理員，總結過去，卻感覺碌碌無為，唯一感到欣慰的是客戶都可以拿著我們的方案量產，但內部管理卻如此雜亂。因此今天應該好好總結一下過去都在忙些什麼，未來應該如何提高效率。首先總結一下dvr的...