前端傳來的數(shù)據(jù)不要直接用
前端傳來的數(shù)據(jù)不要直接用！
前端傳來的數(shù)據(jù)不要直接用！
前端傳來的數(shù)據(jù)不要直接用！
一定要自己驗(yàn)證下數(shù)據(jù)的準(zhǔn)確性
否則一旦被有心人抓包篡改數(shù)據(jù)塔橡，嚴(yán)重的話可以讓公司破產(chǎn)
我有個(gè)朋友最近被爆出來一個(gè)驚天大BUG
他在下單階段竟然直接用前端傳來的price作為訂單的價(jià)格，一開始還能正常運(yùn)行霜第，直到某天葛家，客服發(fā)現(xiàn)后臺(tái)出現(xiàn)了大量0元訂單.....
不要完全相信測(cè)試
普通的測(cè)試一般就做做業(yè)務(wù)上的測(cè)試，能用就行了泌类，他們只關(guān)心表面結(jié)果惦银，幾乎沒有測(cè)試會(huì)在乎你會(huì)不會(huì)有安全漏洞，什么sql末誓，什么性能問題，就算是高級(jí)測(cè)試书蚪，他們會(huì)堂而皇之的告訴你喇澡，他們是功能測(cè)試，會(huì)看日志的測(cè)試都能讓我覺得很不同殊校，很感動(dòng)晴玖。
改變別人太難了，還是改變自己吧，凡事自己想清楚呕屎，不要指望著別人會(huì)幫你什么让簿。還是自己態(tài)度的問題。畢竟出了事故秀睛，還是開發(fā)背大鍋尔当。
代碼精度問題
var_dump(0.7+0.1);//0.8
var_dump(0.8==0.7+0.1);//false
var_dump(sprintf('%.20f',0.7+0.1));//0.79999999999999993339
var_dump(sprintf('%.20f',bcadd(0.7,0.1,2)));//0.80000000000000004441
var_dump(sprintf('%.20f',0.8));//0.80000000000000004441
涉及小數(shù)運(yùn)算時(shí)，記得用bc函數(shù)蹂安，否則因?yàn)樾?shù)轉(zhuǎn)二進(jìn)制丟失精度的問題椭迎，出現(xiàn)各種奇葩bug的時(shí)候可別找半天找不到哦。而且這種精度問題不是所有數(shù)字都會(huì)發(fā)生的田盈，所以在測(cè)試環(huán)境可能根本不會(huì)遇到畜号，但是一上線，用戶一試一個(gè)準(zhǔn)允瞧。
總結(jié)：不要為了圖一時(shí)方便偷懶简软，不然等問題爆出來的時(shí)候還有誰比你更尷尬呢？嚴(yán)格的代碼里驗(yàn)證的代碼可能比真正的邏輯代碼還多述暂。不要總抱著能用就行的僥幸心理痹升，一旦東窗事發(fā)，想不提桶都難了贸典。驗(yàn)證一下數(shù)據(jù)能有多復(fù)雜有多難视卢？其實(shí)都是我們工作態(tài)度的問題，態(tài)度決定細(xì)節(jié)廊驼，細(xì)節(jié)決定你能有多少成就据过。
上線時(shí)竟然把前端忘了？
有兩個(gè)需求由于排期不明確妒挎，我也是突然得知今天就要走緊急上線绳锅。在上線時(shí)忘記通知前端同學(xué)了，結(jié)果嗯酝掩，可想而知鳞芙，場面還是比較尷尬。還好這玩意沒啥人用期虾，不然妥妥的挨一頓批原朝。
這咋說呢，本來就沒有明確的責(zé)任人镶苞，再加上上線時(shí)間本來就沒規(guī)定喳坠，出現(xiàn)這種情況也不足未奇。誰來做這個(gè)主動(dòng)與N方周旋的人呢茂蚓？還是取決于個(gè)人態(tài)度壕鹉。
