對(duì)于一個(gè)軟件開發(fā)工程師來說，技術(shù)是很重要的一項(xiàng)衡量指標(biāo)错蝴；但是“技術(shù)”這個(gè)詞的含義呜笑，自己之前一直存在著很大誤解或是片面認(rèn)識(shí)

通常意義上我們所說的技術(shù)，一般指技能殖熟，這點(diǎn)對(duì)于開發(fā)工程師來說局待，也就是：‘掌握語言的語法，某種定義方法和類庫調(diào)用的方式菱属，引用機(jī)制的了解等等钳榨；熟練的做到這些，很多時(shí)候你就可以認(rèn)為自己是一個(gè)稱職的工程師了纽门；但是薛耻，對(duì)于一個(gè)優(yōu)秀的工程師來說，技術(shù)的定義卻遠(yuǎn)不止如此赏陵，甚至饼齿，以上的這些，都還不是最重要的

剛到一家新的公司蝙搔，今天下午組長讓我處理整合一個(gè)圖片社區(qū)模塊缕溉，涉及的業(yè)務(wù)包括用戶資料修改，賬戶提現(xiàn)充值以及圖集上傳加載排序吃型，原有的代碼中有很多BUG以及不合理的地方证鸥，需要修復(fù)整改，具體如下

?1. 賬戶提現(xiàn)時(shí)? 金額需要驗(yàn)證勤晚，提現(xiàn)金額大于余額時(shí)不得提交

2. 社區(qū)用戶的圖集列表按照點(diǎn)贊數(shù)從高到低順序排列枉层，推薦列表中顯示前3條

任務(wù)1拿到手時(shí)我的做法： 點(diǎn)擊提現(xiàn)按鈕時(shí)修改提現(xiàn)頁面的后臺(tái)提交方法，根據(jù)用戶名獲取用戶賬戶余額赐写，和輸入框傳入的余額做對(duì)比返干，如果超出，返回錯(cuò)誤提示

組長的做法：前臺(tái)增加驗(yàn)證腳本血淌，加載時(shí)提現(xiàn)按鈕為不可用灰色狀態(tài)，通過輸入框控件判斷輸入的值和已經(jīng)載入的值余額之差，只有差值是正整數(shù)的時(shí)候悠夯，才打開提現(xiàn)按鈕癌淮，在打開按鈕的同時(shí)，觸發(fā)后臺(tái)提交方法中的GUIDKEY驗(yàn)證碼沦补，將其賦值乳蓄，使方法體能夠執(zhí)行下一步（防止從前臺(tái)頁面繞過驗(yàn)證）。

任務(wù)2我一拿到夕膀，頓時(shí)間不知道該怎么入手虚倒，后來想了想，在后臺(tái)寫了一個(gè)方法：獲取所有社區(qū)用戶列表产舞，遍歷每個(gè)人的圖集魂奥，將這些圖集按照點(diǎn)贊數(shù) 從高到底排列，裝入一個(gè)集合當(dāng)中易猫，取出前三條加載到推薦列表

組長的做法：組長拿到手耻煤，只看了一眼數(shù)據(jù)庫，就說准颓，這個(gè)表結(jié)構(gòu)不行哈蝇，必須重新建三張表，要把圖片社區(qū)和攝影師上傳圖集分離開來攘已，為的是防止同時(shí)具有攝影師和社區(qū)用戶角色的使用者炮赦，在上傳圖片時(shí)，在圖像表中傳入一條攝影師用戶名為空的圖片記錄样勃。因?yàn)樵谶@個(gè)系統(tǒng)里吠勘，不管是攝影師還是社區(qū)用戶，上傳圖片用的BASE類是同一個(gè)彤灶，也就是不管從哪個(gè)入口上傳圖片看幼，它們生成的圖片編碼是同一個(gè)。兩種不同性質(zhì)的圖片幌陕，在一張表里诵姜，只用type類型子段控制，在上傳者只有一種用戶角色的時(shí)候搏熄，是沒問題的棚唆，但是，假若上傳者同時(shí)具備了兩種或是多種身份心例，因?yàn)樘峤蝗肟谔幍挠脩裘畔⒑陀脩艚巧壎ㄏ瑁蛔鲆淮悟?yàn)證寫入一次，所以止后，在一個(gè)用戶同時(shí)具有兩種身份的情況下瞎惫，有一條數(shù)據(jù)必然是缺失用戶名的

有些東西的差別看上去是技術(shù)的差別溜腐，從更深層次的角度來說，卻是底層思維方式的差異：從純技術(shù)角度來說瓜喇，我的做法簡便易思考挺益，組長的做法略微復(fù)雜且不一下子容易想到；組長的做法可以有效的防止數(shù)據(jù)庫的二次調(diào)用（尤其涉及賬戶金額這種安全性要求高的屬性字段）乘寒，我的做法具有一定的被攻擊風(fēng)險(xiǎn)（無限提交）和安全性風(fēng)險(xiǎn)（金額這個(gè)值望众，查了兩次數(shù)據(jù)庫） 這只是表面上的原因

? 從底層思維模式深挖，可以看到：1.組長的開發(fā)是面向用戶對(duì)象伞辛，以用戶需求和習(xí)慣為導(dǎo)向的開發(fā)思維：用戶拿到這個(gè)東西之后烂翰，有可能會(huì)怎么用，有可能會(huì)做什么操作蚤氏，這些操作可能會(huì)出現(xiàn)怎樣的問題甘耿？ 這些問題應(yīng)該怎樣避免和預(yù)防？ 用戶在使用過程中瞧捌，還有可能產(chǎn)生怎樣的狀況和新的需求棵里，應(yīng)該對(duì)此采用怎樣的應(yīng)對(duì)策略……? 而我的開發(fā)，是面向開發(fā)本身姐呐，以自身編程模式習(xí)慣為導(dǎo)向的開發(fā)思維： 這個(gè)問題??按我的經(jīng)驗(yàn)和理解殿怜，?我覺得 應(yīng)該怎么處理…? 2.組長面對(duì)一個(gè)問題，是站在整個(gè)項(xiàng)目的層面上來考慮這個(gè)問題： 這個(gè)寫法改下去之后曙砂，其他哪里相關(guān)聯(lián)的地方還有用到头谜？?它會(huì)對(duì)整個(gè)項(xiàng)目產(chǎn)生哪些，產(chǎn)生多大影響鸠澈？ ?它在將來做拓展和維護(hù)時(shí)有多大的難度柱告？？?? 而我面對(duì)一個(gè)問題笑陈，一般就是想：如何解決當(dāng)下的問題际度，如何讓功能正常運(yùn)轉(zhuǎn)?？涵妥？??? ?這兩種思維方式的差異? 導(dǎo)致了同一件事情乖菱，完成的效果?? 大不相同

思維模式的優(yōu)與劣，比代碼本身更重要也更值得每個(gè)開發(fā)人員重視