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

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

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

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

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

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

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

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

組長的做法：組長拿到手，只看了一眼數(shù)據(jù)庫，就說，這個表結(jié)構(gòu)不行，必須重新建三張表，要把圖片社區(qū)和攝影師上傳圖集分離開來，為的是防止同時具有攝影師和社區(qū)用戶角色的使用者，在上傳圖片時，在圖像表中傳入一條攝影師用戶名為空的圖片記錄。因為在這個系統(tǒng)里，不管是攝影師還是社區(qū)用戶，上傳圖片用的BASE類是同一個，也就是不管從哪個入口上傳圖片，它們生成的圖片編碼是同一個。兩種不同性質(zhì)的圖片，在一張表里，只用type類型子段控制，在上傳者只有一種用戶角色的時候，是沒問題的，但是，假若上傳者同時具備了兩種或是多種身份，因為提交入口處的用戶名信息和用戶角色綁定，只做一次驗證寫入一次，所以，在一個用戶同時具有兩種身份的情況下，有一條數(shù)據(jù)必然是缺失用戶名的

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

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

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