Street coder 1.4.1 -1.4.2

原文:http://livebook.manning.com/book/street-coder/chapter-1/19 

譯：祝坤榮

Cátia Matos圖片: http://www.pexels.com/zh-cn/photo/1072179/

1.4.1 太多的技術

我們持續對於最佳技術的追求源自銀彈的謬論。我們認為有一種技術能成倍提升我們的生產力。其實並沒有。比如，Python是一種解釋語言。你不需要編譯Python程式碼-它可以立即執行。更好的是，你不用指定變數的型別，能讓你更快，所以Python一定是個比C#更好的技術，對嗎？未必。

由於你沒有花時間宣告你程式碼的型別並編譯它，你錯過了剛寫的錯誤。這意味著你只能在測試或生產環境才能發現它們，這比簡單編譯原始碼成本高多了。大多數技術都是提高生產力的一種權衡。提高生產力的是你對技術和技巧的熟練程度，而不是你正在用什麼技術。是的，是有更好的技術，但它們不會產生數量級的差距。

在1999年時當我想要開發我的第一個互動式網站時，我完全不知道如何寫一個網路應用。如果我開始試著搜尋最好的技術，那我會要自學VBScript或Perl。相反，我用了我最熟悉的Pascal。這是為這個目的最不適合的語言，但它能工作。當然，會有很多問題。當程式掛了，程序仍然會在加拿大某臺隨機伺服器上的記憶體中存活著，使用者每次都要打給服務提供商並讓他們重啟物理伺服器。儘管如此，由於我很熟悉，Pascal能讓我快速開發一個原型。不需要經過個把月的開發和學習，我可以只花三個小時寫完併發布程式碼。

希望你也能通過自己的方式使用適合自己的工具。

1.4.2

我記得最早的程式設計正規化就是1980年的結構型程式語言。結構化程式語言基本上是按像函式和迴圈這種結構塊來寫而不是按行號，GOTO語句， 血，糖和眼淚。它讓你讀和維護程式碼都很簡單，不需要犧牲效能。結構化程式設計激發了我對像Pascal和C這樣語言的興趣。

在我學習結構化變成至少5年後，我遇到下一個正規化：面向物件程式設計，或OOP。我記得在那時，電腦類雜誌並不多。這是一個能讓我們寫比以前結構化程式設計更好的程式碼的大事。

在OOP後，我想我可能會在每五年遇到一個新的正規化。實際上它們出現的更快。1990年出現了使用託管型JIT編譯的Java語言，JavaScript網頁尾本， 20世紀90年代，隨著Java的出現，我們接觸到了經過編譯的託管程式語言，以及在90年代末突然變得主流的函數語言程式設計。

到了2000。下個十年，我們看到了更多使用分層的應用。富客戶端。瘦客戶端。泛型。MVC，MVVM，MVP。非同步式程式設計開始引入promises，futures，最後，響應式程式設計。微服務。類似LINQ這種更多的函數語言程式設計概念，模式匹配和不可變讓它進入了主流程式語言。這是一場流行語的龍捲風。

我還沒有列舉設計模式或最佳實踐。我們有關於幾乎所有主題數不盡的最佳實踐，小技巧。有許多宣言寫了為什麼我們要用tab或者空格來縮排原始碼，關於這個很明顯最後的答案是空格。

我們假設通過一個正規化，一個模式，一個框架，或一個工具庫來解決我們的問題。考慮到我們面對問題的複雜性，這是不現實的。而盲目的使用這些工具會在未來製造更多問題：它們可能會引入新的需要學習的領域知識和特定的一些bug。它們甚至可能讓你改變設計。這本書會讓你在程式碼審查時讓你正在正確的使用模式更自信。

本文來自祝坤榮(時序)的微信公眾號「麥芽麵包」，公眾號id「darkjune_think」

開發者/科幻愛好者/硬核主機玩家/業餘翻譯 轉載請註明。

微博:祝坤榮 B站: http://space.bilibili.com/23185593/

交流Email: [email protected] ^[1]

References

[1] [email protected]:  mailto:[email protected]