老話說，工欲善其事，必先利其器。
那麼，作為編程人員，你都用過哪些“兵器”呢？你的”兵器“夠”鋒利”嗎？
近期，有很多新朋友問，都有什麼畫流程圖的工具，給推薦推薦？
索性，就靜下來，好好梳理一下，從事編程十餘載中，用到了哪些工具？嘗試彙總分享給大家，希望對大家有所幫助。
Tips：
1. 考慮方便收藏，文末已經把文中提到的工具整理成圖。
2. 曾經用過的，以及目前在用的工具梳理，勢必會有適合你的款。
01. 設計原型
代碼寫久了，也會客串一下產品的角色，畫點原型。按照接觸時間，主要分享兩款。
一款是安裝後，便可進行設計原型的 Axure RP。
（Axure RP 效果圖，圖片來源於官網）
另一款是在線進行產品原型設計的磨刀（沒錯，名稱就叫磨刀），是當下遠程辦公的好幫手。
（磨刀效果圖）
02. 制定計劃
產品同事把產品原型畫完，往往會喊上開發的兄弟們，組會進行評審，待產品需求評審完，就要進行大致的排期，而排期的工具也有很多，在這裡主要提我用過的兩款。
之前，用的比較多的一款是 Microsoft Project，排出來的效果，個人感覺整體是比較正式的。
（Project 計劃效果圖）
現在，經常用的是 Microsoft Excel（沒錯，就是 excel 表格），用 Excel 排完之後，團隊的兄弟幾乎都能看，無需安裝其它軟件，主要是圖個方便。
（ Excel 簡易的排期效果圖，複雜的要比這複雜的多）
03. 流程設計
當產品需求明確，大致週期也定了，按照規範化的流程，那便是進入設計階段，此時往往會用到畫圖工具，在這裡，按照我用的時間先後順序，羅列幾款出來，希望對你有用。
第一款是 Office Visio，此款是我用的最早的一款，而且畫起圖來也很簡單，清晰明瞭。只要我用 Windows 系統，都會用 Visio 進行畫架構圖以及詳細業務流程圖，已經形成了肌肉反應。
有些時候，也會用一款超好用的 UML 畫圖工具 StarUML，來畫畫類圖，時序圖等等。
（StarUML 效果圖，來源於官網）
不過，自從切換成蘋果電腦，開始使用 ProcessOn 進行在線畫圖，無需安裝，打開鏈接就能用，而且各種圖都支持。無論是工作，還是平時寫文章做分享時，經常會用到這款工具。從以往分享的文章中摘兩張醜圖，看看效果。
（ProcessOn 效果圖，來源於以往分享“矛與盾，如何造好系統的盾”）
（ProcessOn 效果圖，來源於以往分享“監控實戰Prometheus+Grafana”）
但是，倘若在 ProcessOn 不花 Money 的情況下，能畫圖的張數是有限制，所以偶爾也會用 draw.io，它也是一個強大簡潔的在線的繪圖工具，用它來湊兩張圖也未嘗不可。
（draw.io 效果圖，來源於以往分享“這些技術輪子，讓監控落地成為現實”）
04. 代碼研發
當業務流程設計圖畫好時，喊上產品汪，組會評審一下，看看需求理解的有沒有問題，若是沒啥問題，那就進入了編碼研發階段。
作為一枚 Java 程序員，編程工具從記事本、Editplus、JCreator、Eclipse 到現在用的最多的 IntelliJ IDEA。
業務需求實現過程中，很多場景需要進行三方系統對接，有時三方會給你一個調用的 jar 包。但是有些時候怎麼調，都不通，就想知道 jar 包裡面都寫了點啥？在此，推薦一款用的最多的反編譯工具 JD-GUI。
在代碼研發過程中，代碼質量貫穿始終。之前我都會採用 Eclipse 集成 FindBugs 的插件進行掃描一下，看看有沒有潛在的 Bug，不過現在 IDEA 的代碼規約校驗插件（阿里開發規約插件）已經很好的滿足了此需求。
在這裡，還是要提一下 SonarQuable，它是一個用於代碼質量管理的開源平臺，也有助於幫你進行代碼審查，提升代碼質量。
（SonarQuable 效果圖）
當代碼研發差不多時，不可避免的就是充分的自測，那麼如何對自己寫的接口進行請求調試呢？
一種方式寫各種 Test 進行模擬發包，一段測試代碼，反反覆覆修改參數；另外一種方式，避免反覆修改代碼，用 Postman 模擬發請求包，而且能把歷史訪問都存起來，超級好用。
（Postman 效果圖）
敢問，你們開發過程，代碼版本管理工具都用啥？我用過的代碼版本管理工具，主要是 SVN 和 Git，但是逐漸開始都轉向 Git。
另外，開發過程中，往往會進行合併代碼，衝突時需要進行找不同，用 SVN 和 Git 這些代碼版本管理工具可以做到，不過有些時候，緊急使用時，為了儘快定位不同，也會用 Beyond Compare 直接比較。
（Beyond Compare 效果圖）
05. 代碼評審
代碼研發完成，冒煙自測沒啥問題，接下來就會組織會議，進行代碼評審。
代碼評審的主要目的，在我看來主要是兩方面。第一：看看需求理解實現上有沒有問題；第二：看看代碼實現上有沒有潛在的 Bug。
代碼評審時，為了記錄 Review 中的問題，現在用的最多的是 Excel。
（Review記錄單，效果圖，僅供參考）
06. 提交測試
當代碼研發完成，經過代碼評審後，進行代碼反覆調優，再經過充分的自測與聯調，當信心倍增的時候就可以提交測試啦。
經歷過的小作坊，打個包用 Xshell 或 SecureCRT 放到測試環境，發個郵件或者在 Jira 上通知一下測試組就 ok 啦。
經歷過的大作坊，首先用 Jenkins 進行編譯發佈版本，部署到測試環境；若測試人員發現 Bug，會把 Bug 提到 Jira 上，研發人員修復完 Bug，再用 Jenkins 打包發版，這樣每次提交測試的版本號都會 +1。這麼一來，可以衡量開發人員的開發質量，若是提測版本過高，那肯定是風險係數稍高一些，稍微嚴格一點，會根據測試版本來算績效呦。
（Jira 效果圖）
經歷過的由各公司抽技術人員，臨時組成項目組去幹一件大事，用過一款在線協作工具 Teambition，簡單拖拽就能完成任務分配、認領，同時也非常適合測試提 Bug，研發人員進行認領 Bug 進行修復。
（Teambition 效果圖）
07. 進行上線
當測試組完成測試時，會發送測試報告，當研發人員看到測試報告時，就可以發起上線申請啦。不過在上線前會與運維同事一起制定上線計劃，制定計劃的工具簡單點的是 Excel，稍微正規點就在 Jira 上發起上線申請時，把上線注意事項寫清楚，然後線下再溝通，確認無誤再安排進行上線。
08. 寫在最後
從事編程十多年，其中那些經常打交道的工具，本次就梳理這兒，希望你們能夠喜歡。
最後，用 XMind 思維導圖工具給大家彙總一下，便於各位收藏。
都知道，要使車子走得快，就得給輪子勤上油，但前提是要給車子裝好輪子。
效率，是做好工作的靈魂。希望分享的這些工具，這些利器都能助你提高效率，有限的時間內，實現更多的價值。
閱讀更多 一猿小講 的文章
