以前，開發人員寫的彙編程式碼輕巧而且執行速度快。運氣好的話，如果預算充足，他們可以僱傭一些人來幫助完成這些程式碼的輸入。運氣不好的話，只能靠自己完成複雜的輸入工作。
現在，開發人員要和分佈在不同大洲的團隊成員一起工作，這些成員使用不同字符集的語言，更壞的情況是有的團隊成員可能會使用不同版本的編譯器。一些程式碼是新編的，一些庫是從很多年前建立的，原始碼已經無法獲得。所以，要想成為一個程式設計師，必須要擁有團隊精神和吃苦耐勞的信念。
下面我們就來梳理一下正在改變基本開發工作的 15 種科技技術。這些技術改變著我們與其他團隊成員的合作方式，與客戶的溝通方式以及我們的程式設計方式。
1、持續整合（Continuous integration）
當把程式碼提交到庫中以後，你就有足夠的時間休息一下，喝杯咖啡，甚至可以去吃個午飯。這個時候，程式碼庫已經與一個持續執行的編譯系統繫結，開始重新編譯你提交的程式碼，仔細檢查你的程式碼結構，初始化多個測試程式，標記你程式碼中可能的問題。在離你辦公桌 5 英尺的範圍內，編譯系統就通過郵件或簡訊將需要修復的問題發到你的手機上。重新回到工作崗位，持續執行的編譯系統又有新的任務給你了。
2、架構（Frameworks）
通過複製別人的工作進而站在巨人的肩膀上已經不是什麼新鮮事了，但是優勢卻從來沒有像現在這麼明顯。現在只有很少的程式設計工作是從頭做起了。最好也是最有爭議的開發方法是：利用一個正確的框架，研究清楚 API，然後自己寫程式碼使用 API 完成最核心的功能。網頁不再是由 HTML 或者 CSS 生成的了；更多的是開始使用 Ext JS，Express JS 或者其它程式碼庫作為編碼的基礎。
當然，你也可以創新並且從頭開始構建所有的東西，但那是相當痛苦的。你沒有辦法趕上其他人做的所有工作。你不是一個技工，僅僅是一個框架修理工。在你打算自己編碼之前，先了解一下已經正在使用的框架。
3、程式碼庫（Libraries）
和框架類似的是程式碼庫，程式碼庫無處不在，程式設計師已經離不開它了。寫關於瀏覽器的程式碼可以不用 jQuery 嗎？是否有人記得有一個內建函式 GetElementByID？像 jQuery 這樣的庫現在應用在各個層面。人們會談論他們喜歡的語言，但是確很少談論他們是怎麼程式設計的。如果你想僱傭一些程式設計師，你應該多問他們一些關於程式碼庫的知識。Java 指令碼的開發人員是從 jQuery 或 Dojo 發展來的嗎？遊戲開發人員可能會使用 C++，但是實際的問題是這些開發人員是否知道 Allegro，Unity，Corona 或者其他更多的選擇。程式碼庫的知識和語言本身的來龍去脈一樣重要。
4、應用程式程式設計介面（APIs）
從前，程式設計師總需要關注資料結構。他們需要將所有的資訊打包成位元組塊，確保將值放在正確的偏移位置。現在，編譯程式為我們做了這些。
現在我們通過非常嚴謹的介面工作，它有一個發燒友一樣的名字：應用程式程式設計介面。它通常在一個完全不同的機器上或是執行在其他公司的，每次呼叫都需要收費。你想將一個街道地址和一個郵政編碼變成經緯度嗎？有專門的 API 介面可以呼叫，並且使用的費用也相當便宜。
很多情況下，資料不需要這麼死板的打包。舊的位元組打包方式已經被輕量級的資料交換格式例如 JSON 或 XML 取代。你需要確保你的資料格式完全正確，幸運的是有現成程式碼庫可以用。
5、平臺即服務（Platform as a service）
誰建立了自己的網站？相反的，如何在別人的網站上建立一個使用者賬戶，並做一些定製呢？所有的這些僅僅需要的是一個網站，這樣，你的站點就可以做你想做的所有事情了，比如往 Youtube 上傳一個貓的視訊或者在 eBay 上競標一個佩斯飲水機。
當然，這個例子有點誇張。許多 PaaS 選專案前都要求程式設計師清楚的知道每個 Web 表單上放什麼東西。以微軟的雲服務為例，你可以將用 Java 指令碼語言寫的用於描述網站如何響應的函式放到上面。然後，這個雲服務會將這些函式打包成一個庫然後放在 js 節點上執行。
6、瀏覽器（Browsers）
曾經有一段時間人們分別寫桌面軟體，伺服器軟體和裝置上執行的軟體，這些軟體都是不一樣的，軟體之間相互傳遞資訊的方式也互不相同。現在，所有的這些都使用瀏覽器了。當我在家裡建立一個本地檔案伺服器來存放音樂，就可以通過一個網站登入到這個網址上。蘋果的桌面視窗程式是用 Java 指令碼和超文字標記語言寫的，已經用了很多年。很多用超文字標記語言和 Java 指令碼寫的移動客戶端的跨平臺應用都和 Apache Cordova 繫結了。
當然，很多應用還在繼續使用 C/S 結構。最好的遊戲仍然使用客戶端模式，沒有使用瀏覽器，但是隨著越來越多的 Java 指令碼開發者研究在畫布上繪圖這種情況正在改變。例如，憤怒的小鳥，就即將執行在瀏覽器視窗上。
7、應用程式容器（Application containers）
專門建立一個伺服器來做比較困難的工作。程式設計師可以從伺服器上獲取程式碼然後執行，並且將執行日誌傳送到服務端。有時候可以得到正確的庫，有時候得到的庫是錯誤的，但最終，都會找到可用的程式碼庫。
現在，類似 Docker 這樣的應用程式容器允許我們按一個按鈕就找到正確的庫。如果這個程式碼庫可以執行在我們的測試機上，它也可以執行在伺服器上。所有的東西都捆綁在一起了，那些夾在我們桌面和服務之間不相容的東西都不存在了。
8、基礎設施即服務（Infrastructure as a Service）
我提到過伺服器策展人團隊嗎？這些人喜歡在午餐時間或下班後出去玩，但是現在他們都被聚集到了雲上，像是在一個全球的資料中心那樣為那些自認為是雲世界中的領導者的公司工作。少數開發人員會需要服務團隊為他們的新工程搭建一個新的服務。他們只需要登入一個站點，按一個按鈕，就可以得到一個為他們服務的機器。特別簡單，但是這些 IaaS 管理網頁不會在工作結束後為你買一杯咖啡。當然，它能為你節省很多工作。
9、Node.js 和 JavaScript（Node.js and JavaScript）
在你們中的一些人出生以前，網路伺服器送出靜態的 HTML。後來，有人就開始研究如何構建動態的，可以和資料庫互動的伺服器。每個團隊都需要一個人用 SQL 語言編寫資料庫程式，一個人用 PHP 或 Java 編寫服務程式，一個人設計 HTML 模板。一旦每個人都開始喜歡上執行在客戶端的 AJAX 和 Java 指令碼，這個網站就需要一個會這種語言的人。
現在 Java 指令碼做了所有的事情。當然，瀏覽器用 Java 指令碼，服務端（Node.js）和資料庫（MongoDB 和 CouchDB）也一樣。即使是 HTML 也通常是用 Ext JS 或者 jQueryMobile 這樣的框架，使用 Java 指令碼在客戶端生成的。
10、二級市場（Secondary marketplaces）
如果你想構建一個遊戲，你可以自己僱傭一些設計人員，建立一個非常棒的模型集。你甚至可以僱傭一些開發人員為你的遊戲增加一些視覺效果，讓遊戲看起來更酷。或者你可以去類似統一資源市場的二級市場購買你需要的所有部分。當我寫這些的時候，構建下水道的場景的工具箱正降價 30%，可以用來構建小型的或大型的遊戲場景。這個銷售活動在你看見這則新聞的時候可能已經結束了，價錢可能已經升到 45 美元了。開發人員和設計人員怎麼會有這麼低的價錢！
現在有越來越多的提供外掛，庫和其它附加軟體的市場。有這麼多的庫和框架，開發人員也越來越多的去購買所需要的部分，編碼工作越來越少了。
11、虛擬機器（Virtual machines）
編寫大段程式碼的時代已經慢慢遠去了。現在大部分寫出來的執行在虛擬機器上的程式碼都被翻譯成晶片可以識別的指令了。Java 虛擬機器，C#/.Net 虛擬機器，現在的 JavaScript 引擎都是程式碼的最終執行載體。
虛擬機器的流行，使得這個領域吸引了越來越多的東西。過去，如果你想創造一種新的語言，你需要建立從處理器到暫存器的整個流程。現在，新的語言執行在舊的虛擬機器上。Clojure，Scala，Jython，JRuby 都參與了虛擬機器開發的工作，現在這個虛擬機器業務是屬於 Oracle 的。
相似的情況也出現在瀏覽器領域。使得，你可以建立你自己的瀏覽器和語言，也可以通過價差編譯在 Java 中模擬。現在很多新建立的指令碼語言也是這麼做的。谷歌的 Web 工具包也有類似的功能：將 Jave 語言轉換成 Java 指令碼。
12、社交媒體網站（Social media portals）
在網際網路的早期，你可以搭建一個自己的網站，然後祈禱人們可以找到它。他們需要記住你的網址。
越來越多的網站被吸引到網際網路世界中，湧現出了非常多的社交網站和營銷網站。如果你建立自己的網站，很可能門庭冷落，大部分使用者都在社交網站和營銷網站上瀏覽、點選。解決這個問題的辦法是搭建一個社交網站或銷售網站的應用，通過這種方式可以進入並整合到這些網站中。但是最後，你的應用也僅僅是一個附庸，會受到很多限制，還很可能會被輕易停掉。你還有別的選擇嗎？沒有，你要麼選擇做大型網站的附庸，要門只能接受門庭冷落的現實。
13、開發工具（Devops tools）
很久以前，我們僅僅需要在一個伺服器上安裝軟體就能滿足應用需要。但是現在，我們要租用大量的伺服器，需要幾十，成百，甚至上千臺機器，其中很多機器都需要按照需求配置，已經不是一個能用手工完成的工作了。
進入運維模式，就會有一些類似 Chef 和 Puppet 這樣的工具幫助你完成這些複雜的工作。將軟體推送到雲端，在這些工具的控制下，可以保證所有的機器上執行的是相同的程式碼。這些工具替自動完成了我們以前在一臺機器上的工作。
有一些服務，例如谷歌應用程式引擎已經在內部處理了這些，你需要做的僅僅是將你的應用程式告知引擎，並授權它開始工作。你甚至不知道後臺到底發上了什麼，你能看見的僅僅是 CPU 的佔用量。
14、GitHub，SourceForge 和程式碼共享（GitHub, SourceForge, and social code sharing）
程式碼共享網站可能是開源世界的最大貢獻。在 SourceForge 出現之前，軟體僅僅是在你的機器上建立並且程式碼也只屬於你。如果另一些人想獲得原始碼，他們需要找你來獲得原始碼，當然必須要得到你的統一。
現在程式碼共享已經變成了一種共識。類似 SourceForge 和 GitHub 這樣的網站釋出了所有的程式碼，供所有人閱讀和更新。他們為程式碼的維護、共享、評論提供了一個易於訪問的地方。你可以通過一個入口閱讀這些程式碼，並提出修改意見。很多專案每個星期可能有幾十甚至幾百萬的下載量，這在以前是不可能的。
這種模式非常有優勢，很多自營專案都使用這種模式。GitHub and BitBucket 這些網站還在一定程度上支援他們售賣自己開發的程式碼庫。
15、效能監控（Performance monitoring）
早期，跟蹤程式碼效能是一件非常容易的事。在程式碼執行的初始位置列印一個時間，然後在執行結束的位置列印一個時間。如果你想，你還可以把這兩個時間做一個差，然後列印出來。很多問題在一臺機器上是無法暴露出來。在程式碼上附加一個分析器可能無法暴露出真正的瓶頸，導致這種瓶頸的的原因可能是內部的一些複雜問題或者是資料庫延遲。現在測試網路效能的工具不僅要測試軟體本身，還需要測試軟體中的每個模組。這是瞭解內部執行是否正常的唯一方式。當程式從在一個機器上執行演變成通過網路互相連線執行後，這是一種判斷程式執行是否正常的非常重要的方式。
英文原文：15 technologies changing how developers work
來自：CSDN
相關閱讀
評論(2)