如何清晰定位目標，並高效的寫一個工具，既不會和github重複，有自己的特點，從而不是造輪子？

12-30

自己欲寫一個工具，但是打開github發現有很多，但是又不知道質量如何，想自己寫的化，又怕重複造輪子，請問如何清晰的定位工具目標，然後高效的編寫？

開天闢地的活一不見得一個人做得來，二不見得能留名，說不定你自己默默無聞悶死了，最後成果被大牛發現，改進一番然後簽上了他的名字。

其實很多青史留名的傢伙都是在重複造輪子啊。

比如Linux是在重造Minix的輪子，Minix又是重造UNIX的輪子，Linux實際上是山寨的山寨。

所以和別人重不一定是大問題，重點是一定要有比別人做得好的地方。

造就造。現在什麼都被人寫光了，你堅持絕對要做別人沒做過的事情的話，就不要做了。

你喜歡，你愛做什麼不行？

這就是我做的一個毫無技術的小輪子，最近還想發展成一個自己的小應用。

造這個輪子的原因起因是我覺得市面上的熱量查詢工具有幾個比較蛋疼的地方：

需要下載
下載以後需要註冊
註冊以後還要填寫自己的一些傻逼信息
填寫一些傻逼信息以後還要每天給我發廣告
操作麻煩，輸入這個輸入那個，選來選去，反正我不喜歡啦

因為平時上班比較累，所以就想簡單一點，聊天形式的熱量記錄，直接就是天然的資料庫了，而且修改什麼東西也很方便........

於是就有了這樣的一個小工具，用戶量不大，大約是每天1500人在使用，我也不收錢，功能簡單明了，你說這個應用哪裡沒見過？哪裡沒玩過？

輪子哥經典寶話：「造就造。現在什麼都被人寫光了，你堅持絕對要做別人沒做過的事情的話，就不要做了。」 @vczh 好頂贊！！！！！

那為啥不先寫一個工具來檢測一個項目是否和github的項目在功能上重複或是相似，並且能列出功能類似的TOP10項目。這本身就是一個Idea啊小夥子。

曾經有這麼個段子：當我有什麼想法的時候，我就去淘寶搜搜，大多數情況下，人家早都有這個想法並且將它商業化了，少數情況能在某些地方找到這個想法不可行的證據。

有這樣的疑問說明你還不清楚自己的目的。那麼先三問自己：我是誰；我要產出什麼；我要得到什麼。

1. 我會什麼？水平如何？對於未知領域有沒有能力和毅力學習並掌握？

2. 我想做什麼？我為什麼要做？有多少feature？和現有產品比有何優勢？

3. 我要通過開發過程掌握什麼技能？希望給linkedin加項目經驗？希望github被star還是知乎圈粉？

雖然不嚴謹，但老實說，既不和各種開源閉源項目重複，又比別人質量好，還是新輪子的機會基本不存在。如果你能確定有這樣機會，那還不抓緊做好申請專利，跑來這裡問個毛線。不知道現有代碼的質量，可以扒下來測試嘛。

如果還不清楚自己要做什麼，可以從一些常見需求入手，嘗試把一些日常需求程序抽象化然後實現；或者平時有哪些覺得有用但是個人覺得還不夠好用的工具、軟體，找找開源的自己來完善，甚至是自己重寫。不要怕重複造輪子，好輪子自己實現一遍都會有很大收益。或者這些都看不上，那從零擼一個OS也可以啊對吧。

我看到的現實是能做的事情太多了，根本就是有沒有時間和能力夠不夠的問題。

如果你有時間就寫，現在滿世界的輪子，不怕多你一個。

嗯，想法不錯，五百年前也許行

（我就造了一個輪子，應該能回答一下題主的這個問題，因為剛開始造輪子的時候，就遇到了很類似的事情。

先廣告一下，我的輪子叫 amWiki (輕量級前端化文庫系統)，嘿嘿

-------------------------

剛開始的時候就是解析一下 markdown 生成文檔，卻和 gitbook、hexo、jkell、dokuwiki 這些體量龐大的工具是競爭關係。

剛開始對別人介紹項目的時候，很多人用很奇怪的眼神或者語氣面對你，好一點的只是說跟 gitbook 很像，而一些不客氣直接反問，你知道 hexo 么？

當時，真的很氣餒，我一個小小的個人開發者，工作還那麼忙，每天就那麼可憐的一點點開發時間，周末還常常被老婆埋怨不陪她，我的項目憑什麼在那些大型項目的擠壓下存活下來？

我一開始其實並沒有這個問題的答案，但是我仍然在繼續開發。

首先因為項目的最初有三個使用者，也是我工作團隊內的三位後端，他們用我的項目來寫介面文檔，他們在支持我。

雖然我一直認為，他們三個之所以用我的項目，不是因為一個初創項目功能有多好，而是這個項目的作者就在旁邊，想改啥就改啥，想要啥就有啥，立馬就有，還有一對一問題指導。

但是沒關係，就我自己來說，我需要造一個足夠份量的輪子來全面提升我自己，沒有造過輪子的前端不是好程序員，於是我就一直在堅持。

至於項目是不是被別人不屑一顧的問題，沒關係，就當練手好了，Github 上練手的項目多了去了，多我一個不多。何況我還是有使用者的，儘管少了點，但是也有不是？有使用者就能提煉需求，不是自己憑空臆造，一個輪子造下來，已經值了。

-------------------------

在造輪子的過程中，我一直在思考如何把項目本身做得更好，後來，事情才慢慢出現轉機。

第一次轉機是這樣的，當時和他們三個討論某個問題，其中一人問我，我們寫好一個介面自己是要測試的，你的文檔工具怎麼不在頁面上直接發 ajax 呢？這樣我們寫介面文檔和測試介面就可以一次搞定了！（當然原話比這個複雜很多，但是那些彎彎曲曲這裡就略過了）

當時，我是沒有那什麼響過一道驚雷啥的，當時覺得寫文檔的搞介面測試做什麼？囧…不過嘛，最後想了一想，好像加上也不錯，發個 ajax 而已，應該不會改變項目整體的性質啥的，做了就做了…

不過，做了這個功能上線應用了以後，給我帶來了不一樣的東西，那三個哥們，居然把項目推薦給他的朋友了！然後 Github 上居然多了兩個 Star！！！

這消息，讓我放下的心又重新燃起來了，於是在進行了很多分析和考察後，我於是認為，文檔即測試，這是一種的特色，那些做介面測試的項目哪一個不是龐大臃腫？然而我的項目簡單輕量，和文檔即測試的特色一組合，優勢就從重重迷霧中開始浮現了！這是我第一堂真正意義上的產品課，嘿嘿！

當然了，這都還是很小圈子裡的事情，上了一課後的的啟發也是很朦朧的，時間大概是16年初。

第二個轉機，是在 github 上，已經隔了一段時間到 16 年中旬了，在經過第一個 issue 的狂喜和冷卻後，第 7 個 issue 的提問者，給了我一個新的思路，內容搜索！

一開始我只是把這當做一個符合要求的普通需求來對待，直到我寫好功能了，我才明白，原來不知不覺間，一個神奇的功能誕生了，在github pages 這個純靜態空間上，不需要任何其他額外的條件，居然可以搜索任意文檔內容了，注意是內容，不是標題！

這可能就是所謂的開創先河了吧，這一刻，我也終於明白，終於可以開始對外做推廣了，因為介紹自己項目的時候，終於有底氣了。

-------------------------

而如今，17年中旬即將過去，我的項目已經提煉出很鮮明的思路了，那就是「前端化」+「文庫」。

這個前端化和「Web 前端」的前端略有區別，Web 前端一般是和後端配合組成系統的；

我這裡的這個前端化有些類似軟體、客戶端的意思，是指在沒有資料庫、沒有後端語言的條件下，在只有用戶直接接觸的這一端，儘管是文檔+網頁的形式，也向軟體、客戶端級別的功能體驗看齊，並努力將這種體驗做到極致，這是道路其一。

然後是文庫，這是一個定位問題，和 gitbook 主導的是 book 和社區化不同，也和 hexo、jkell 主導的是建站不同，amWiki 不推做書、不推建站；

amWiki 主導的是建設文庫，文庫即文檔成庫，界面功能優先按成百上千篇文檔這樣規模下的使用體驗來設計，努力做到再多的文檔也能很好管理和使用，這是道路其二。

在這兩個思路下開發，很明顯，已經不再是重複造輪子了。

這期間，通過一些推廣運營的工作，市場也有了反饋，amWiki 已經累積了一批原始用戶，交流群里莫名而來的用戶，也開始和我討論比較深入的實踐和應用問題了。

-------------------------

我覺得，作為程序員，真的不要怕造輪子，只不過造輪子前、中、後各個時期，都要腳踏實地，讓造輪子給自己帶來實質的收穫，收穫了才是真的，而不是為了造輪子或其他奇怪目的而造輪子。

其實不用自己造輪子，現有的輪子中肯定有很多的bug和未完善的功能，只要你能發現並修改就已經很了不起了。

說說我自己的經歷，Nginx本身不支持上傳文件的功能，但是一個俄羅斯人寫了個第三方模塊，Nginx官方推薦了，但是呢，由於版本迭代，這個模塊到Nginx某個版本就不能編譯了，剛好那段時間我要用這個模塊，所以在github上搜了一下，有人解決了那個問題（貌似是個中國人），但是遺留了兩個bug，我提交了patch，沒成想好幾年前的工程，作者給merge了！

再如，有段時間看到知乎上有人問有沒有簡單的C/C++程序，1000行以內的，供初學者入門學習，我看了下回答，其中有個引起了我的興趣，webbench，一個簡單的伺服器壓力測試工具，但是看了源代碼以後，發現它不支持HTTP的POST方法，我就給加上了，支持表單提交和文件上傳兩種使用POST方法的功能：https://github.com/winshining/webbench-plus-post

最近幾年直播不是挺火嘛，在github上閑逛，除了著名的SRS（Simple-RTMP-Server，國人楊成立發起的，國內很多廠商都在用）外，還有老早就成名的nginx-rtmp-module，而後者有個問題，不支持HTTP方式的直播，而這是SRS支持的，所以我就在工作之餘給加上了，學習了一把音視頻傳輸么知識，順便把Nginx的一些東西複習了一下：https://github.com/winshining/nginx-http-flv-module

還有個一致性Hash的Nginx第三方模塊，也是工作中要用，看了下源代碼，發現有個很簡單的bug，只是一直不敢確認，畢竟Nginx官方都推薦了，而且已經開發出來好多年了，然後去作者的github上看，結果看到有人兩年前就指出相同的問題。

所以，只要你想玩，不用造輪子，現有的輪子夠你玩了，當然，你要能搞出個像SRS那樣的輪子，大家肯定是歡迎的啦！

建議你找個時間機器，穿越到1970年1月1日。

這樣應該可以在一定程度上避免重複造輪子

這麼怕重複造輪子，我告訴你個好方法：你的工具滿足某些需求，這些需求是全世界任何人都不需要的需求。比如一個不輸出，不顯示，不報警的鬧鈴。

這樣你再也不會被重複造輪子所苦，還不謝謝我。

你能不能寫一個，插u盤自動換桌面，拔u盤換回原先桌面的工具，最好能放在u盤就能生效，實在不行安裝在電腦上也行。

這樣機房批量安裝上去，或者預裝在u盤裡，能防止不少丟失u盤事故。

語義層次很重要，我發現很多技術人員不善於從語義層次維度去做形式化分析。

比如：圖資料庫技術可以承載「數據之間的關係」，屬於比較低的語義層次；「人與人之間的關係」、「知識與知識之間的關係」等，數據更具體，語義層次更高，因此可以針對該語義層次進行建模、並實現相應的工具去承載。這個工具，可能依賴了圖資料庫，但核心的東西，是高語義層次的那些實現。

絕大多數人，習慣於利用技術，來實現自己的功能以便於任務交差。殊不知，他所引用的技術是一種低層次的代碼邏輯、要實現的功能也只是一個更高的語義層次的代碼邏輯……某個語義層次上，一定存在「做工具」的空間。

那麼，自己「做工具」有兩個方向：

1、某個低語義層次的工具歸納的不夠好、覆蓋的範圍不合適，重新實現該語義層次的工具。

2、對更高的語義層次進行歸納總結，實現該語義層次的工具。

什麼叫怕重複造輪子…

用自己現有的知識解決自己手裡的問題不是一個程序員需要具備的能力嗎？你有需求就動手寫啊管別人做沒做幹嘛。github的項目可以作為參考啊，不一定必須直接拿過來用的吧

支持輪子哥所說的，想造就造，反正造出來一般也除了你沒人用，如果你想造出來有人用，這輪子不造個一兩年是造不出來的，給你兩個缺輪子的方向，1，企業微信號，2，bpmn20流程的web設計器，這倆玩意都缺輪子，前一個是17年五六月才出的，所以輪子是很少的，後一個的輪子因為web在線設計流程是這兩年才有的趨勢，所以現在也是缺輪子，現在有的輪子都是大公司不開源的，你可以搞一個開源的

因為不是所有的數學家都會寫代碼，還是有些相當不錯的數學理論並沒有及時地轉換為code。

說一個可以造的輪子的思路，參數化曲線parameteric curve.

或許有人想說這個github上已經有了，然而github上有的大部分都是Bezier,B-Spline,NURBS等逼近(approximation)類型的曲線，而對於B-Spline,NURBS這些曲線，他們從誕生開始就離不開參數化(parameterization)，因為需要節點矢量，parameterization是其定義中的應有之義。

對於那些傳統的插值曲線呢。例如Newton,Hermite,Cubic curve來說，他們都是可以參數化的，而且參數化之後性質有很大提高[1]。

至少體現在（以二維X,Y曲線為例）：

傳統曲線相鄰點X坐標不能相等，不然會出現0作分母的情況，參數化曲線不會
有些傳統曲線不能形成環，參數化曲線可以
有些傳統曲線要求X坐標必須以遞增順序排布，參數化曲線不需要

[1]Barsky B A, Derose T D. Geometric Continuity of Parametric Curves: Three Equivalent Characterizations[J]. IEEE Computer Graphics Applications, 1989, 9(6):60-69.

造輪子可以，但是要造一個比別人的項目更好的輪子才有意義

呵呵呵。這個我覺得我能夠回答。我的建議是，放下你心中的「怕」，想做就做唄。最不濟自己也能在寫代碼的過程中學到很多東西。

這是我幾年前為了磨練自己的正則表達式基礎寫的工具在線解方程，運行了好幾年了每天幾百號小朋友都會過來算一算。讓我吐血的是人民群眾的想像力是不可戰勝的. 各種意料之外的輸入和特殊字元讓我基本放棄治療了。寫了這玩意後我知道了兩個道理：1.沒人看你的工具說明 2.你覺得你自己牛逼正則表達式玩起來跟霸王舉鼎一樣，然鵝人民群眾會分分鐘教你做人。然後我學會了謙虛。

最近我又寫了個小工具微信朋友圈截屏生成器這個沒什麼技術含量，是專門給我朋友寫了生產段子用的。純粹好玩。最近默默看他生產了一些創意圖片用來做廣告。囧漲姿勢了。

你看看這麼傻逼的工具都有人寫。你還怕什麼。

一個是輪子的研究，一個是造輪子的研究。你到底要輪子還在要練技能得想清楚。兩全其美的事情不容易，總得分個主次吧。

主次沒分清，說明你的「清晰定位目標」都沒達到……