我有壹個觀點，並且我認為這是無須詳細去解釋的，那就是：
每壹個程序員，都得學會對自己的代碼做性能測試
當然，性能測試的工具並不壹定是JMeter，但以當前開源框架來說，我認為它是最好的選擇。
從本周開始，在講編碼之道的同時，我將同時每周講壹篇技術，也就是編碼之術。
做為壹個優秀的程序員，道與術同等重要，不可偏廢。
編碼之術的第壹個系列就是： 寫給程序員的JMeter教程
要記住壹個原則，性能只是技術價值中的壹個維度，不要說業務價值，光是從技術價值上來考量，性能也並不是最重要的，甚至得排在很多點後面，比如可維護性。
我壹向認為： 可維護性是最重要的技術價值
因為性能是可以用硬件來彌補的，但可維護性差就不是彌補這麽簡單的事了，為可維護性付出的代價會遠高於提升下硬件或在集群中多加個服務來解決性能問題的代價，硬件永遠是越來越便宜的。
作為程序員，壹定要有這種認知。
當然，這不代表性能是可以輕視或者忽略的，關於如何對待性能這個技術點，我的觀點是：
在不犧牲可維護性的前提下，努力做到性能最好
相比其它維度的測試工作，性能測試稍顯尷尬。
性能這個事情，不理解技術，沒有實際編碼過，坦率地講要做好並不容易。而理解編碼或編碼過的測試人員其實是少數。因此，僅有此部分的測試人員能夠去做性能測試，而大多數測試人員在性能測試方面始終有點難以著手與深入。
好吧，大多數程序員可能並不認為性能測試是需要自己動手的壹個事情。這顯然並不是壹個正確的認知。
我認為，程序員是非常有必要自己做性能測試的，它應該是壹個程序員的必備技能之壹。
有誰會比妳更熟悉妳自己編程的思路與實現？
程序員的自我性能測試應該是第壹道防火墻，無論後面測試團隊會如何進行性能測試，本身妳自己要先給自己把這壹關給過了先。
原因我認為有以下幾點：
1. 專業性
其實無論是單元測試，還是性能測試，程序員理當自己去做這些事，自己寫的代碼自己要保障它的質量，這應該是專業性的壹種體現。我們想做好壹個程序員，那對專業性的追求就必不可少。
2. 發現隱蔽的錯誤
很多功能，如果不在大並發下運行，可能壹切正常。但這並不意味著它就真的 正常 ，我們要明白我們的服務是在網上運行，它並不是壹個人在使用。大並發下會出現非常多妳意料不到的問題與Bug。
3. 自己最清楚自己的邏輯
別人測試妳的代碼，永遠不如妳自己清楚，妳知道自己是怎麽實現的，當然就更清楚在性能上如何測試它更好。
4. 這不是壹件很難的事
其實技術整體發展方向是越來越易於使用，不斷地有更好的工具出現。我要講的JMeter就是壹個足夠簡單且易於使用的工具，使用JMeter絕大部分情況下，只需要用圖形界面就能搞定，極少數情況下才需要編寫腳本。
5. 它更節省時間
好吧，我知道這聽起來有點誇張或不可思議，很多人理所當然地會認為這會花費更多的時間。
其實這個點與單元測試是壹樣的，凡是認為單元測試或性能測試會延長編碼時間的程序員，這些想法都屬於想當然，他們可能從未嘗試過。
實際上，妳不做這些事，未來妳會在其它方面為它付出更多的時間。而只有做這些事，才有可能保障代碼的可維護性。
當然，現在我們都盡量使用開源的工具，因為很多開源的工具足夠強大並且是免費的。
在性能測試領域，當然最專業的要屬LoadRunner這個工具了，但顯然這個太重了，還只支持Windows。
事實上，很多互聯網公司主流都是使用了更輕，更易於使用的JMeter。
且不論JMeter和LoadRunner孰優孰劣，對於程序員來說，選擇JMeter肯定是當下最正確的選擇。
所以，從現在開始妳可以跟隨我的腳步來學習與使用JMeter吧。其實它足夠簡單，妳並不需要花費太多的時間。
下壹篇，寫給程序員的JMeter教程（壹）：理解性能測試中的性能指標