讓你編程得到升華：開發者需知的十個真理

　　編程是一種有益的體驗方式，當遇到挑戰時，我們會不斷尋求新的解決方法。也許你會認為將毅力、直覺、適宜的工具三個組合在一起即可編寫出優雅、完美的代碼。然而，隨之而來的拙劣的部署或另一種功能需求亦或者是沉重的依賴關系會產生不良的迭代更新，等等這些突發狀況會摧毀了你最初的夢想。

　　我們希望每次的努力付出能夠有著深遠的影響，希望我們的應用程序所依賴的服務器如同磐石一樣，然而編程的獲取方式卻是殘酷的。這並不意味著你所有的努力都是有價值的。相反，我們應該學會如何面對這些殘酷的事實。一起看下文中羅列出的10條實踐真理，或許能為你的工作帶來一絲幫助。

　　1. 如果這一切只是if-then-else語句

　　開發者往往會因封存(closures)、字節(typing)和抽象化(amazing abstractions)而爭論不休，最終會選擇 old if-then-else statements，這幾乎是所有開發者的需求，包括輸入輸出內存移動數據的操作代碼和算法操作代碼。剩下的便是將分支或非分支兩者之間進行比較。

　　圍繞if-then-else statements，開發者們開始為其添加一些奇妙的虛偽的外表，但在最後，聰明的統計推薦引擎會在矩陣的數組列表中選出的最大值或是最小值，該引擎通過執行計算浏覽所有的列表，直到你作出最後選擇，否則它會一直提示你“這是最大值嗎，這是最大值嗎?”

　　2. 大多數Web網頁將數據存儲在表單中

　　在過去的20年裡，互聯網世界帶來了神話般的財富，更好的友誼，更便宜的產品，更快的通信等等。究其核心，大部分互聯網將數據存儲在表單中。

　　Match.com?表單裡包含著各種信息，比如頭發顏色，宗教信仰和鐘愛的食品。eBay?這個列表收集了最高價的項目列表。Blogs?字裡行間記錄了每一個投訴。OK，我們將其命名為table。我們有理由相信互相網是一個神秘的且充滿智慧的地兒，它是一個自動化的文件文件“辦事員”。

　　從編程語言來看，Ruby on Rails這個貫穿Web開發最流行的語言之一，是一個數據庫框架。你只需要指定一個全局的變量和Rails就可為你創建一個列表，因為它熟悉所有創建表單的數據庫表。

　　還有一個， NoSQL非關系型的數據庫。現今的計算機體系結構在數據存儲方面要求具備龐大的水平擴展性，而NoSQL致力於改變這一現狀。目前Google的BigTable和Amazon 的Dynamo使用的就是NoSQL型數據庫。

　　3. 用戶有自己的主見

　　如果你想為語言和labeled“save”創建event listener監聽事件，將程序拷貝到磁盤上。在現實中，用戶會期待看到一個神奇的按鈕，在自己損壞的文件中修復所有的錯誤或添加到401(k)中，點擊打開並永遠保存下來。

　　或許，用戶還會這樣想，我們創造了一個完美的機器，每當用戶打開時，每一個設計都是萬無一失的，避免出現任何一個故障。他們設想可以點擊發送並未存儲在磁盤上的數據。所有這些完美的設計，他們想通過一種方式來點擊任何被他們所遺忘的東西。

　　有時，用戶是通情達理的，但在大多數情況下，他們是非常苛刻的，行為較為古怪。程序員嘗試著去猜測他們的想法，當以最終的代碼結果呈現在用戶面前時，他們會是怎樣的?結果還是失敗了。因為大多數用戶不是程序員，他們要求程序員像普通用戶的那樣思考問題就如同要求一只貓像一只狗那樣思考一樣，這根本就不符合邏輯思維。

　　不管你如何發明智能的或設計出優雅的代碼，用戶不會按照你的想法來看待問題。因為他們不會用140個字符限制來表達他們的憤怒和欲望。

　　4. 部分代碼永遠不會被使用

　　你的工具是否支持XML，CSV，Aramaic。我們的操作團隊能否解析瑪雅象形文字，也許在2012年年底有這方面的需求，如果不具備該功能，ok，如果你能提供此項功能，將會獲得更多的項目訂單。

　　當然，用戶不用關心太多，他們只想要一個按鈕，這個按鈕甚至可以把他們混淆了。這個完美的代碼當你在編譯時能夠支持N-1按鈕，在QA團隊中能夠很好的被執行。

　　程序員不像藝術家，他們可以指望自己的父母或者親戚能為其帶來某些業績，而我們的父母不會通過執行代碼來測試性能。

　　5. 項目發生變化不可避免

　　一位經理人曾告訴我有關他的秘密，他總是面帶微笑並告知他的團隊，他很熱愛他們所作的事情即便是有危險的，在他走出門的那一刻，他會說“哦，還有一件事”。那個弧線球部分覆蓋了該項目，並要求大家重新設計應用程序。意思說作為一名管理者首先你得肯定團隊的工作能力。

　　項目范圍的擴張程度直接體現了這個項目結構的最終成果。經理人總是使出全身解數來清算報表，首先他們構思出一個偉大的夢想，建立一個經濟結構模型來證明他們需要多少投資預算。

　　開發者們辛勤付出後，將勞動成果呈現在經理人面前，你的經理人什麼也沒做反而擔心：這個按鈕是在正確的位置嗎?日志頁面看起來有什麼不同之處?即便是輕微的意見，它也改變了我們最初的需求，不是嗎?

　　6. 沒人理解你——尤其是老板

　　有兩種程序員：一個是按照老板指定的計劃進行工作，沒有任何計劃，也不知道如何努力編寫代碼;另一種是以程序員方式全身心的投入工作，努力編寫出色的代碼。

　　你的老板永遠不會理解你或者你的工作，他們關注的是當業務發展遇到瓶頸時刻時你能否給出一個出色的解決方案，而不是你解決了計算機芯片等某種問題。

　　如果你的老板知道如何解決問題，他會留下來並將問題解決。因為他知道與你交流，刨根問底要比實際操作花費的時間要多的多。

　　7. 隱私權是一種痛苦

　　我們希望我們的服務能夠保護用戶以及他們的信息(隱私問題)，同時又希望網站能夠簡潔易操作，我們希望能用最少的點擊數來達到用戶想要的目的。

　　隱私意味著你要多挖掘幾個問題，這樣才能確保控制信息擴散，然而這樣也就意味著我們需要有更多的點擊數。隱私也體現出一種責任，如果用戶不希望服務器知道他們過多的隱私，而服務器又無法讀取用戶的想法，怎麼辦呢?所以說，責任是一種麻煩，隱私也是件麻煩事。

　　當然，它也有有利的一面，比如說根據你的喜好，網站可以自動提供鏈接，讓你隨心所欲買到自己喜歡的物品，當你有需求時可以為你提供幫助。

　　8. 與他人建立信任

　　Web 2.0的誕生，豐富了人們的生活，這種新的互聯網方式，通過網絡應用 (Web Applications)促進網絡上人與人間的信息交換和協同合作，其模式更加以用戶為中心。因此，你只需將代碼鏈接給某人，就會有奇跡發生了，你的代碼會被調用。

　　首先，在別人使用你的代碼前，請先填好這些協議，在多數情況下，該協議會要求你放棄一切，那麼你會得到什麼回報呢?其次，和用戶建立信任，在基於該協議下每個人都會承諾最佳的實踐方法和最高的加密軟件來分享你的信息。因此，不用擔心你的代碼會被竊取。

　　最終的結果會比你預期的要好的多，比如會給你提供更多的工作。期待好運降臨吧。

　　9. 當代碼遭遇腐爛

　　當你啟動任務時，你可以獲取最新版本庫，利用這些庫來工作一至兩周，那麼將誕生library1.0.2版本，當然你不會使用library B最新版本，因為使用A版本的程序員已經更新了新版本，這時你的老板還會要求你在C版本的基礎上開發出一些新的功能，當然只適用於1.0.2.版本。

　　打個比方，當房子和船要腐爛時，他們會以統一的方式腐爛。很多團隊都有這個問題，一個項目的代碼本來開始設計得好好的，一段時間以後，代碼就會變得難以理解，難以維護，難以修改。為什麼呢?因為代碼的腐爛都是由於沒有深入理解的情況下修改別人的代碼導致的。如何防止代碼腐爛?

　　如果你想要C，那麼必要放棄B。如果你選擇B，那麼你就必需要告訴你的老板C是不正確的選擇。

　　我們以3個庫為例，但在實際項目中會有十幾個甚至更多的選項，問題也會隨之成倍的增長。更糟糕的是，腐爛不會立即呈現。有時隱藏在某個角落裡，看起來是個不起眼的問題，時間久了就會感染到整個代碼。正是這細小的不兼容的代碼會毀掉整個系統。

　　我們應該讓代碼像諺語一樣即使是在100年後依然完整無缺。

　　10. 開源世界茁壯成長

　　越來越多的數據表明開源的重要性，目前，開源只有一小部分市場，極少部分人願意將代碼貢獻給開源社區。

　　這也許就是Linux和BSD代碼的最大貢獻者們轉為封閉私有代碼的原因。像TiVo這樣的設備也許會使用Linux作為內核，但絢麗的交互界面卻不是開源的，Mac也同樣如此。

　　近日，Linux boxes與Windows boxes之間的競爭陷入了困局。很多人都在質疑：花一樣的錢，既然能夠買到一個可以安裝Linux的Windows機器，為什麼還去買Linux 呢?Mac筆記本的價格是普通PC的2至3倍等等這種案例很多越多。然而只有極少部分人知道，iPhone也是一款開源操作系統。

　　我想，只有人們不斷的去關注開源哪怕只是細微的性能部分，開源世界才會茁壯成長。

　　英文出自：infoworld

　　翻譯地址：CSDN