作者 | 黃峰達，CSDN 博客專家 Phodal

責編 | 唐小引

出品 | CSDN（ID：CSDNnews）

過去的幾年里，我一直在打造各式各樣的編程相關的工具。這些工具有的是用于指導軟件開發工作，有的是用來進行編程學習，還有的純粹是為了提升技術而寫的。在我寫了越來越多的工具，接觸了越來越多的工具思路之后。我便想寫一篇文章，用于記錄一下過程中發生的一些變化。

一、如何打造工具？

如果你擁有廣泛的技術棧知識，還有相對充裕的時間，那么加上一些激情，你就能寫出一個不是那么差的工具。

工具的技術棧

在我短短十幾年的編程生涯中，我嘗試了不同的層級技術棧，大抵也是了解怎么從底層到頂層做各種工具。連接物理世界的工具：

• 純嵌入式系統編程。

只需要一個 Arduino IDE + 一個 Arduino 開發板，配合各式各樣的輸入設備（如傳感器），配合一些輸出，這就是一個簡單的計算機原型。

• 嵌入式操作系統編程。

對于復雜的場景來說，你還需要一個簡單的操作系統，以幫助你進行任務調度。你可以簡單的寫一個任務調度，又或者是根據你的能力基于 uCOS、FreeRTOS、Contiki、Zephyr 等系統開發應用。

• 基于 GNU/Linux 的嵌入式系統編程。

對于大部分人來說，只需要一個 Raspberry Pi + Python 就可以編寫一個高性價比的機器學習相關的應用；又或者是在路由器上運行 OpenWRT 這樣的操作系統，這種性價比更更高的方案。

• 編譯 GNU/Linux 操作系統。

如果時間充裕，可以用諸如于 Linux From Scratch 這樣的工具，自己編譯一個自用的操作系統。

• 物聯網時代的嵌入式編程。

我喜歡使用 ESP32 （ESP8266 的繼任者）來搞搞智能家居，它們自帶 Wi-Fi 和藍牙，有各種模擬現有設備的方案，配置上 HomeKit。考慮到成本原因，對于沒有硬件基礎的開發者來說，采用 Android Things 又或者是 Windows IoT 是一個更簡單的選擇。我沒有玩過 Fuchsia，它可能也是不錯的，哈哈。

對于大部分開發者來說，連接物理世界是一項昂貴的事，畢竟硬件太貴了（考慮一下 Raspberry Pi，它也相當的不錯）。于是乎，我們所能做的就是在操作系統之后，開發一些工具。

• 桌面應用。

過去我嘗試使用 QT 來開發一些桌面應用，后來我改為了 PyQT / PyGtk + Python，而現在我都轉向了 Electron，用 Web 技術來開發桌面應用就是這么簡單。

• 移動應用。

盡管 React Native、Flutter 是一個非常不錯的移動應用框架，我也用它們開發了一系列的應用。但是，從架構上來說，我偏向于使用混合式架構的應用，Flutter + Ionic / Angular，或者是 RN + Ionic / Angular。

• 小程序。

我討論小程序，它們都有各種審查。

• 命令行界面應用（CLI）。

對于日常工作來說，我們只需要一個簡單的命令行，對于前端來說，也許 Node.js 就夠了，對于后端來說，也許 Python 就夠用了；不過，現在我更喜歡用 Go 來開發 CLI 應用。

• Web 應用。

對于我們而言，考慮到跨平臺特性，我往往使用后端 Serverless + 前端 Angular + 微前端架構來開發 Web 應用的工具。

• 瀏覽器插件。

偶爾我也會開發一些瀏覽器插件，但是當我切換到 Firefox 瀏覽器之后，我正在考慮怎么遷移舊的 Chrome 插件。

愿意這些花式的介紹能給你的新工具帶來一些想法。然后你就可以把這些知識串起來，開發一些有意思的應用：

• 基于 Arduino + Raspberry Pi 的持續集成告警燈。

• 通過 ESP8266 模擬各種硬件，部署個服務器，來實現遠程。

• ……

現在，我們已經離題很遠很遠了，回到正題上。

找一個想法

配合上上述的技術棧，你就可以輕松地開發一個工具。

完了？

還沒有

還有一半的內容

二、工具的開發模式

對于開發工具來說，存在一些特別固定的開發模式。我大概也經歷了三個階段，它們大概是三種不同的模式：

• 『隨心所欲』造輪子模式。即，我愛怎么做，我就怎么做，我缺什么，我就加什么。

• 『轉化原則與模式』的模式。我從某些地方，尋找一些原則與模式，并將它們沉淀到工具里。

• 『標準化特定流程』模式。我將過程、流程轉變為工具，以弱化人在過程中的作用。

『隨心所欲』造輪子

沒啥可說的，我愛怎么做就這么做。但是，它有這么一些點，你可以去玩：

• 積累技術和素材。要隨心所欲地造輪子并不是一件容易的事情，你要有強大的學習能力，以實現自由自在的目的，上要會焊電阻，下要會拿錘子。

• 尋找現成、學習現有的工具。你可以在它們身上學習到一些優點。

• 構建、并持續完善常用的工具。通過持續的使用，你就可以完善這個工具，直到它順手。突然間，我有了一個想法，自己寫一個瀏覽器（基于 Electron），笑~。如果提升技術對于你來說很重要，那么這是一個非常不錯的提升點。

然后， 你就可以和我一樣，開開心心地天天看著自己的 bug 在自己的電腦上復現，然后覺得在其它電腦上應該是好的。等我有空的時候，我再來修這個 bug 吧。

轉化原則與模式

這個大抵是去年在造工具的一大收獲。當時和公司的同事一起討論造工具的時候，討論出了沉淀出原則與模式，然后將使用工具來承載它們。

原則與模式這種東西，本身就是我們對于日常工作的一些沉淀。所以，它們特別容易被轉換到工具上。我們也可以寫一個工具，它用于介紹各種原則與模式，狗頭。

轉化原則與模式的另外一大意義是，告訴你：你可以通過學習別人，來打造出自己的工具。就這么來說，去年我在寫 Coca 的時候，我做了這么一件事：

• 尋找各種 paper。

• 下載各種 paper。

• 閱讀各種 paper。

然后，我就把各種 paper 轉換到我的工具中了。雖然，大部分的 paper 都寫得特別水（我覺得讀完 100 篇之后，寫出一個工具之后，我能寫出一篇比 99% 的都強），但是我們就輕松地 copy 了別人幾個月的研究經驗。

從書中讀也是一個不錯的主意，但是大部分技術書偏向于實踐為主，比較難轉換。

標準化特定流程

如果說，前兩者是造輪子的話，那么標準化流程做的是平臺。我最近在研究各種成熟度模型，它們有五個階段。我更喜歡 GitHub 官方寫的一個開源成熟度模型的定義：

• 臨時（Ad-hoc） —— 新的或未記錄的過程是不受控制、反應性的和不可預測的，通常是由個人驅動而沒有協調或溝通。成功取決于個人英雄主義。

• 管理（Managed）—— 流程已部分記錄在案，有可能導致一致的結果。成功取決于紀律。

• 已定義（Defined）—— 記錄，標準化流程并將其集成到其他流程中。成功取決于自動化。

• 度量（Measured）—— 對過程進行定量管理。成功取決于根據業務目標衡量指標。

• 已優化（Optimized）—— 通過增量和創新更改，該過程正在持續可靠地得到改善。成功取決于減少變革的風險。

抽象完這段話，我們就可以提到這樣的過程：

個人的實踐 -> 團隊的實踐流程 -> 標準化流程為工具 -> 集成到其它流程，作為平臺的一部分 -> 持續完善平臺

再一次抽象就是：

實踐 -> 模式 -> 工具 -> 流程 -> 平臺

對，就是這么簡單。所以開發這一種模式的工具，只需要尋找現有的成熟度模式，然后就成平臺了。

三、結論

沒有輪子，哪來的 KPI？

沒有技術，哪來的輪子？

沒有興趣，哪來的技術？

作者簡介：黃峰達（Phodal），ThoughtWorks Senior Consultant，CSDN 博客專家。長期活躍于 GitHub、CSDN，專注于物聯網和前端領域。出版著作《自己動手設計物聯網》，以及《Growth：全棧增長工程師指南》等六本電子書，并譯有《物聯網實戰指南》。

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

總結

以上是生活随笔為你收集整理的程序员造轮子的正确姿势的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。