今天突然想起了幾句話，由此聯想到了Java Servlet中的get和post方法。
對於Servlet其實自己也算是清門熟路了，get和post這是http協議的兩種方法,而在servlet開發中，以doGet()和doPost()分別處理get和post方法.這兩個方法有什麼區別呢。
get方式會透過url傳送表單資料，這是一種顯式的資料傳輸，而對於post而言，表單資料會透過http協議的header來傳送表單資料，而且支援的資料傳輸長度也要多，當然直觀的感受就是瀏覽的url不會變化，從安全性上來說，post方式也要好很多。當然也不能一巴掌拍死，兩者都有一定的適用場景，在此也不再贅述。
     而在生活中，其實我們很多時候碰到的都是get這種型別的人和朋友，最讓我有直觀感受的是，我之前的公司會和不同國家的人來打交道，比如我有一個工具軟體的問題，如果身邊沒有同事能幫上忙的話，我一般都是透過lync來搜尋相關的同事，如果問國家A的同事，因為彼此也不熟悉，一般情況下都是帶著試探的口吻來諮詢，而大多數情況下他們都會選擇直接的拒絕，比如我不知道，這個不是我所在的專案，我現在有些事情比較忙等，後來我似乎也習慣了這種情況，如果對方能夠幫助我，我還會內心帶著一絲的驚奇。而同樣的問題，我在碰到了國家B的同事，大多數的情況下，他們都會比較熱情的接受我，然後仔細聽我的問題，如果不清楚，確實不知道，他也會坦誠告知，但是不同的一點是，他們會給我一些額外的線索和資訊，比如讓我找某某團隊的某個同事，他應該知道。如果他不太確定，還會幫我聯絡其他的同事來協助解決，這個時候我的內心其實是很溫暖的，哪怕沒有解決，哪怕沒有得到應有的幫助，同樣這位同事如果後面有需要我幫忙的地方，我肯定會盡可能多的幫助到他。這也算是一種禮尚往來吧。所以我還是比較喜歡post型的同事。
     當然post和get方式有時候也是互相影響的，這也體現了我們對待工作的一些態度。對於工作，有些同事能夠很清晰的設定計劃和目標，然後向著這個方向來努力，有些同事則會明顯懶散的多，每天都在那種懵懵懂懂之中，大家都坐在那裡工作，可能get型工作方式的同事每天干了什麼，透過工作計劃和溝通都能夠很清楚知道，而有些同事再這方面就會欠缺很多，本來負責就幹事情A,結果因為其它的事情打斷，去處理事情B,當事情A已經被耽擱了很多天以後，才突然發現自己原來已經忘了有這麼回事，而且大家都不知道他到底幹了些什麼，不知道是工作的重複性過高，還是其它的個人原因。這個時候從工作態度來說，我喜歡get型的同事。
     我對於工作中的問題處理的態度，也會有get,post的差別，get型的人一般都是看待問題很實際，解決了問題，或者知道了問題，點到為止，不會進一步追究分析問題的根本原因，如果碰到了疑難問題A,那麼在他的知識庫中是需要一個獨門的攻略來處理的，而後來有了問題B，由於沒有找到問題的原因和本質，只是根據簡單的現象來處理和歸納，這個時候獨門秘籍越多，其實還真不是好事情，因為那些看似奇怪的問題，肯定背後都有著更深層次的原因，而post型的同事可能對於問題不侷限與此，他們會在這個基礎上進一步歸類總結，最終找到問題的原因，然後進一步引申，分析出更深層次的原因總結，至少在問題的層次上，他解決的不是一個問題，而是一類問題。當然在其他同事來看，他只是在處理一個簡單的問題，當然和其他同事處理的結果一樣，問題都得到了解決，但是兩者的境界完全不同，這個時候我喜歡post型的同事。
    而對於問題，其實get,post也是相互作用，比如你要升級一個系統，可能對於開發，運維的同事來說，對他們又沒有什麼實質性的福利和改進，他們就會帶著一種牴觸的情緒，這個溝通都會是被動的，而更深層次來說，如果出了問題，這也是一件吃力不討好的事情，所以他們也不大願意妥協，而同樣的，如果他們有類似的問題需要我來配合，我也會用get型的態度來回應，也就是能不動就不動，能不改就不改，因為對我也沒直接的好處，而對於post型的同事，這種情況下就會帶著一種友情支援的問題，有問題了大家一起扛，本身處理問題不是互相推諉，而是下決心需要把事情做好，這才是終極目標。所以在這種情況下，我還是喜歡post型的同事。
   所以對於get,post型，有時候是一種矛盾的態度，而我的主要觀點就是對事不對人，問題解決了皆大歡迎，出了問題也能夠緊密配合，大家都是一個身上的螞蚱，還老是分清彼此，互相推諉，溝通成本太高，工作效率低下，對get型，post型的人都沒有好處。

我們身邊的get,post型的人

相關文章