程序员拥有这些工具，还怕干不出好活？

Posted 2020-11-27 socoool

老话说，工欲善其事，必先利其器。

那么，作为编程人员，你都用过哪些“兵器”呢？你的”兵器“够”锋利”吗？

近期，有很多新朋友问，都有什么画流程图的工具，给推荐推荐？

索性，就静下来，好好梳理一下，从事编程十余载中，用到了哪些工具？尝试汇总分享给大家，希望对大家有所帮助。

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 思维导图工具给大家汇总一下，便于各位收藏。

都知道，要使车子走得快，就得给轮子勤上油，但前提是要给车子装好轮子。

效率，是做好工作的灵魂。希望分享的这些工具，这些利器都能助你提高效率，有限的时间内，实现更多的价值。