作者
黄峰达，CSDN博客专家Phodal
责编
唐小引
头图
作者绘制并授权CSDN使用
过去的几年里，我一直在打造各式各样的编程相关的工具。这些工具有的是用于指导软件开发工作，有的是用来进行编程学习，还有的纯粹是为了提升技术而写的。在我写了越来越多的工具，接触了越来越多的工具思路之后。我便想写一篇文章，用于记录一下过程中发生的一些变化。
一、如何打造工具？
如果你拥有广泛的技术栈知识，还有相对充裕的时间，那么加上一些激情，你就能写出一个不是那么差的工具。
工具的技术栈
在我短短十几年的编程生涯中，我尝试了不同的层级技术栈，大抵也是了解怎么从底层到顶层做各种工具。连接物理世界的工具：
纯嵌入式系统编程。只需要一个ArduinoIDE+一个Arduino开发板，配合各式各样的输入设备（如传感器），配合一些输出，这就是一个简单的计算机原型。
嵌入式操作系统编程。对于复杂的场景来说，你还需要一个简单的操作系统，以帮助你进行任务调度。你可以简单的写一个任务调度，又或者是根据你的能力基于uCOS、FreeRTOS、Contiki、Zephyr等系统开发应用。
基于GNU/Linux的嵌入式系统编程。对于大部分人来说，只需要一个RaspberryPi+Python就可以编写一个高性价比的机器学习相关的应用；又或者是在路由器上运行OpenWRT这样的操作系统，这种性价比更更高的方案。
编译GNU/Linux操作系统。如果时间充裕，可以用诸如于LinuxFromScratch这样的工具，自己编译一个自用的操作系统。
物联网时代的嵌入式编程。我喜欢使用ESP32（ESP的继任者）来搞搞智能家居，它们自带Wi-Fi和蓝牙，有各种模拟现有设备的方案，配置上HomeKit。考虑到成本原因，对于没有硬件基础的开发者来说，采用AndroidThings又或者是WindowsIoT是一个更简单的选择。我没有玩过Fuchsia，它可能也是不错的，哈哈。
对于大部分开发者来说，连接物理世界是一项昂贵的事，毕竟硬件太贵了（考虑一下RaspberryPi，它也相当的不错）。于是乎，我们所能做的就是在操作系统之后，开发一些工具。
桌面应用。过去我尝试使用QT来开发一些桌面应用，后来我改为了PyQT/PyGtk+Python，而现在我都转向了Electron，用Web技术来开发桌面应用就是这么简单。
移动应用。尽管ReactNative、Flutter是一个非常不错的移动应用框架，我也用它们开发了一系列的应用。但是，从架构上来说，我偏向于使用混合式架构的应用，Flutter+Ionic/Angular，或者是RN+Ionic/Angular。
小程序。我讨论小程序，它们都有各种审查。
命令行界面应用（CLI）。对于日常工作来说，我们只需要一个简单的命令行，对于前端来说，也许Node.js就够了，对于后端来说，也许Python就够用了；不过，现在我更喜欢用Go来开发CLI应用。
Web应用。对于我们而言，考虑到跨平台特性，我往往使用后端Serverless+前端Angular+微前端架构来开发Web应用的工具。
浏览器插件。偶尔我也会开发一些浏览器插件，但是当我切换到Firefox浏览器之后，我正在考虑怎么迁移旧的Chrome插件。
愿意这些花式的介绍能给你的新工具带来一些想法。然后你就可以把这些知识串起来，开发一些有意思的应用：
基于Arduino+RaspberryPi的持续集成告警灯。通过ESP模拟各种硬件，部署个服务器，来实现远程。……现在，我们已经离题很远很远了，回到正题上。
找一个想法
配合上上述的技术栈，你就可以轻松地开发一个工具。
完了？
还没有
还有一半的内容
二、工具的开发模式
对于开发工具来说，存在一些特别固定的开发模式。我大概也经历了三个阶段，它们大概是三种不同的模式：
『随心所欲』造轮子模式。即，我爱怎么做，我就怎么做，我缺什么，我就加什么。『转化原则与模式』的模式。我从某些地方，寻找一些原则与模式，并将它们沉淀到工具里。『标准化特定流程』模式。我将过程、流程转变为工具，以弱化人在过程中的作用。『随心所欲』造轮子
没啥可说的，我爱怎么做就这么做。但是，它有这么一些点，你可以去玩：
积累技术和素材。要随心所欲地造轮子并不是一件容易的事情，你要有强大的学习能力，以实现自由自在的目的，上要会焊电阻，下要会拿锤子。寻找现成、学习现有的工具。你可以在它们身上学习到一些优点。构建、并持续完善常用的工具。通过持续的使用，你就可以完善这个工具，直到它顺手。突然间，我有了一个想法，自己写一个浏览器（基于Electron），笑~。如果提升技术对于你来说很重要，那么这是一个非常不错的提升点。然后，你就可以和我一样，开开心心地天天看着自己的bug在自己的电脑上复现，然后觉得在其它电脑上应该是好的。等我有空的时候，我再来修这个bug吧。
转化原则与模式
这个大抵是去年在造工具的一大收获。当时和公司的同事一起讨论造工具的时候，讨论出了沉淀出原则与模式，然后将使用工具来承载它们。
原则与模式这种东西，本身就是我们对于日常工作的一些沉淀。所以，它们特别容易被转换到工具上。我们也可以写一个工具，它用于介绍各种原则与模式，狗头。
转化原则与模式的另外一大意义是，告诉你：你可以通过学习别人，来打造出自己的工具。就这么来说，去年我在写Coca的时候，我做了这么一件事：
寻找各种paper。下载各种paper。阅读各种paper。然后，我就把各种paper转换到我的工具中了。虽然，大部分的paper都写得特别水（我觉得读完篇之后，写出一个工具之后，我能写出一篇比99%的都强），但是我们就轻松地copy了别人几个月的研究经验。
从书中读也是一个不错的主意，但是大部分技术书偏向于实践为主，比较难转换。
标准化特定流程
如果说，前两者是造轮子的话，那么标准化流程做的是平台。我最近在研究各种成熟度模型，它们有五个阶段。我更喜欢GitHub官方写的一个开源成熟度模型的定义：
临时（Ad-hoc）——新的或未记录的过程是不受控制、反应性的和不可预测的，通常是由个人驱动而没有协调或沟通。成功取决于个人英雄主义。管理（Managed）——流程已部分记录在案，有可能导致一致的结果。成功取决于纪律。已定义（Defined）——记录，标准化流程并将其集成到其他流程中。成功取决于自动化。度量（Measured）——对过程进行定量管理。成功取决于根据业务目标衡量指标。已优化（Optimized）——通过增量和创新更改，该过程正在持续可靠地得到改善。成功取决于减少变革的风险。抽象完这段话，我们就可以提到这样的过程：
个人的实践-团队的实践流程-标准化流程为工具-集成到其它流程，作为平台的一部分-持续完善平台
再一次抽象就是：
实践-模式-工具-流程-平台
对，就是这么简单。所以开发这一种模式的工具，只需要寻找现有的成熟度模式，然后就成平台了。
三、结论
没有轮子，哪来的KPI？
没有技术，哪来的轮子？
没有兴趣，哪来的技术？
最后，我又造了一个新轮子，一个『DevOps+研发效能』知识平台，欢迎大家Star：