拥有这些工具，还怕干不出好活？
老话说，工欲善其事，必先利其器。
那么，作为编程人员，你都用过哪些“兵器”呢？你的”兵器“够”锋利”吗？
近期，有很多新朋友问，都有什么画流程图的工具，给推荐推荐？
索性，就静下来，好好梳理一下，从事编程 十余载中 ，用到了哪些工具？尝试汇总分享给大家，希望对大家有所帮助。
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 思维导图工具给大家汇总一下，便于各位收藏。
都知道，要使车子走得快，就得给轮子勤上油，但前提是要给车子装好轮子。
效率，是做好工作的灵魂。 希望分享的这些工具，这些利器都能助你提高效率，有限的时间内，实现更多的价值。
推荐阅读：
About The Author
