程式設計師真正的價值

問：池老師，我是個不愛互動的人，但是您所有的文章我都看了，非常感謝您的引導，我入手了人生第一臺 MBP。現在問題來了，但是找不到更合適的人解答，只能求助於您了，如果您有時間的話。問題是這樣的：我有個32bit unix file（開啟一個服務程式），在 Mac 上執行時錯誤提示是：exec format error，但是在 Linux 伺服器卻可以執行，為何？Mac 上有可以執行的方案嗎？期待您的回覆，不勝感激。

答：Linux 和 OS X 是不同的作業系統，可以嘗試在 OS X 裡重新編譯這個檔案。

問：非常感謝！如果沒有檔案原始碼是不是就只能認命了？

答：可以在 Mac 上裝 Docker，然後對服務進行埠對映就可以了。

答：茅塞頓開。謝池老師。

以上是我和一位讀者的對話，這位小夥子在拿到答案之後像一縷煙塵一樣消失無蹤，之後再也沒有出現過。

在微信上加了很多 MacTalk 的讀者之後，經常會收到一些奇奇怪怪的問題，關於職場、關於選擇、關於朋友、關於 Mac、關於技術等等，不一而足。但是我能回答的卻很少。問題不好沒法回答，問題太複雜沒法回答，問題領域超出我的認知也沒法回答，耗時太長的問題我也沒 時間回答，實在是慚愧的緊。好在偶爾也能夠幫助一些小夥伴解決一些實際問題，心理上略感安慰，比如上面這個問題。

把這段程式設計師之間的對話翻譯一下，大致是這麼個故事：

一位讀者有一個32位的 Unix 可執行檔案，可以在某種版本的 Linux 伺服器上正常執行，執行這個檔案作用就是起個程式，開埠，然後與其他程式進行互動。但是這個檔案拿到 Mac 上完全沒辦法執行。就在他趴在 Mac 上愁腸百結萬念俱灰的時候，突然想到了「池老師」。不就是這個老傢伙把 Mac 誇的像一朵玫瑰一樣，讓每個程式設計師都去採摘麼？現在扎手了，你不管誰管？於是他給我發來訊息，意思就是管也得管，不管也得管，您看著辦。

我拿到問題一看，不難。Linux 和 OS X 雖然師出同門，都是從老前輩 Unix 那兒畢業的，但是後來畢竟各練各的，在 Linux 編譯好的程式不可能在 OS X 上用，但是在 OS X 上重新編譯一下可能就沒事了。我把這個想法告訴了這位程式設計師，得到的反饋是：對不起哥，沒有原始碼！

我被這個冷酷的回覆震驚了，立刻意識到 剛才的想法並不是最優解決方案，因為在重新編譯的過程中，各種包的依賴關係和編譯錯誤足以讓你焦頭爛額，我隨即提供了 B 計劃：在 OS X 上安裝 Docker，輕量級的容器 Docker 可以執行各種版本的 Linux，把檔案扔到 Docker 裡，然後通過主機和 Docker 之間的埠對映即可輕鬆解決這一問題。

雖然這裡面會涉及很多技術細節，但是方向是沒有問題的，所以這位程式設計師立刻表示「茅塞頓開」，然後「biu 」的一聲就在螢幕對面消失了，沒有留給我說「不客氣」的機會。

這個問題裝個 Linux 虛擬機器也可以解決，但是虛擬機器過於耗費資源，而且不如 Docker 靈活，所以不是最佳解決方案。Docker 是。

做為一個程式設計師，我們除了要掌握多門程式語言和多種資料庫，瞭解前端技術、後端技術，通曉網路七層架構，知道 TCP/IP三次握手和四次揮手，編寫漂亮的程式碼，設計優美的架構……之外，我們還要解決研發、程式執行和產品上線過程中遇到的各種問題，而且被要求以最 小的代價來解決問題……我們容易嗎？

除了程式設計技巧和程式設計能力，解決問題的穩準狠是衡量一個程式設計師是否優秀的重要因素之一，也是資深技術 人員真正的價值所在。在科技浪潮澎湃、技術資訊撲面而來的今天，一位剛畢業的大學生如果足夠勤奮，他可以在兩三個月之內掌握一門程式語言，並編寫出像模像 樣的軟體，他們的學習速度甚至超過了我們這些老程式設計師，但是解決問題的能力是無法速成的，只能依靠時間、經驗和慘痛的教訓歷練而成。有時候還需要靈感和運 氣。

很多軍迷讀了大量的軍事著作和歷史小說，常常羨慕那些名將的風采，並浩嘆自己「生不逢時」。但是名將不是那麼容易煉成的。歷史上叱詫風 雲的名將鳳毛麟角，他們親自持刀上陣追擊敵人，見識戰場的慘烈，目睹敵人的屍體，看到戰友被殺，知道被刀看中會流血死去，他們冷酷無情，堅如磐石，在全軍 即將崩潰的時候發現敵人的弱點並進行攻擊，在瞬息萬變的戰場進行決斷，在多次失敗後從無數士兵的屍體裡站起來重新出發去挑戰那個戰勝你的對手，在所有人對 你說「指導員，我們上吧」的時候，堅定的說出那三個字：再等等！

如果你做不到這些，那還是做個最終會被張飛槍挑的小兵吧。

優秀的程式設計師同樣如此，菜鳥常常羨慕高手在談笑之間讓難題灰飛煙滅，而自己卻苦苦思索而不得入門之法，殊不知這些高手同樣經歷了名將的那些腥風血雨。他們在 清晨的微光裡編寫程式碼，在轟鳴的機房中除錯程式，他們徹夜不眠就是為了解決一個 bug，他們要承受資料丟失或上線失敗的痛苦，默默吞下眼淚，準備下一次的戰鬥。不停的學習、實踐和思索，成千上萬個小時之後，高手史成。

同樣的問題，高手的解決思路和小球是截然不同的。一般來說，只要不是世界難題，給足時間、空間和人力，都能解決。如果你遇到問題告訴上級，這個問題交給我 了，兩年之內搞的妥妥噠，那就不要怪專案組組團把你打出翔來，因為大家要的是分分鐘解決，不是兩年。在這個唯快不破的年代，我們沒有這麼多的時間，所以要 通過逆向思維、經驗教訓、輾轉騰挪、借力打力等方式以最小的代價快速解決問題。這才是老程式設計師的價值。

再舉個例子，一個執行良好的線上應用在你修改 bug 增加功能之後重新上線出現了一些莫名其妙的問題，比如佔用資源增加或執行一段時間當機等等，怎麼解決？

常規的做法就是通過閱讀日誌、模擬線上環境和除錯程式來定位錯誤。容易的 bug 用這些方式基本就能搞定了，但是更隱蔽的 bug 會耗費大量的時間和人力。更好的方式是什麼？

首先，排查是程式問題還是環境問題，把線上程式恢復到執行正常時的老版本，如果出現了同樣的問題，那就是生產環境發生了改變。如果執行正常，要麼是你修改老 bug 時引入了新 bug，要麼是新增加的程式碼出現了問題。

其次，閱讀產品的 changelog，根據程式碼提交的時間線構建系統，通過二分法排查，定位是哪部分程式碼引起的問題。

第三，排除了所有的不可能，剩下的無論看起來如何不可能，就是它乾的。

以上只是一個簡單的例子，實際的情況可能比這個例子複雜一百倍，需要我們綜合使用各種方式進行交叉比對和錯誤排查才能解決。這僅僅是遇到問題解決問題，更多的時候是需要你提出問題，並解決問題，那是更高的境界。

很多人學了那麼多程式語言，寫了十幾年程式，最終依然無法做到以最小的代價解決問題，不禁讓人扼腕嘆息。

程式設計師真正的價值是什麼？以最小的代價解決問題！知行合一，方可無敵於天下。

文章出處：池建強