自學(xué)java入行工作的第十四個月
自學(xué)java入行工作的第十四個月
目前我做的工作一是維護項目，主要是修改bug、功能缺陷、新功能；二是新項目開發(fā)，主要負責(zé)一個單表接口開發(fā)和后管頁面。不論新老項目，總的來說就是一件事，寫業(yè)務(wù)代碼，主要問題一是需求描述不清；二是第三方接口的對接很惡心；三是原來開發(fā)的功能不完善；四是奇怪的bug
bug：
- 反應(yīng)過來有問題，我一查就沒問題。。。
- 用戶明明做了某一部操作，然后說什么都沒干就這樣子，怪功能不行，直接找日志打他臉
- 項目經(jīng)理不懂流程說成是bug
- 找日志困難，沒有日志追蹤，找bug困難
需求：
- 需求很抽象——就幾個很抽象的頁面，然后說就這樣子就行了很簡單，我也說了不能這么做會出問題（可用性、穩(wěn)定性差），上線之后就各種問題，永遠要把用戶當成白癡
- 需求溝通困難——因為是自己維護的項目，所以也比較熟悉，一看需求我就知道怎么做了，但是跟產(chǎn)品溝通實際實現(xiàn)的時候往往要解釋很久，因為產(chǎn)品雖然也是技術(shù)出生但是功能實際實現(xiàn)代碼不知道。還有就是需要跟售前掰扯，因為售前不懂技術(shù)。
- 需求情景不明確——售前提需求的時候不說明這個功能是什么情況能觸發(fā)，導(dǎo)致我開發(fā)完之后還要改，因為我剛接手對于一些業(yè)務(wù)不了解
- 需求無法實現(xiàn)——無法實現(xiàn)的原因，一般都是第三方不支持導(dǎo)致我這邊沒法做，其次就是需求提的很無語，異想天開。
- 需求甩鍋——對接方刷鍋說他們數(shù)據(jù)、接口沒問題；需求做完了然后需求經(jīng)理說這個需求不是這么做的。。。
- 改需求——都確認了沒問題，都改了好了，結(jié)果說要重新改一下。。。
- 自研與外包的區(qū)別在于前端，我也做一些前端，很無語——隨便弄弄不就完事了，字體顏色什么的還要搞
三方：
- 很抽象的接口——調(diào)用充值接口始中返回成功，三方說防止我們調(diào)用失敗。。。調(diào)用對賬接口始中返回成功，三方說這個接口是把你的記錄和我們庫里記錄對比，對缺少的接口進行充值。。。
- 很抽象的設(shè)計——門鎖的密碼刪除修改都是拿到他們的庫里的記錄id修改，然而這個id始中會變，假如有一個id為3的記錄，當你把id為2的記錄刪掉后，id為3的會變成2，也就意味著，刪除修改等操作要調(diào)接口去獲取。token失效了也不會返回token失效的錯誤code，導(dǎo)致根本不知道token是不是失效了
- 很抽象的三方后管——你在你以為的菜單標題中獲取不到想要的數(shù)據(jù)，比如你想要查交易記錄，然后進入了交易記錄這個菜單，但是他查出來的是用戶信息。。。
- 很吊的三方——把請求參數(shù)返回內(nèi)容完完整整的截圖給他，他只會改參數(shù)文檔錯了都不知道，調(diào)不通就說我們都能用的，你自己研究吧。。。
功能開發(fā)：
- 功能完善度——沒有刪改接口，原來并不是所有程序員都會把功能場景思考充分，考慮用戶體驗，現(xiàn)在就是我在背鍋
- 項目結(jié)構(gòu)復(fù)雜度——雖然是二開，但是我發(fā)現(xiàn)實際并沒有用到開源框架主要的功能，唯一用到的是用戶管理模塊。但是卻完整繼承了開源項目的各種modle，wrapper、viewer啥的層
總結(jié):
- 需求開發(fā)全程都要有記錄，不要以自己的想法去開發(fā)功能
- 開發(fā)前確認需求，充分考慮場景，描述開發(fā)復(fù)雜度和預(yù)計開發(fā)時間
- 開發(fā)中有問題及時反饋，關(guān)鍵處一定要打印日志
- 開發(fā)后準確描述功能和具體使用場景，后期可能會產(chǎn)生的問題，以及對應(yīng)的解決方案
- 上生產(chǎn)前確認測試完畢，功能正常且符合需求
- 上生產(chǎn)后及時測試，及時反饋，做好回退的準備等等
標簽：
