10個程式設計師必須學會接受的殘酷真相

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

大多數時候，寫程式碼都是挺有意義的一件事，不光能增加經驗值，解決難題的時候還特別爽。耐心、毅力、執著，再加上正確的工具——只要有它們的親密協作，優雅、漂亮的程式碼就是手到擒來的事兒。

但是，緊接著拙劣的資源部署、新增的特性請求、糟糕的文件更新洶湧而來，打破了我們的美夢。

但是這並不是說我們的努力就沒有價值。只是我們需要面對現實罷了。下面就是程式設計開發人員必須接受的10個殘酷真相。

殘酷的開發真相No. 1: 程式設計就是if-then-else語句的運用

程式語言設計者討論、抽象化思考等等作為，其實都只是在舊的if-then-else語句上重新包裝一下而已。

這也幾乎就是硬體所有的功能了。是的，通過操作碼我們可以順利地移動資料輸入和輸出作運算和儲存，其餘的則在比較的基礎上進行分支或者不分支。

而致力於人工智慧的同志們更是為這些if-then-else語句包裹上了一件件神祕的外衣，通過這些語句，機器會按照我們的吩咐自動從一些數字矩陣中執行計算，查詢搜尋直到發現目標。

殘酷的開發真相No. 2: 網際網路其實就是儲存在表中的資料

在過去20年間，“網際網路”這個詞造就了神話般的財富、搭建了五湖四海的友誼、生產出更為便宜的產品、促成了更為快捷的溝通等等等等，除了治療癌症，它幾乎就是無所不能。但是，說到底，網際網路的本質就是一堆儲存在表中的資料罷了。

Match.com？就是列滿頭髮顏色、宗教信仰和興趣愛好的表格而已。ebay？就是一張記錄一筆筆合同的交易表。部落格？就是一張每一行每一列寫下你天馬行空胡言亂語的資料表。無論我們怎麼給它起名字，它的本質還是資料表格。

這一點也可以從程式語言中看出來。例如Ruby on Rails——當前操作web最為流行的程式語言之一，其實就是在資料庫中搞一個小天地：指定一個全域性變數，Rails就會自動建立一個列，因為它的作用就是在資料庫中建立表格。

殘酷的開發真相No. 3: 使用者有自己的想法

偶爾使用者會變得理智和通情達理，但是大多數情況下，他們都是古怪且難以琢磨的——甚至是非常苛刻的。程式設計師根本想不到這些使用者在看到產品時會出來哪些天馬行空的想法。因為使用者不是程式設計師，不會照著程式設計師的想法走。

殘酷的開發真相No. 4: 你寫的大部分程式碼將永遠不會被使用

這一點就不再多說了，說多了都是淚啊！

殘酷的開發真相No. 5: 需求變更是必然的

有一位經理告訴我他的祕訣就微笑著和他的團隊說他們很棒，他很欣賞他們做的一切，然後在臨出門之間，他會說，“對了，還有一件事……”。就是這件事往往會顛覆整個專案，讓每個人都重新回到設計app的起點。

需求變更是專案結構的直接後果。管理人員會在事情開展之前做好所有的規劃工作，制定目標。

但是一旦事情交給開發人員，那管理人員就輕鬆了，然後開始無所事事了，成天胡思亂想吹毛求疵。這個按鈕放的地方對嗎？登入頁面是不是應該改一改？反正一點點細微的想法就讓開發人員去做修改。

這在專案過程中頻繁發生，而且由來已久。要知道，就算是Ada Lovelace的分析機——被譽為第一段計算機程式，也有著需求變更的問題，源於將近一年的筆記討論中。

殘酷的開發真相No. 6: 沒有人理解你，特別是你的老闆

我們可以將程式設計師分成兩種：第一種的老闆是不會程式設計的，也不知道為了使程式碼能成功編譯需要付出多大的努力；還有一種的老闆以前也是程式設計師但是現在已經忘記了程式碼編譯過程的艱辛。

第一種老闆顯然永遠也不會理解你以及你的工作。不過這也是可以理解的，畢竟所學不同，術業有專攻。

而第二種老闆，我們也可以理解。舉個例子吧，即使是最好的程式設計師，如果一兩個月不用API也會忘記這方面的內容。再則他們以前學的主流程式語言很有可能和現在的大不相同。

還有一點，如果你的老闆自己知道如何解決問題的話，他往往會選擇自己熬夜解決它而不是費時費力地僱用其他程式設計師來解決。所以我們得感謝這些“不懂寫程式碼”的老闆。

殘酷的開發真相No. 7: 關於隱私，痛苦的糾結

我們都希望我們的服務可以保護我們的使用者和他們的資訊。但是同時，我們也希望網頁簡單且易於操作。點選深度——達到目標所需要的點選次數——儘可能的少。

然而保護使用者的隱私就意味著，在使用者點入頁面之前得詢問使用者一些問題，以確定使用者已經知道這樣做可能帶來的後果。

隱私也意味著責任。如果使用者不希望伺服器知道發生了什麼事情，那麼使用者就得自我承擔責任，因為這樣做會導致伺服器不能夠讀取使用者的資料。責任就意味著麻煩，從這個層面上說，隱私也是個麻煩。

隱私也意味著矛盾的邏輯思維。一邊希望能一個人呆著，另一邊希望知道大量的資訊；一邊渴望安安靜靜毫無紛爭，另一邊則希望什麼邀請函、購物優惠券、工作面試機會等等有多少來多少。

唉，俗話說，魚與熊掌不可兼得啊。總之隱私還是不隱私，it’s a question。

殘酷的開發真相No. 8: 信任是有代價的

專案Web 2.0聽上去很美！感覺只要把大家的程式碼連線起來，就會有奇蹟發生。你可以呼叫他人的程式碼，別人也可以呼叫你的，相得益彰。

如果真能像你想的那麼簡單就好了。事實是，首先在別人允許你使用他們的程式碼之前得先填寫一些表格——大多數情況下會由專業人士起草——簽署“不平等條約”。你的回報是什麼呢？將你辛辛苦苦寫出來的這麼漂亮的程式碼交給別人，卻不知道別人給出的是什麼貨色？但是，沒辦法，你只能相信他們。

但是他們也不知道你是不是真有真材實料？搞不好你不過是個濫竽充數的傢伙呢？但是他們也沒有辦法，也只能相信你。

而使用者則不得不信任你們雙方。哈，你說隱私？當然有了，每個人都承諾會使用最高階別的加密軟體，但同時卻堂而皇之地和所有人分享你的資訊。不過你也不用擔心。

結果往往是你得在這個專案上花上比你預計更多的精力和做更多的工作。這就是信任的代價。

殘酷的開發真相No.9: 軟體有一定的生命週期

當你開工做新專案的時候，往往會利用最新出來的版本庫等一切資源。這時庫A的1.0.2版本出來了，但是它不能與庫B的最新版本相容，因為庫A的程式設計師還停留在以前的釋出上。然後庫C釋出了一些你的老闆真正需要你挖掘的新功能。當然這些功能僅適用於1.0.2版本。

如果說房子和船的腐爛是以一種潛移默化“潤物細無聲”的方式，那麼程式碼就是以一種複雜又迅猛的形式轟然倒塌。如果你想要庫C，那麼就必須放棄庫B，同樣的，如果你選擇了庫B，你就不得不向你的老闆解釋為什麼不就近直接利用庫C的原因。

當然我舉的這個案例僅僅包含三個庫，但事實上，在現實專案裡起碼不下十個，而且問題更多。更糟糕的是，很多時候這種消亡的趨勢我們還一下子看不出來。有時候甚至看上去是那麼微不足道的一個小問題，感覺寫點程式碼就能立馬解決。但是往往就是這麼一個細小的不相容性會猶如白蟻一般吃光所有的一切直到大廈坍塌。

生命週期的存在讓我們能更深刻的理解計算機。不要以為程式碼沒有摩擦、沒有氧化、沒有微生物的繁殖，就是永恆的，就能永垂不朽，事實並非如此。

殘酷的開發真相No. 10 : 在圍牆中生存發展

即使我們一再強調開放的重要性，但是有越來越多的證據表明，市場依然很小。而更糟糕的是，很多人往往不願意在這方面投入成本。一些免費軟體倡議者堅稱社會應該提供免費軟體。總之很少有人願意在軟體上面花錢。

這可能就是為什麼Linux和BSD最大的採用者會將其專有程式碼隱藏起來的原因。類似於TiVo的裝置可能內部也會使用Linux，但是使它們顯得與眾不同的介面卻並不開放。Mac同樣如此。

隨便說一句，現在的Linux系統明顯比不過Windows系統。人們會想同樣的錢這邊只夠買Linux系統，那邊我都可以買到Windows電腦了，裡面系統怎樣有什麼關係呢？使用者如何選擇可想而知。

我只是希望以後會有越來越多的人願意在軟體上為許可證付錢，這樣我們這一行業才能在這種四面圍牆的條件下生存發展。