遇到緊急需求并且時間安排不過來的時候舆床，應(yīng)該如何去合理的安排時間和精力去平衡工作與生活呢？
一、敏捷開發(fā)過程
需求背景：
A領(lǐng)導(dǎo)要求的研發(fā)任務(wù)靖避，計劃3個月后上線
開發(fā)過程：
某程序員夜以繼日九默，瘋狂開發(fā)震放，但是無奈模塊關(guān)聯(lián)較多，導(dǎo)致開發(fā)過程中顧此失彼直到上線前仍然在改問題單
上線結(jié)果：
上線的日子逐漸來臨驼修，各種問題仍然被頻頻爆出殿遂，開發(fā)诈铛、測試、運維等人員苦不堪言墨礁，終于上線了幢竹，所有人等著這一刻，一直熬夜到凌晨兩點才下班
二恩静、需求開發(fā)暴露的問題
1焕毫、對于整個需求、上到領(lǐng)導(dǎo)下到員工驶乾。錯誤的預(yù)估了整個需求的技術(shù)開發(fā)周期
2邑飒、開發(fā)過程中，存在多方人員分工與協(xié)調(diào)级乐，各個人員忙于自己負(fù)責(zé)的模塊疙咸，導(dǎo)致公共模塊驗收緩慢
3、開發(fā)人員對于自身的時間安排也存在諸多問題风科，主要體現(xiàn)在以下幾個方面
(1) 寫代碼的時間占據(jù)了80%撒轮，思考時間卻只有20%，導(dǎo)致程序運行后bug不斷
(2) 對于整個需求的開發(fā)模塊贼穆，沒有清晰的認(rèn)識腔召，而是邊寫代碼邊進(jìn)行修改，后期才進(jìn)行重構(gòu)扮惦，導(dǎo)致代碼不健壯
(3)
三臀蛛、改進(jìn)思路
1、代碼設(shè)計
（1）目錄結(jié)構(gòu)設(shè)計崖蜜、代碼風(fēng)格浊仆，這里主要包括對于需求中所涉及的模塊進(jìn)行分層設(shè)計，比如pages豫领、utils等
文件夾命名：是否要按照業(yè)務(wù)邏輯劃分抡柿、比如首字母是否大寫等
html、class命名：dialog_wrapper等恐、dialog_title洲劣、dialog_header_btn、dialog_body等
變量或者props命名：moal模態(tài)框區(qū)別于popup课蔬、appendoBody是否添加到body上囱稽、closeOnClickModal當(dāng)點擊moal的時候關(guān)閉模態(tài)框等
方法命名：handleWrapperClick處理wrapper點擊事件、afterEnter/afterLeave 打開或者離開時事件處理
（2）公共組件二跋、工具類設(shè)計战惊、彈框設(shè)計：確保可復(fù)用扎即、高內(nèi)聚吞获、低耦合的原則况凉，同時滿足單一職責(zé)原則，若多個彈框各拷，要新建一個彈框基類進(jìn)行控制刁绒，滿足易擴(kuò)展、復(fù)用性強(qiáng)
（3）彈框設(shè)計：如果存在多個彈框烤黍，需要設(shè)計彈框積累知市，設(shè)計彈框需要滿足易擴(kuò)展、復(fù)用性強(qiáng)
2蚊荣、視覺構(gòu)建
（1）后端在開發(fā)接口初狰，前端可以做視覺構(gòu)建莫杈、構(gòu)建完成后可根據(jù)接口文檔互例，通過mock數(shù)據(jù)方式調(diào)試接口，（2）同時書寫前端邏輯筝闹；后端完成接口開發(fā)后媳叨，可以進(jìn)行使用聯(lián)調(diào)。
（3）像素級還原設(shè)計稿：使用snipaste截圖关顷，F(xiàn)1截圖糊秆，F(xiàn)2貼圖，調(diào)整貼圖的透明度為50%议双，將貼圖與前端頁面進(jìn)行像素級比對痘番。
（4）及時溝通：開發(fā)視覺過程中及時與UI設(shè)計師溝通，進(jìn)行樣式調(diào)整平痰，防止后期返工汞舱。
3、業(yè)務(wù)邏輯
（1）使用思維導(dǎo)圖宗雇，梳理業(yè)務(wù)邏輯昂芜，再著手寫代碼，仔細(xì)思考開發(fā)中的可能關(guān)聯(lián)的模塊赔蒲。思維導(dǎo)圖方便理清邏輯泌神，事后復(fù)盤，高效給他人講解（多模塊協(xié)同開發(fā)舞虱、與領(lǐng)導(dǎo)講述開發(fā)思路）欢际，這種思想比較重要。
（2）調(diào)用接口時矾兜，要明確前端自己的安全邊界幼苛，比如接口字段異常或者接口返回異常焕刮，前端要有自己的降級措施舶沿，如頁面如何呈現(xiàn)墙杯。不能完全依賴和信任字段，不能讓頁面白屏括荡。交互異常高镐，控制臺報錯等異常場景
（3）除了完成產(chǎn)品要求的業(yè)務(wù)邏輯外，還要時刻考慮異常流的設(shè)計和容災(zāi)畸冲，簡單來說就代碼執(zhí)行的異常場景下嫉髓，邏輯是否還能繼續(xù)執(zhí)行，如try-catch-finaly邑闲，promise.then.catch.finaly 等機(jī)制算行，保證頁面正常加載
（4）如果有PRD文檔，那么開發(fā)時一定要嚴(yán)格按照文檔進(jìn)行開發(fā)苫耸，看看是否有遺漏州邢。
4、代碼提交
（1）先git pull 再git commit褪子、git push量淌，減少代碼沖突
（2）commit粒度要細(xì)、注釋寫清楚嫌褪、方便后續(xù)問題定位與復(fù)盤
（3）commit之前要diff代碼呀枢，確保每一次修改是已知的，而沒有錯提交代碼
（4）commit message常用格式：feat笼痛、fix裙秋、docs、merge缨伊，合并代碼時遇到?jīng)_突要及時與對應(yīng)同事溝通后提交摘刑，不要盲目自信的提交代碼
（5）生產(chǎn)環(huán)境去掉console.log/debugger等多余代碼
四、產(chǎn)品體驗
（1）App或者小程序端一定要真機(jī)體驗倘核，同事對比IOS和Android對比體驗
（2）體驗時記錄各種todoList
需求待確認(rèn)list：一些小的泣侮、風(fēng)險可控的需求點，可以在體驗階段紧唱，幾種向產(chǎn)品童鞋提出
開發(fā)未完成list：有哪些尚未完成的部分活尊，需要和產(chǎn)品童鞋交代清楚
已知bugList
體驗問題 list：邊體驗邊記錄產(chǎn)品反饋的問題，并稍后同步給測試童鞋
依賴項list：接口漏益、視覺切圖蛹锰、真實的測試環(huán)境等
五、代碼評審绰疤、代碼review
代碼review
（1）也稱codeReview铜犬，也叫CR，是一種通過復(fù)查代碼來提高代碼質(zhì)量的過程，一次 CR 可以是一次 Commit癣猾，也可以是一次 Merge Request敛劝。
（2）代碼review可以在測試期間進(jìn)行
review順序 業(yè)務(wù)核心邏輯、編碼規(guī)范纷宇、關(guān)鍵位置（容易踩坑的地方夸盟、需要注釋詳細(xì)）、系統(tǒng)保障（監(jiān)控像捶、容災(zāi)上陕、報錯等場景）、系統(tǒng)安全和風(fēng)險（是否有xss攻擊等）拓春，用戶體驗
六释簿、測試環(huán)節(jié)
（1）建議加強(qiáng)自測質(zhì)量、減少由于開發(fā)人員自測覆蓋不全的問題
（2）整理自測硼莽、測試庶溶、發(fā)布時需要的主流程checkList，每次迭代都能用上
七沉删、發(fā)布環(huán)節(jié)
發(fā)布方案
發(fā)布順序：一般是先發(fā)后端渐尿，再發(fā)前端
依賴項是否準(zhǔn)備就緒：配置的數(shù)據(jù)醉途、配置項等
是否會對線上業(yè)務(wù)矾瑰、線上數(shù)據(jù)造成影響
本地環(huán)境、dev環(huán)境隘擎、gamma環(huán)境殴穴，均要做好驗證。
回退機(jī)制
發(fā)布 checkList
參考
