大家好，我是艾叔，從04年第一個正式的軟件項目開始，一直在做編程相關的事情：開發過工業級的軟件；做過很多次Hadoop和Spark的算法性能優化和實現；寫過Linux下的硬件驅動；裁剪和移植過操作系統；帶學生打過很多次編程比賽；也得過很多獎。

復盤這15年，發現對自己編程方面影響非常深的，卻是3件和編程不太相關的事情。

第一件事：解決計算機報“缺少**dll文件”的問題

那是剛入大學的時候，同學電腦報了一個“缺少“**dll”的錯誤，具體文件的名字已經記不清楚了。

我當時都沒怎麽接觸過計算機，但畢竟是學這個專業的，也想挑戰下自己，於是，嘗試幫他解決這個問題。

我根據對話框彈出的dll文件名，去網上搜索，找到了這個文件，並把它放到了指定的目錄下。

系統重啟後，原來的錯誤沒有了，但報了一個新錯誤：“缺少另一個dll文件”。

沒問題，繼續尋找唄。

就這樣，不斷找到缺失的文件，復制，重啟，又報新文件缺少的錯誤。

反反復復，沒有盡頭。

這時，我們班的計算機牛人同學出手了，他並沒有沿著我的思路走，而是把報錯的硬件驅動直接刪掉，重新檢測硬件，安裝驅動，重啟，計算機不再報錯，整個世界都清凈了。

這件事情過去已經近20年了，當年的場景仍記憶猶新。

因為這代表了兩種不同的解決問題的思路，一種是我們人類世界的，而另一種則是計算機世界的。

按照我們人的思路，全部推倒重來，雖然能徹底解決問題，但是，通常要比修修補補這種方式，付出更大的代價。

而在計算機世界中，只要是計算機能完成的，不管其過程多復雜，它都會不知疲倦地把事情做得又快又好，其代價可以忽略不計，人只用下達正確的指令即可。

我的問題就在於：用我們人的做事思路，手動去解決計算機世界的問題，既費時費力，還無法徹底解決。

第二件事：解決電臺通信接口的問題

那是剛參加工作不久，有一天，領導拿來四個Modem（調制解調器，可以實現數字信號和模擬信號之間的互相轉換），並交代了任務：利用今晚的時間，使用Modem連接三臺計算機，並編程實現任意兩臺計算機之間的文件傳輸，第二天去現場演示。

我之前做的工作很少和硬件打交道，既然不會，就現學。看說明書，看連線，終於用Modem將三臺計算機給連接起來。

然後又打開示例程序，開始研究起代碼來。代碼是VB寫的，我之前一直用的是Delphi，但語言是相通的，這個難不倒我。經過一個晚上的修改，我和另外一個同事一起，在原來程序的基礎上，增加了轉發的功能，順利實現了任意兩臺計算機的文件傳輸。

第二天，帶著Modem和程序，我們踏上了北去的列車。

達到現場，已是下午，吃過晚飯，我們來看設備，頓時傻眼。

我們在實驗室時，Modem之間是用導線直接互聯的，而到了現場，Modem是要連接電臺的，也就是說，數據最終是通過電臺發送和接收，實現雙方計算機數據通信的。

這兩天的跨度確實有點大，我是學計算機的，電臺只是聽過這兩個字而已，具體是什麽，在這一秒之前，都沒見過，更不用說，要利用它實現數據通信了。

捋了捋頭發，壓壓驚。

我提出了問題的關鍵：即Modem和電臺之間如何連接？

我們找到了電臺的專用接口，密密麻麻有幾十個引腳，關鍵是還沒找到說明書，每個引腳是幹什麽的不知道，還有就是，引腳非常密集，需要有專門的接頭對接，才能將線引出來。

兩個問題橫亙在面前，我們分成兩組，第一組，在堆積如山的資料中去找說明書；第二組，則研究如何在沒有專用接頭的情況下，將Modem的線和電臺的引腳連接上。

第二天一早就要演示，時間一分一秒過去，到了淩晨3點，兩個小組都沒有解決的跡象。

怎麽辦？

Modem和Modem之間連接，最主要就是一收、一發兩根線，這個對於Modem和電臺也一樣。關鍵就是要找到電臺接口中，哪個是收、哪個是發，並連接上。

按照前面的方案，從電臺的專用接口突破，希望很渺茫。

那除了這個接口，電臺還有沒有其它接口呢？有沒有可能繞過這個接口呢？

順著這個思路，我一眼看到了電臺的送話器，我們用它可以說話，這就是發送信號，也可以聽到對方的說話，這就是接收信號。它不就是電臺的第二個接口嗎？

更重要的是，它的接線非常簡單，而且因為它的導線已經引出，所以和Modem導線之間的連接也非常方便。

確定思路後，我們趕緊拆開送話器，確定收發線，然後，將Modem的導線臨時焊接了上去。

忙完這些，窗外的遠山已經漸漸清晰起來，天際露出了魚肚白，一輪紅日噴薄而出。（此處為文學描寫，請自行忽略。。。）

趕緊打開電臺試機，在計算機中點下發送按鈕，計算機的數據，通過電臺發送出去，發出呼呼的聲音，而在接收端，果然接收到了數據正確的文件。

大家沸騰了，這一天一夜的的工作沒有白費，第二天，我們順利地完成了演示，拿下了這個項目。

這件事，對我後續的影響是很大的。之前，我通常習慣於做有把握的事情，但在實際中，很多事情是來不及準備的，這個時候，積極主動想辦法，就有解決的希望。

第三件事：解決視音頻不同步的問題

第三件事情，發生在我第一次帶學生參加全國軟件大賽時。

比賽要求上傳作品的介紹視頻，為了有更好地效果，我們用動畫來介紹作品，這個動畫制作起來非常麻煩，每一幀都要手繪，而且還找了專業的配音，再加上作品開發的任務很緊張，整個動畫直到作品提交截止的那個晚上，才做完。

當我拿著做好的動畫，回到家準備上傳時，為了以防萬一，我在自己的筆記本上，又播放了一遍動畫，頓時傻眼。

動畫視頻在我的筆記本上播放，嚴重不同步，介紹的語音都已經講完了，動畫裏人物的嘴還在一張一合。

這是為什麽？在做動畫的機器上，這個不是播放的好好的嗎？

時間已經是晚上10點多了，離截止的時間不到2個小時。

雖然我沒有做過專門的視音頻處理，但從現象上看，還是能夠基本推測出來，這個是因為：筆記本的顯示性能比較弱，從而導致：視頻播放的速度遠慢於音頻播放速度。

該如何解決呢？

拿回去重新編輯，重新生成已經來不及，只能另想辦法。既然不能編輯源文件，那我能否用軟件，直接降低該視頻的分辨率呢？

到網上去搜索，還真是有很多這樣的軟件，但好用的沒有幾個，費盡幾番周折，終於搞定了一個。轉換以後，雖然分辨率下降了，但視音頻同步了，還是達到了想要的效果。

快接近12點的時候，我們終於把介紹視頻給傳了上去。

後續，在那次比賽中，我帶領了2個零基礎的本科生，戰勝了多支985大學的研究生團隊，得到了全國總決賽的第2名。

這件事情和第二件事有點類似，工作中很多的事情，真的很難準備充分，但積極地去應對，就有解決的希望。

這三件小事，雖然和編程沒有太多直接的關系，但卻對我編程有重大影響。第一件事，讓我對計算機的世界觀有重新的認識，提醒我在編程的時候，要遵循計算機世界的規律；第二、三件事，則提升了我的信心，增加了處理未知的編程問題的經驗。

Ps：艾叔不是高手，也不是牛人，編程的道路上，走了很多彎路，也踩了很多坑，如果你也和艾叔當年一樣，歡迎掃碼關註公眾號。如果您覺得文章有用，也可分享給有需要的人。

復盤15年編程路-印象最深的3件事