过去的几年里,我一直在打造各式各样的编程相关的工具。这些工具有的是用于指导软件开发工作,有的是用来进行编程学习,还有的纯粹是为了提升技术而写的。在我写了越来越多的工具,接触了越来越多的工具思路之后。 我便想写一篇文章,用于记录一下过程中发生的一些变化。
如果你拥有广泛的技术栈知识,还有相对充裕的时间,那么加上一些激情,你就能写出一个不是那么差的工具。
在我短短十几年的编程生涯中,我尝试了不同的层级技术栈,大抵也是了解怎么从底层到顶层做各种工具。连接物理世界的工具:
对于大部分开发者来说,连接物理世界是一项昂贵的事,毕竟硬件太贵了(考虑一下 Raspberry Pi,它也相当的不错)。于是乎,我们所能做的就是在操作系统之后,开发一些工具。
愿意这些花式的介绍能给你的新工具带来一些想法。然后你就可以把这些知识串起来,开发一些有意思的应用:
现在,我们已经离题很远很远了,回到正题上。
配合上上述的技术栈,你就可以轻松地开发一个工具。
完了?
还没有
还有一半的内容
对于开发工具来说,存在一些特别固定的开发模式。我大概也经历了三个阶段,它们大概是三种不同的模式:
没啥可说的,我爱怎么做就这么做。但是,它有这么一些点,你可以去玩:
然后, 你就可以和我一样,开开心心地天天看着自己的 bug 在自己的电脑上复现,然后觉得在其它电脑上应该是好的。等我有空的时候,我再来修这个 bug 吧。
这个大抵是去年在造工具的一大收获。当时和公司的同事一起讨论造工具的时候,讨论出了沉淀出原则与模式,然后将使用工具来承载它们。
原则与模式这种东西,本身就是我们对于日常工作的一些沉淀。所以,它们特别容易被转换到工具上。我们也可以写一个工具,它用于介绍各种原则与模式,狗头。
转化原则与模式的另外一大意义是,告诉你:你可以通过学习别人,来打造出自己的工具。就这么来说,去年我在写 Coca 的时候,我做了这么一件事:
然后,我就把各种 paper 转换到我的工具中了。虽然,大部分地 paper 都写得特别水(我觉得读完 100 篇之后,写出一个工具之后,我能写出一篇比 99% 的都强),但是我们就轻松地 copy 了别人几个月的研究经验。
从书中读也是一个不错的主意,但是大部分技术书偏向于实践为主,比较难转换。
如果说,前两者是造轮子的话,那么标准化流程做的是平台。我最近在研究各种成熟度模型,它们有五个阶段。我更喜欢 GitHub 官方写的一个开源成熟度模型的定义:
抽象完这段话,我们就可以提到这样的过程:
个人的实践 -> 团队的实践流程 -> 标准化流程为工具 -> 集成到其它流程,作为平台的一部分 -> 持续完善平台
再一次抽象就是:
实践 -> 模式 -> 工具 -> 流程 -> 平台
对,就是这么简单。所以开发这一种模式的工具,只需要寻找现有的成熟度模式,然后就成平台了。
没有轮子,哪来的 KPI?
没有技术,哪来的轮子?
没有兴趣,哪来的技术?
KPI 是什么?
围观我的Github Idea墙, 也许,你会遇到心仪的项目