程序員的自我修養——遠離“外包思維”

*************************************優雅的分割線 **********************************

分享一波:程序員賺外快-必看的巔峰干貨

在我們做開發的日子里，不免會進行跳槽，跳來跳去公司無非就分成兩大類——互聯網公司、外包公司。當然我們本次討論的并不是外包公司，而是一些外包公司所培養出來的“外包思維”。
什么是 “外包思維”呢？簡單來說，就是由多年外包經歷所影響，逐漸總結出來的一些工作經驗。事實上并不是所有的工作經驗都對大家有幫助，有些工作經驗反而只會坑到你。那么下面我們來看看有哪些常見的“外包思維”吧。

技術是為業務服務的

單看這句話其實說的并沒有毛病，但是不少程序員卻對這句話進行了曲解。
每個技術的出現都有它的適用場景，比如MongoDB是為了解決高負載的讀寫，solr和ES是為了解決全文檢索，ELK整個技術棧的出現是為了解決日志收集，消息隊列則是解耦、解決高并發，redis則是解決緩存、分布式下的共享。。。等等等等。應對不同的業務場景，采用最合適的技術去進行解決，這才是“技術是為業務服務的”這句話本來的意思。
而現在的一些程序員，尤其是常年在外包公司工作的開發者，則對這句話產生了不同的理解。往往他們認為，業務是占主導，只要實現了功能，用什么技術都無所謂。你可以在攔截器中每次都查表校驗用戶token是否準確，你也可以每次加載省市區縣數據的時候都從數據庫里查出這3000多條數據，你還可以將大量的日志都存到數據庫中，在應對全站搜索時，你也可以用一個 where title like '%哈哈哈%' or content like '%哈哈哈%' 這樣簡單粗暴的方式掃描一張幾十萬數據的表。功能實現就行。往往帶有這種思維的程序員，更容易面臨30危機而考慮轉行，因為技術更新換代是非常快的，你永遠也想不到當年火的一塌糊涂的 delphi 現在卻變得無人問津。盡管現在很多框架的底層實現是Servlet，但是不可否認的是，已經沒有什么項目是用純Servlet+JDBC開發的了，如今這些排斥SpringBoot的程序員，會不會像當年那些排斥Ejb、Struts的程序員一樣被淘汰呢。

穩定最重要

單看這句話其實說的也沒什么毛病。技術用的天花亂墜，結果上線經常宕機，用戶使用起來很卡，數據也存在問題，這是非常可怕的。開發一個系統，最重要的就是穩定，上線要平穩運行，要能應對突發的流量，數據要有災備，出了問題可以快速恢復。因此，才需要用ELK從多維度分析日志，才需要用主從復制來進行災備，才需要用MQ應對突發的流量，才需要用緩存來存儲頻繁訪問的大量數據。這些技術棧的引入，就需要有專業的架構師來進行維護、調配，以保證其的穩定。對于有惡性bug的框架（如Struts2），應當及時廢棄，采用更加輕量、高效、學習成本低的技術進行替換，才能保證系統的穩定運行。
而現在不少外包程序員對這句話的理解，則不是系統的穩定，而是框架的“穩定”，簡單來說，就是接到一個類似的系統之后，用現有的框架復制粘貼再稍作修改就可以交付，這樣能夠快速完成一個項目。長期使用一套框架，只要核心人員不變，就能快速上手。“新技術不穩定”這種說法也是因此而來，因為核心員工不會，又不愿意學，拿來做項目無法應對里面的一些小坑。比如從Struts2轉到SpringMVC，如果不知道SpringMVC是單例的，直接把成員變量寫到Controller里，出現線程安全問題之后大談“SpringMVC不穩定”，誰能有辦法。因此你會發現不少的外包技術都很老，甚至于是SSH、Struts1、EJB、JFinal，而前端則是extjs、easyui，以及各種估計70后才知道的UI框架。因為他們覺得，這樣技術復雜度不會提高，即使他們使用的技術已經可以稱之為“古墓派框架”了。畢竟很多電網項目滿天飛的bug都無法修復，最終客戶只能接受當做特性來看待，你跟我談穩定？

進了公司都是CRUD

這個我是完全否定的。
外包公司的工作說白了是流水線工作，只需要實現功能，性能、穩定性、可維護性、擴展性、代碼可讀性等完全不顧，來了新項目就用現有的框架改改就寫，確實做來做去都是CRUD，程序員技術得不到提升，這也是大部分互聯網公司不喜歡招外包經驗開發者的原因之一。
而互聯網公司則不同。初中高級開發者涉及的領域就有所區別。高級工程師雖然有時候也會寫crud，但是更多的時候是參與到架構搭建、技術選型、框架和中間件的研發、高并發問題解決等工作，而在外包公司，初中高級工程師的區別僅僅是薪資的區別，搞來搞去都是CRUD。

框架源碼沒必要讀，上班用不到

就拿Mybatis來說，不看一遍Mybatis源碼，拿頭寫Mybatis插件。

傳參和返回值都用Map

你最好把文檔寫清楚了，詳細到每一個方法的Map都有哪些參數，不然我怕你離職了被下一個接手的人追著砍。

存儲過程、觸發器好用

好用你妹啊，數據庫遷移的時候拿命搞，其他開發者冷不丁就踩個坑，業務放到代碼層面處理會死哦。

遇事不決Oracle

Oracle是一個高性能的大型商業數據庫，這個是很多人對Oracle的第一想法。早期的大型項目，現在的一些金融項目基本都是Oracle數據庫，這也奠定了大多數人對這個數據庫的偏愛，但是就目前來說，Oracle的優勢已經不行了。大廠逐漸的開始去IOE，早在2008年，阿里巴巴就提出了“去IOE”的想法，很多企業覺得癡人說夢，畢竟不存在哪個系統離得開Oracle。而現實卻給了這些企業一個狠狠的大嘴巴子，去IOE很成功，事實上也證實了現在確實需要去IOE。
Oracle的流行，是因為這是個商業數據庫，雖然使用免費，但是提供技術支持需要高昂的費用。早期Oracle在世界各地都有技術支持，一旦你的數據庫出了問題，基本上你都可以在當地找到技術人員來支持，這樣可以保證系統的相對穩定。而前兩年發生的Oracle裁員事件，至少在國內基本沒有多少Oracle的人了，而這個數據庫也就失去了技術支持，它的低位變得比較尷尬——沒有官方的技術支持；不開源。
就數據庫來說，現在更加推薦的就是MySql，如果是大型數據庫的話，可以考慮PostgreSql。都說Oracle性能比MySql好得多，但是比性能沒規定必須比單機性能，一臺MySql性能比不上Oracle，兩臺呢？三臺呢？現在隨便一個開發者，基本都會自己搭建MySQL集群，搞個主從復制、讀寫分離等，也就是說，使用MySql基本都是會集群的，即使現在沒有集群，將來集群也沒什么成本。而Oracle，我想大部分中小型企業都是沒人會搭建集群的，這就意味著使用Oracle只能使用單機版。
至于現在的金融系統還在使用Oracle，那就是歷史遺留問題了，畢竟這類項目，還有電網項目等，都是外包公司做的，這也就印證了上面外包公司認為的“穩定”。換了MySql可能會導致現有的框架不能復制粘貼改改就用，得重新寫，這樣“不穩定”。

結語

實際上，大家所聽到的一些外包思維言論不止這些，這里只是舉了一些常見的例子。找工作、水群的過程中遠離外包思維很重要，長期被這種思維所影響，會使人變得倦怠，從而排斥新事物，最終會消亡在舊事物中，終將迎來30危機。
這里并不是排斥外包公司，只是想說，外包公司只是個起點，或者說只是個體驗，不能作為終點。如果你不幸進了外包，可以在工作之余繼續學習、養精蓄銳，下一波跳槽跳到更好的互聯網企業脫胎換骨。

*************************************優雅的分割線 **********************************