面向需求編程才是常態，聊聊我的經歷
這篇文章中的內容在幾年前曾經發過，之所以今天整理一下再發一次，是因為最近不少有人問我類似的問題：
工作無聊，主要是增刪改查。
現有項目很爛，在上面修修補補
沒有從事過高并發，大流量的項目，簡歷沒有亮點......
想想我自己這10多年的開發經歷，主要做企業應用開發，業務復雜，業務邏輯都不講邏輯，要求穩定性，很少有機會去設計高并發，大流量的項目。連從頭開始一個項目的機會都不多，大部分時間都是在現有項目的基礎上面向業務，面向需求做開發。
我想這才是中國軟件業的常態吧!在這種情況下，抱怨沒用，跳個槽估計也差不多，還不如自己多思考，看看在工作中怎么搞點事情，提升自己的價值，我舉幾個我自己的案例。
01
我原來做過一段稅務系統的開發，公司有一個自研的平臺，包括了表單設計和工作流設計，把底層的Java EE都給封裝起來了，在上面做開發，讓人很絕望，什么底層都接觸不到。
實現了一些稅務的具體操作以后，我就慢慢的發現了這些操作的共性，但就是不知道該怎么描述出來, 思考了很久也沒有頭緒。
有一天騎自行車回家的路上， 突然間就“頓悟”了：奧，這些稅務操作其實就是點(x,y)在二維坐標系下的移動 !
第二天回去就把這個東西整理成文檔， 并且把代碼也做了改寫，因為有理論指導，代碼變的特別簡單，很健壯--- 之后這就成為我簡歷中的亮點了。
一個月后有個老外來北京， 看到了我抽象出來的關于稅務的操作，吃驚不已， 一直在問：這是你搞出來的嗎?
02
使用那個自研平臺的工作流開發出來的程序，必須得部署到app server中才能測試，并且只能手工測試，費時費力，我當時就想能不能像Junit那樣寫好腳本，然后自動化地去測試啊，把這個想法給Leader說了，他非常支持，就按照這個想法去實現， 后來發現和數據庫緊密耦合，難以完整實現。雖然如此，這也是我工作中的亮點了。
值得一提的是，這些亮點最終都指向了業務目標：更好更快地實現需求，而不僅僅是show 技術。技術是為業務服務的，仔細想想公司的業務，流程，用的工具，從技術角度好好想想，是能發掘出東西來的。
03
我曾經在一個研究所工作過幾年，雖然有開發任務，但是很少有進度的壓力， 在那里是很清閑的。
當時在做一個小數據集成項目，需求明確， 系統也不復雜 ，開發著也挺無趣的， 我就琢磨著能不能搞點別的事情， 后來就發現了敏捷軟件開發， 對里邊的實踐非常認同，于是就學習了單元測試，TDD(測試驅動開發)，結對編程，用戶故事 等實踐， 在項目中也嘗試著做了應用， 尤其是TDD, 的確不錯。
再后來就進了IBM， 沒想到幾年前種下的種子開花結果了。IBM 也開始提倡敏捷轉型，于是我幾年前的積累就用上了， 不僅僅幫助本團隊做了敏捷轉型， 還走出去幫助工行、農行、華為、鼎橋等公司做了敏捷咨詢， 不但進一步提升了水平， 也為自己的簡歷增光不少。
04
剛進IBM的時候做了一個極其簡單的小項目， 就是用戶登錄， 然后顯示一個Applet (沒錯，就是上古時代的Applet)， 這個Applet 基于IBM 的Samtime ， 實現了讓用戶和公司的客服實時通信功能， 類似于QQ, 但是只能發文本消息。
后來由于Sametime升級， Applet也要更新， 我就接觸了Applet的源碼，做了改動， 一切看起來沒什么大不了的， 很正常。
唯一的不同是我多做了一點工作， 深入的研究了Sametime 的SDK, 帶來了兩個重要的好處：
(1) 在developerWorks上發表了第一篇中文的sametime sdk文章，后來形成了一個系列。
這一系列文章被很多人看到， 并且直到6，7年以后，我都離開IBM了，還有人發信問我相關的問題， 影響力應該是很深遠的。
(2) 徹底理解了基于事件的編程模型 ， 因為Sametime SDK的編程就是基于事件的， 等到幾年后Node.js 開始出現并且流行開來時， 我發現它和當年的Sametime 編程模型幾乎是一樣的，都是異步的、事件驅動的， 就像喝涼水一樣輕松掌握了， 后來寫了一篇文章《Node.js：我只需要一個店小二》
看完了我的故事，也許你有所觸動，像那些高并發、大流量的項目不是每個人都能接觸到的，面向需求編程才是常態。
在開發過程中，建立對整個系統端到端的理解，在業務、流程、工具等領域多想一想，肯定能發現讓自己閃光的、有價值的點。
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
