從全棧工程師到全棧整合師：再見，Web2.0時代的英雄

        獵云網 11 月 21 日報道 （編譯：綠島的索拿大）

        全棧工程師，Web2.0 時代叱咤風云英雄。一個人掌握整個平臺的 IT 神話，在當今新開發平臺和個人終端不斷增長和完善的大平臺下又該何去何從？今天，獵云網編輯將帶你探索全棧開發者在變化的需求中的前世今生。

        每個互聯網行業的從業者都曾經對全棧開發者有過各種各樣的幻想。全棧工程師在 Web2.0 時代是每個項目不可或缺的資源，然而，隨著新一代互聯網創業大潮的席來，虛擬空間所呈現的想法到了極致。從人工智能到云服務分析，單個全棧工程師不再可能 統領每一個部門的運營。

        全棧工程師的神話

        在互聯網時代起步之初，因為軟硬件平臺的限制，編輯一個程序往往只需要一名工程師，而使用匯編語言也是工程師作業的唯一規范。然而，隨著 80 年代末在客戶機/服務器處理結構的技術進步和 90 末互聯網浪潮的風靡，編程成為了一個團隊項目。新技術帶來的每一個子項目往往都需要一名專家來運營，而在數據庫、用戶服務器等技術的應用中，每一層級都由 一名專家負責也是很常見的情況。因為這樣的技術革新，運營一個網站變成了一項無比復雜和艱深的工作，全棧工程師也因為這樣的狀況而愈發受到重視。

        隨著技術的不斷革新，到了 21 世紀的頭十年中期，任何程序公司，無論是簡單的網頁制作還是新一代 SaaS 服務平臺的開發，其人工成本都變得無比高昂。人工成本增長的原因很簡單，隨著程序需要涵蓋的技術模塊的增長，單個個體再也不可能同時掌握這么多專門的技 術，保持對他們的更新并且領導這些技術在產品中的應用，因此昔日由一個主棧工程師負責的事物被分割成多個部分分配出去。正如 Mosaic 創始人 Marc Andreessen 所指出的，“隨著程序員的增加，溝通成本大幅上升而溝通效率急劇下降。”

        隨著科技的進步，也有方便的一面。Web2.0 時代通行的代碼變得更加簡潔明晰了，程序員們放棄了陳腐復雜的 Java 包轉而使用直白的 LAMP 組合（Linux， Apache, MySQL, PHP/Python/Perl）；類似 Django 和 Ruby on Rails 這種新語言和框架讓網頁和數據庫之間的交流變得直截了當；例如 jQuery 的前端框架系統讓各個瀏覽器間錯綜復雜的關系變得清晰，類似 Amazon Web Services 的云服務讓物流和新技術觸手可及。

        程序員間在大數據庫、運營支持、服務器邏輯運算等技術服務上的交流和支持體系得到了大幅提升，新一代的全棧工程師的職責就是在林林總總的技術團隊間協調、交流，當技術團隊的數量隨著新技術應用而增加時，相應的增加負責的全棧工程師則會顯著增加團隊間交流效率。

        從全棧工程師到全棧整合師

        當你新建一個頁面時，Image-1 的項目是你第一時間想到索要覆蓋的平臺，一個全棧工程師可以讓這些項目的交流效率大大提高。但隨著科技的發展，這幾個平臺其實并不是真正的“全棧”了，我認為真正的“全棧”應該如 Image-2 這樣。

        我相信沒有人能夠精通上面每一棧的技術并且實時跟進新晉發展還能帶領團隊應用這些到事件當中去。因為僅僅是跟進這些技術的進步就是一項全日工才完成的繁重任務了。

        在我們身處的年代里，技術日新月異的革新，新的突破不斷的發生。僅僅是開發優秀的 iOS 和 Android 應用都需要精通每個平臺的優秀工程師，運營 MongoDB 這種數據庫則需要長時間專注于此的人才，云服務的支持需要云技術的專家，在這個時代，每一個新的子技術都需要專門的人才負責。面對這樣的現實，全棧工程 師，一個能夠理解每個平臺每個服務每個子項目工作原理的人對于企業至關重要。在當下，我認為這樣的人才隨著他的職責改變而從一個全棧工程師變為一個全棧整 合師，一個聯絡各個技術項目組，具有戰略眼光統籌全局的人。

        再見了，全棧工程師，新的時代里，讓我們張開雙臂擁抱全棧整合師吧，IT 行業將會無比的需要你們。

        Source：R&W

                    <span id="shareA4" class="fl">                  
                        </span> 

</div>