讓你編程得到升華：開發(fā)者需知的10個真理

我們希望每次的努力付出能夠有著深遠的影響，希望我們的應用程序所依賴的服務器如同磐石一樣，然而編程的獲取方式卻是殘酷的。這并不意味著你所有的努力都是有價值的。相反，我們應該學會如何面對這些殘酷的事實。一起看下文中羅列出的10條實踐真理，或許能為你的工作帶來一絲幫助。
1. 如果這一切只是if-then-else語句
開發(fā)者往往會因封存（closures）、字節(jié)（typing）和抽象化(amazing abstractions)而爭論不休，最終會選擇 old if-then-else statements，這幾乎是所有開發(fā)者的需求，包括輸入輸出內(nèi)存移動數(shù)據(jù)的操作代碼和算法操作代碼。剩下的便是將分支或非分支兩者之間進行比較。
圍繞if-then-else statements，開發(fā)者們開始為其添加一些奇妙的虛偽的外表，但在最后，聰明的統(tǒng)計推薦引擎會在矩陣的數(shù)組列表中選出的最大值或是最小值，該引擎通過執(zhí)行計算瀏覽所有的列表，直到你作出最后選擇，否則它會一直提示你“這是最大值嗎，這是最大值嗎？”
2. 大多數(shù)Web網(wǎng)頁將數(shù)據(jù)存儲在表單中
在過去的20年里，互聯(lián)網(wǎng)世界帶來了神話般的財富，更好的友誼，更便宜的產(chǎn)品，更快的通信等等。究其核心，大部分互聯(lián)網(wǎng)將數(shù)據(jù)存儲在表單中。
Match.com？表單里包含著各種信息，比如頭發(fā)顏色，宗教信仰和鐘愛的食品。eBay？這個列表收集了最高價的項目列表。Blogs？字里行間記錄了每一個投訴。OK，我們將其命名為table。我們有理由相信互相網(wǎng)是一個神秘的且充滿智慧的地兒，它是一個自動化的文件文件“辦事員”。
從編程語言來看，Ruby on Rails這個貫穿Web開發(fā)最流行的語言之一，是一個數(shù)據(jù)庫框架。你只需要指定一個全局的變量和Rails就可為你創(chuàng)建一個列表，因為它熟悉所有創(chuàng)建表單的數(shù)據(jù)庫表。
還有一個， NoSQL非關系型的數(shù)據(jù)庫。現(xiàn)今的計算機體系結構在數(shù)據(jù)存儲方面要求具備龐大的水平擴展性，而NoSQL致力于改變這一現(xiàn)狀。目前Google的BigTable和Amazon 的Dynamo使用的就是NoSQL型數(shù)據(jù)庫。
3. 用戶有自己的主見
如果你想為語言和labeled“save”創(chuàng)建event listener監(jiān)聽事件，將程序拷貝到磁盤上。在現(xiàn)實中，用戶會期待看到一個神奇的按鈕，在自己損壞的文件中修復所有的錯誤或添加到401(k)中，點擊打開并永遠保存下來。
或許，用戶還會這樣想，我們創(chuàng)造了一個完美的機器，每當用戶打開時，每一個設計都是萬無一失的，避免出現(xiàn)任何一個故障。他們設想可以點擊發(fā)送并未存儲在磁盤上的數(shù)據(jù)。所有這些完美的設計，他們想通過一種方式來點擊任何被他們所遺忘的東西。
有時，用戶是通情達理的，但在大多數(shù)情況下，他們是非�？量痰�，行為較為古怪。程序員嘗試著去猜測他們的想法，當以最終的代碼結果呈現(xiàn)在用戶面前時，他們會是怎樣的？結果還是失敗了。因為大多數(shù)用戶不是程序員，他們要求程序員像普通用戶的那樣思考問題就如同要求一只貓像一只狗那樣思考一樣，這根本就不符合邏輯思維。
不管你如何發(fā)明智能的或設計出優(yōu)雅的代碼，用戶不會按照你的想法來看待問題。因為他們不會用140個字符限制來表達他們的憤怒和欲望。
4. 部分代碼永遠不會被使用
你的工具是否支持XML，CSV，Aramaic。我們的操作團隊能否解析瑪雅象形文字，也許在2012年年底有這方面的需求，如果不具備該功能，ok，如果你能提供此項功能，將會獲得更多的項目訂單。
當然，用戶不用關心太多，他們只想要一個按鈕，這個按鈕甚至可以把他們混淆了。這個完美的代碼當你在編譯時能夠支持N-1按鈕，在QA團隊中能夠很好的被執(zhí)行。
程序員不像藝術家，他們可以指望自己的父母或者親戚能為其帶來某些業(yè)績，而我們的父母不會通過執(zhí)行代碼來測試性能。
5. 項目發(fā)生變化不可避免
一位經(jīng)理人曾告訴我有關他的秘密，他總是面帶微笑并告知他的團隊，他很熱愛他們所作的事情即便是有危險的，在他走出門的那一刻，他會說“哦，還有一件事”。那個弧線球部分覆蓋了該項目，并要求大家重新設計應用程序。意思說作為一名管理者首先你得肯定團隊的工作能力。
項目范圍的擴張程度直接體現(xiàn)了這個項目結構的最終成果。經(jīng)理人總是使出全身解數(shù)來清算報表，首先他們構思出一個偉大的夢想，建立一個經(jīng)濟結構模型來證明他們需要多少投資預算。
開發(fā)者們辛勤付出后，將勞動成果呈現(xiàn)在經(jīng)理人面前，你的經(jīng)理人什么也沒做反而擔心：這個按鈕是在正確的位置嗎？日志頁面看起來有什么不同之處？即便是輕微的意見，它也改變了我們最初的需求，不是嗎？
6. 沒人理解你——尤其是老板
有兩種程序員：一個是按照老板指定的計劃進行工作，沒有任何計劃，也不知道如何努力編寫代碼；另一種是以程序員方式全身心的投入工作，努力編寫出色的代碼。
你的老板永遠不會理解你或者你的工作，他們關注的是當業(yè)務發(fā)展遇到瓶頸時刻時你能否給出一個出色的解決方案，而不是你解決了計算機芯片等某種問題。
如果你的老板知道如何解決問題，他會留下來并將問題解決。因為他知道與你交流，刨根問底要比實際操作花費的時間要多的多。
7. 隱私權是一種痛苦
我們希望我們的服務能夠保護用戶以及他們的信息（隱私問題），同時又希望網(wǎng)站能夠簡潔易操作，我們希望能用最少的點擊數(shù)來達到用戶想要的目的。
隱私意味著你要多挖掘幾個問題，這樣才能確�？刂菩畔�擴散，然而這樣也就意味著我們需要有更多的點擊數(shù)。隱私也體現(xiàn)出一種責任，如果用戶不希望服務器知道他們過多的隱私，而服務器又無法讀取用戶的想法，怎么辦呢？所以說，責任是一種麻煩，隱私也是件麻煩事。
當然，它也有有利的一面，比如說根據(jù)你的喜好，網(wǎng)站可以自動提供鏈接，讓你隨心所欲買到自己喜歡的物品，當你有需求時可以為你提供幫助。
8. 與他人建立信任
Web 2.0的誕生，豐富了人們的生活，這種新的互聯(lián)網(wǎng)方式，通過網(wǎng)絡應用 (Web Applications）促進網(wǎng)絡上人與人間的信息交換和協(xié)同合作，其模式更加以用戶為中心。因此，你只需將代碼鏈接給某人，就會有奇跡發(fā)生了，你的代碼會被調(diào)用。
首先，在別人使用你的代碼前，請先填好這些協(xié)議，在多數(shù)情況下，該協(xié)議會要求你放棄一切，那么你會得到什么回報呢？其次，和用戶建立信任，在基于該協(xié)議下每個人都會承諾最佳的實踐方法和最高的加密軟件來分享你的信息。因此，不用擔心你的代碼會被竊取。
最終的結果會比你預期的要好的多，比如會給你提供更多的工作。期待好運降臨吧。
9. 當代碼遭遇腐爛
當你啟動任務時，你可以獲取最新版本庫，利用這些庫來工作一至兩周，那么將誕生library1.0.2版本，當然你不會使用library B最新版本，因為使用A版本的程序員已經(jīng)更新了新版本，這時你的老板還會要求你在C版本的基礎上開發(fā)出一些新的功能，當然只適用于1.0.2.版本。
打個比方，當房子和船要腐爛時，他們會以統(tǒng)一的方式腐爛。很多團隊都有這個問題，一個項目的代碼本來開始設計得好好的，一段時間以后，代碼就會變得難以理解，難以維護，難以修改。為什么呢？因為代碼的腐爛都是由于沒有深入理解的情況下修改別人的代碼導致的。
我們以3個庫為例，但在實際項目中會有十幾個甚至更多的選項，問題也會隨之成倍的增長。更糟糕的是，腐爛不會立即呈現(xiàn)。有時隱藏在某個角落里，看起來是個不起眼的問題，時間久了就會感染到整個代碼。正是這細小的不兼容的代碼會毀掉整個系統(tǒng)。
我們應該讓代碼像諺語一樣即使是在100年后依然完整無缺。
10. 開源世界茁壯成長
越來越多的數(shù)據(jù)表明開源的重要性，目前，開源只有一小部分市場，極少部分人愿意將代碼貢獻給開源社區(qū)。
這也許就是Linux和BSD代碼的最大貢獻者們轉為封閉私有代碼的原因。像TiVo這樣的設備也許會使用Linux作為內(nèi)核，但絢麗的交互界面卻不是開源的，Mac也同樣如此。
近日，Linux boxes與Windows boxes之間的競爭陷入了困局。很多人都在質(zhì)疑：花一樣的錢，既然能夠買到一個可以安裝Linux的Windows機器，為什么還去買Linux 呢？Mac筆記本的價格是普通PC的2至3倍等等這種案例很多越多。然而只有極少部分人知道，iPhone也是一款開源操作系統(tǒng)。
只有人們不斷的去關注開源哪怕只是細微的性能部分，開源世界才會茁壯成長。