自學java入行工作的第十五個月

從這個月開始逐漸將每月工作記錄放到月初，之前都是15號。

這月有兩個問題，1.在工作改聽取誰的；2.項目著急上線的時候如何處理

小插曲：屎山代碼，代碼寫不好 被辭退

判斷是否著急上線——假著急實壓榨

1. 看自己的領(lǐng)導有沒有在寫代碼
2. 看項目業(yè)務(wù)復(fù)雜不復(fù)雜
3. 思考假如來不及上線，最終的鍋會不會到自己頭上

需求優(yōu)先級——工作中有的人需求一多就亂手腳

需求辨別：是否是真實需求 來自客戶？> 發(fā)需求的是否有實權(quán)? > 發(fā)需求的人是否了解業(yè)務(wù)？> 是否了解代碼實現(xiàn)？

需求排序：線上bug > 功能缺陷 > 新增功能 > 后端代碼優(yōu)化|前端樣式優(yōu)化

線上bug：

1. 線上環(huán)境問題。測試沒問題，但是上了生產(chǎn)因為https或者服務(wù)器網(wǎng)絡(luò)請求限制導致的bug
2. 線上缺少數(shù)據(jù)。測試環(huán)境數(shù)據(jù)比較全面，生產(chǎn)缺少數(shù)據(jù)導致的問題

功能缺陷：

1. 場景沒有考慮全面。功能沒有考慮全部場景，沒有做全面的參數(shù)校驗或者場景限制，給了用戶瞎操作的空間。這一塊主要是一些走流程，導致數(shù)據(jù)走入了下一個流程
2. 代碼問題。代碼沒有處理異常等等
3. 三方對接。多半也是流程問題，三方數(shù)據(jù)錯誤或者接口調(diào)用后沒有正確處理導致的錯誤

需求變更：要看放不方便修改，不方便修改就當成新增功能做，方便修改就當成功能缺陷處理

新增功能：基本功能優(yōu)先處理，擴展功能放一放

后端代碼優(yōu)化|前端樣式優(yōu)化：著急上線的寫的垃圾代碼，或者因為技術(shù)問題導致一時半會兒沒有找到合適的實現(xiàn)方式，曲線救國。

總結(jié)：功能上的問題優(yōu)先處理，生產(chǎn)上的問題優(yōu)先處理