即便沒有翅膀，心。。。。。。也要飛翔

時間 2019-11-13

標籤即便沒有翅膀飛翔简体版

原文原文鏈接

https://blog.csdn.net/lifetragedy/article/details/17721681程序員

企業IT項目開發之七宗罪(下篇）

2014年01月01日 01:01:45

閱讀數：16684

即便沒有翅膀，心。。。。。。也要飛翔！

在新年前一天預祝你們新年好，在新的一年裏工做順利，身體健康。web

前一陣公司給我下達了任務，一直在忙着打造面向SAAS的企業級微信平臺，完全實現零代碼配置，小小一個微信，當面向企業級並且是SAAS時，呵呵，還真的有許多須要注意的地方，很是感謝公司內最強的業務架構師咱們的大姐設計出來這麼優秀的一款全動態微信業務。因此寫完了中篇，一直沒時間來得及寫下篇。面試

下篇的開頭，你們也看到了標題：即便沒有翅膀，心也要飛翔！！！數據庫

爲何提這個標題呢？企業IT項目開發之七宗罪上、中篇你們看後不少人都說：目前形勢就是這樣，有什麼辦法？也有人說：道理都懂，大環境這樣，有什麼辦法。編程

對，對，說得都不錯，咱們沒法去改變環境，咱們天生不是天使，咱們沒有「翅膀，可這就表明咱們要就此淪落嗎？api

NO！安全

咱們的心同樣能夠飛翔！服務器

環境落後沒有關係，可悲的是心態也落後。微信

步入正題

如下我拿一個數據來講明問題，2005-2011年世界上只有3家IT公司保持着每一年利潤超10億美圓，利潤超10億美圓哦，哪三家？網絡

NO1. IBM，拋棄了Laptop後反而更強了，爲何？

NO2. TCS, 塔塔，世界上最大軟件外包，網友們要問了，一個外包，作這麼大，對吧！爲何？

NO3. APPLE，那是勿庸置疑的！

咱們不說APPLE，只說TCS 和 IBM。

IBM，你們若是注意IBM的人會發覺,IBM的WAS系列即Websphere系列經歷了2次變化。

一次是WAS7開始IBM專門規劃出了一個SOA產品區，裏面有Websphere Process Server(ESB）, Business Process Management, IBM iLog規則引擎，TAM，WebSeal，MQ，而後把WAS歸在了這個區。

第二次變化是再次把WPS（Websphere Process Server)，BPM，ilog等又劃出了SOA，歸成了中件間產品。

爲何IBM要對其經典的產品，去作這樣作兩次大的變更呢？咱們放在下文中說，咱們先舉例子，由於太多的道理你可能一會兒不可以去接受，回過頭你再來看，你就會明白了。

歐債危機持續，企業客戶沒錢啦

隨着經濟危機，主要是歐債危機引發了金融保險行業的大規模的蕭調，你們都知道，金融系統的IT每每都是大型的業務系統，當金融業受到了影響，IT業勢必也受到了很大的影響。

那麼咱們國內不少IT公司都是怎麼生存的呢？

國內IT公司在經濟危機以前的生存之道

大部分都是作項目的，或者是賣人頭的，對吧！

就是我前篇講到的學好SSH，貨賣帝王家，SSH滿天飛。

根據客戶的需求，業務要求，作4個月，6個月的開發項目。

有的項目短，作個2個月，搞個項目，而後按照人月數用UCP，FP什麼的estimation方法一估，而後報給客戶多少多少錢。

在歐債危機前，因該是2008年前，或許咱們靠着公司好的名聲，經營之道，管理有方，好的PM，好的客戶關係，或多或少是能夠不斷的接到這樣的單子的。

每每作這樣的單子的時候，咱們用最簡單的「軟件開發生命週期」，就是咱們說的七步曲即：肯定問題、需求分析、設計、開發、測試、佈署上線、維護。

項目管理基本分紅兩種模式：瀑布式項目管理和敏捷項目管理，對吧，這個你們都知道。

關鍵的問題在於這個地方，即無論任何一個需求，項目大小，你都必需要走肯定問題、需求分析、設計、開發、測試、上線、維護，若是在項目中或者是項目後期有超出需求的部分，咱們把它定爲：需求變動，一個需求變動也必需要走完這7七步。走完這七步不算完，還要把之前開發過的代碼和工程再從新測試、佈署、上線。

若是有了BUG，BUG的修改也是要走這七步的，對吧？

由於你的需求變化了，不表明我只完成變動後的部分就完成了任務了，由於你的變動可能會引發我已經開發好的功能上出現了BUG，這個問題想必你們都是碰到過的，這樣的BUG叫Regression Bug。

在經濟危機沒有來時，你這樣作,OK的，客戶理應給錢，由於是他本身要變動需求的嗎，對吧，不然的話你需求變動我也能作啊，可是沒錢所以個人質量就不給你保證，客戶也怕，因此願意掏這個錢。

如今經濟危機來了，企業怎麼生存啊，還能這樣生存嗎？

《哈佛商業評論》上面有一篇文章文章說，IT已經不像之前那麼關鍵了，由於IT的廣泛應用，就像水電同樣，成了一種基礎設施，再也不是企業核心競爭力的來源。

經濟危機，就是企業沒錢啦，沒錢，但IT同樣須要，」再也不是企業核心競爭力的來源「不表明我就不要IT了，不表明技術無用論，這邊的「不要了」只是表明「相關技術的普及"了。

普及就是SSH，J2EE, EJB，Webservice這種東西，你會我會你們都會了。

因而，大量的還在拿SSH作項目的公司面臨着比之前多2倍，不。。。是10倍之多的競爭對手。

因而，你會我會你們會。

因而，大打價格戰，你賣40萬，我賣30萬，成了自由叫賣市場。

因而，工程價格是下來了，GDP上升了，平均工資上升了，程序員的工資仍是要付的。

因而，加班不要錢，會個SSH，工做個5，6年還拿着一個月8K，9K，1萬塊錢到頭了，沒有年終獎了，Team Building取消了。

因而。。。。。。還有不少。

最後，因而，程序員成了民工還不如了，哈哈哈哈哈。

可是，可是，說多了因而還有一個可是。always 有一個可是，導演老是不給咱們一個happy ending，呵呵，像一些美國大片同樣有多個結局哦！！呵呵！！

可是，仍是有一部分企業在這種大環境下脫穎而出，掙足了錢

這些企業越作越好，人頭數就是head count反而年年愈來愈多，在這樣的大環境下，還能持續的掙到錢，這些公司的IT人員反而愈來愈脫離業務愈來愈走技術路線了，反而比原來那些每天「業務業務」掛口頭的公司掙得更多了。

爲何？

這仍是要從客戶的角度去出發。

前面說了，經濟危機，客戶沒錢，項目同樣要作，按照之前那樣，個人一個項目，走完軟件開發生命週期7步，若是有變動再按照瀑布或者是敏捷開發來走一遍需求變動，對不起，客戶受不了。

反正之前的項目已經作了差很少了，新的項目客戶要求的是：

業務上的功能能夠隨時變，當這個變動須要被提出時，若是你是開發商，你說：咱們需求均可以作，給時間，而後咱們翻代碼，對不起啊，客戶不會再讓你這麼作了。

若是你是開發商，你和客戶說：你的需求咱們都能作，而後從新估算，走變動流程的話，告訴你，你從2008年後開始就很難接到新的項目了。

可能，之前你能夠一年接1000萬到2000萬的單，2008年後你可能一年不如一年，一年能接個500萬，300萬就了不起了，有的連100萬的單子都接不到了，真的，因而你就要面臨危機啦！！！

喂喂喂喂，知道了嗎，危機感啊！！！

那有人說了，我業務上的需求功能都變化了，原來是a+b+c*(x/y)如今成了a+b*(x+c-d)了我還不變代碼啊？

業務完全變了我還不改動程序啊，改動了程序後我還不重測試，重佈署啊，這都是人力啊，都要給錢的啊。

固然不是說所有100%可以作到，但至少能夠說70%以上的需求能夠作到不改動代碼，就算改動代碼了也只須要從新測試新開發的功能就能夠了。

這就是SOA提倡的東西，這邊不是說SOA的原則，咱們說SOA能夠作到什麼。

SOA能夠作到什麼？咱們粗看一下，有的人以爲很空洞，有的人以爲「很深奧，看不懂寫點什麼」，那就先來看一段SOA架構理念吧：

1. 模塊和模塊之間耦合度降到最低！

2. 業務間的規則能夠由客戶自由定義！

3. SOA不是一種軟件，它是一種設計、實現的思想，它幫助一家企業創建起一個業務的infrastructure！

4. 它能夠迅速實現客戶的需求，爲客戶提供垂直的業務需求，能夠快速的把客戶的業務從需求直接變成IT實現！

固然還有不少，我先就舉上面幾條市面上見得最多的」行話「，怎麼去理解上面4句話呢？咱們用大水詞來理解吧，上面這4句說的就是：

1. 我新作的東西，應該按照模塊化開發思想，就是你原來的系統給新接入的模塊未來的接口要預留好（有人說了，我2011年開發的東西怎麼知道你2012年的模塊是什麼樣的，怎麼給你預留接口啊，對的，能夠預留看，你看下去）。

2. 因爲我接口已經予留好了，新的模塊就像搭積木同樣，就是樂高積木啊，把新的東西」插「上原有的模塊就能夠用啦，若是這個模塊很差了，舊了，我拿掉它，再換一個模塊。甚至能夠作到原本一個項目，10個模塊，每一個模塊都由一個開發商去實現，而後再找第十一個開發商來搭積木同樣的去完成前10個模塊的集成啊。

3. 而後就是諸如：a+b+c*(x/y)如今成了a+b*(x+c-d)這樣的業務變換，我不須要去用個eclipse打開工程而後改動裏面的代碼，一改就是改jsp, action, service層，dao層對吧，改完後急着上線，而後BUG又是一堆，改不完的BUG，加不完的班，不要，程序員不要走這種路了。

4. 像這樣的業務改變，你有一個界面，讓業務人員就能夠本身去經過拖拖拽拽本身去實現需求的變化了啊，這邊的業務人員指的是企業裏面用你開發的這套系統的最終用戶，他們本身通過簡單的培訓就能夠用你的系統本身去定義本身的業務變動啦。

若是你的系統可以知足客戶這樣的需求，啊呀，在如今這個大環境下，當人家公司接不到項目時，你必定可以接到項目。

那又有人說了，客戶均可以自定義化了，我這個項目結束後不就沒有後期維護，後期開發任務了嗎，我就不可以長期的穩定的去得到一個客戶這邊的項目來源了嗎？

錯！！！

你錯了，客戶的需求是不斷的在變的，由其是業務系統，那個業務變化太大量了，就說一個CRM系統，一個CRM系統它面臨的是每月都在變的業務，爲何？促銷，打折，雙11，雙12，聖誕打折，這些業務都在變啊。

個人系統由於耦合底低，能夠作到模塊間的任意互換，而後我又有這種業務人員自定義規則的界面，因此我新作的模塊能夠0影響到原有的已經佈署的代碼，並且我新作的模塊的佈署是不須要原有的服務器在某天的零晨停一下，而後我重去佈署一下這種作法的，取而代之的是24*7的一種模式，因此我管你客戶需求怎麼變，新的需求拿來，我都是隻須要從新估算新的功能的工做是量，可能新的功能裏面有70%的業務是能夠由客戶中的業務人員去自定義完成的，所以這70%我留給客戶，30%這我的工費我會收，客戶也以爲應該給你。

由於你作的東西不影響原有系統的功能，不影響原有的系統運行，不會有太多或者就算有regression bug也是降到最底的度，所以客戶纔會源源不斷的每月，給你個20%，30%，10%，而後過幾年系統大升級，軟硬件中間件一塊兒換也找你，就算客戶新的模塊是找另外一個開發商作的，可是在集成時碰到問題仍是要諮詢你啊。

因而，項目錢，這個大頭是能夠掙到了。

因而，維護費，每月按期的，並且這種維護由於不是傳統的那種翻寫原來的工程，改動原有的系統，而只是搭積木同樣的，你能夠僱用相對便宜的年紀輕的程序員，利潤也有了。

因而，你還能夠收諮詢費。

從原來的幾個悲慘的「因而」，變成了多條腿走路，多方位收錢的因而啦，呵呵！

關鍵是這樣的項目是怎麼作的，說了這麼多，這樣的項目是長個什麼樣的呢？

記得我當年在公司裏面臨第一次升職選擇時，公司給了我兩條路：PM道路和技術道路。我選擇了技術道路。因而我次日接到了美國總部一個Chief Architect，就是主任架構師的第一輪考覈電話。

老外，很牛B，大家知道他是怎麼考覈的嗎？至關的誇張：

嘿，你，看看公司的員工內部系統，裏面有考勤，在線學習資料，請假，報銷，你在公司這些年一直用這個系統吧，如今請給我寫一下，若是讓你設計這個系統，你會怎麼去設計？給你30分鐘，嗯。。。。。。對，就30分鐘，如今是4：10分，請你在4：40分把你寫的東西經過email發給我，as much more as you can think。

我花了25分鐘，最後他用了一個excellent把我給錄取到了公司的架構師隊伍，從而我成爲了中國這邊惟一一個可以進入到美國核心技術隊伍的成員。

那我是怎麼寫的呢，固然，我也只是給你們參考。 我是這樣寫的：

首先，這個系統無論是考勤、請假、報銷都有一個」流程「性的東西，由於每作一步，系統都會有相應的EMAIL告訴你或者是某個環節的審批人：你目前有一個什麼什麼樣的任務，還常常會收收到系統的EMAIL要求我上傳這個附件，那個附件，駁回，拒絕，經過啦等等等，所以我會採用工做流，若是客戶是大型企事業客戶我會推薦他們去用一些商用軟件如：IBM Lombardi，或者是Oracle的Pega Rulz。若是是中小型客戶我會推薦一些開源的工做流如：jbpm, aris或者是activity。

其次，該系統中存在大量的」上傳單據「，」發票複印件「，」病歷掃描件「，」會議文件「，」PPT「等文件上傳文檔的接口，所以，我不會本身去拿個common upload去作這麼多的界面。

首先，若是我本身作，若是時間容許，我會去作，可是我本身作這些上傳文件的界面和系統，我還面臨着上傳完後根據個人上級，上上級，上上上級這樣的一個」按照權限「查看附件的一個權限系統問題。

那我本身作了上傳系統後，除了解決按照權限查看調閱這些文件系統外我還須要面臨着去作，我上傳了第一次，傳了不夠，加點東西，傳錯了撤銷重上傳這麼一個版本控制的問題。所以我會選用CMS即Content Management System。

比較適中的好的CMS系統如：Microsoft Soft Share Point Server即MOSS系統，或者是純免費開源的OPENCMS進行二次開發來幫助我作到上述這些事情。

而後，這個系統有考勤，有報銷，有請假，有在線學習資料課程管理，我確定會按照模塊一個個開發，而後模塊與模塊間的集成怎麼辦？對吧？這個系統是單點登陸的，這個勿庸置疑，你登陸了企業公司內的AD域就能夠登陸這樣的一個系統，模塊和模塊間又要低耦合，那就是按照模塊分離開發和佈署原則，那只有上PORTAL了，因此Websphere Portal Server或者是liferay portal純開源免費的這個是。若是不用portal那就是模塊和模塊間用web service接口，即組件合開發SCA概念。可是組件開發若是按照Webservice來對接，就意味着若是我新作一個模塊，須要和原有模塊的webservice間的連調問題，所以咱們能夠考慮採用esb統一webservice路由後全部的新作模塊按照這個統一的接口，而後像搭積木同樣把新的模塊「搭」上去。

還有就是這個系統，同時還鏈接着公司的財務，進銷存等其它系統，它們之間確定會有相似自動」定單「的東西或者是數據交換存在，那就存在着異步調用，那我確定會用JMS,可是JMS裏隊列我要本身去實現，你有那個能力那個精力本身去實現一個企業級的隊列？

給我時間，又說給我時間。

人家企業開發集成4個月，6個月哪有這麼多時間給你去本身光開發一個隊列系統，你當人家企業是小白鼠啊，經濟危機，沒錢沒時間，OK，因此我會上MQ，開源的我有activeMQ給企業選擇，若是是商業級的我推薦用IBM Websphere MQ。

前面剛纔說到了單點登陸，這個單點登陸是逃不掉的，並且你光單點登陸是不夠的，還要去集成企業內的權限系統，你本身去重頭寫一個？固然若是如今是一個新產品開發，你能夠花2-3個月甚至更長時間把個權限系統作完美了，如今是企業級開發，業務系統，我確定會去想，如何拿靈活的，組件化的模塊，成熟的組件去實現我這個需求，所以我會選SSO組件和企業權限組件如：IBM TAM，或者是WebSeal或者是YALE CAS去集成這個SSO和權限，這樣，利用這些組件自己強大的訪問LDAP即AD的能力我能夠把精力專一在如何去組成這個系統上而不是拿個SSH，天世界的每天敲代碼把這些東西重頭到尾作一遍。

而後是安全上的考慮，我會考慮：

1. 我要從應用層面上來講防止跨站式入侵，SQL入侵，腳本注入入侵，中間人攻擊入侵等

2. 我要從系統層面上來考慮病毒的入侵，惡意的DDOS攻擊等

3. 數據的傳輸安全層面我要考慮數據如何保護，哪些層面，哪些傳輸是須要加密須要保護的

4. 硬件層面的時間同步

5. 因爲系統中不少層面上用到了加解密認證等東西，我確定要考慮一個證書、口令管理系統，不可能我只把個證書放在WEB-INF目錄下就完了，什麼certificate.bin這樣的東西就能夠整個項目都拿來用了，這是不對的，不能這麼幹，確定要有本身的證書和加解密管理庫的。

擴展性上的考慮：哪些層面我是能夠集羣的，因爲是組件化設計和開發，所以哪些面可能面臨數據集中訪問，訪問量大，能夠集羣擴展，一上集羣后你原有的開發的程序會有不少東西須要作同步，和改動,這些我是怎麼考慮的。

兼容性上的考慮，有些客戶有錢，有些客戶沒錢，有錢的上WAS, WEBLOGIC，沒錢的上TOMCAT, JBOSS，那個人系統不可能作4套，對WAS一套，WEBLOGIC一套，對TOMCAT一套而後對JBOSS一套。我係統確定只有一套，在WAS, WEBLOGIC, TOMCAT, JBOSS上均可以運行或者只須要裝至關有限的擴展LIB庫就能夠運行起來對吧？

數據庫層面，JAVA跨數據庫，我確定要最起碼支持主流的ORACLE, DB2, MSSQLSERVER吧，不可能會爲這幾個數據庫各作一個版本，我確定是只有一個版本，而後個人SQL語句就能夠在DB2時支持DB2, ORACLE時支持ORACLE, MSSQLSERVER時支持MSSQLSERVER吧？（提示：當碰到繞不過去的必須使用到某個數據庫的特性來寫SQL時，請參照hibernate dialect的原碼即實現原理去寫你的SQL）

基本寫了上述這些，而後後面幾天的面試與考覈固然就是圍繞着我第一天寫的這篇文章裏的技術點進行詳細考覈了。

你們不知道看出來沒有，出現了一堆的新東西，由其是最後3項，安全性，擴展性和兼容性。

這裏不是說我列一下這些名詞就能夠了，你必須把這些列出的名詞都玩一把吧。

並且我說了」商業的我會選用哪款產品，爲何，開源的我又會選用什麼產品，爲何「。

因此，要成爲架構師不是說嘴上可以列出一些名詞就能夠了，你必須都玩過，就拿個Webservice來講，你說你會Webservice，OK，用Axis2怎麼實現，JAXWS怎麼實現，XFIRE怎麼實現，SPRING-WS怎麼實現，QOS是什麼，這些你都必須學過用過纔可以說得出一個因此然啊！！！不是說我光會個jaxws就說：我精通webservice了！！！

對於實現上述這樣的一個系統錯誤的作法是什麼樣的呢？

本身設計一套數據庫去作權限，不少公司這麼作，就是基於RBAC原則，固然，咱們能夠這麼作，前提是：你作的是核心系統，就是一家企業的系統從沒有到有都是讓你來作的，那麼咱們先會從權限系統下手，能夠從新設計一套。

可是當你觸及到的是業務系統時，你大多時間面臨的是去集成客戶的權限系統和你本身的系統，所以你要想清楚如何去拿你模塊自身帶有的權限系統去集成客戶已有的權限系統，而不是試圖去用你已有的權限系統去勸說客戶走你的權限模型。

碰到審批流程化的東西時，如大量的用VISIO畫出來的邏輯去寫一堆的IF, ELSE，SWITCH CASE語句，HOHO，千萬不要這麼作。

若是有一個流程的分支改變了，先不說你本身用IF ELSE實現的艱鉅與複雜，若是一旦你改變了，可能你可以經過分析之前一堆的IF ELSE代碼找到你將要新加的IF ELSE的地方，也可能由於你多加了一個IF ELSE而讓原先跑得通的流程所有做廢，壞掉。用引擎吧。

若是有一個諸如：原來是a+b+c*(x/y)如今成了a+b*(x+c-d)，請考慮使用規則引擎，而不是去寫一堆的store procedure，由於規則引擎提供了客戶自定義規則流，規則描述的圖形化界面從而可讓客戶去本身修改規則。

逆波蘭表達式不是讓你用在這邊來作複雜的企業規則的實現的，編譯器原理學了不是讓你本身去開發引擎的，除非你作的是科學計算機，企業級開發裏請儘可能使用規則引擎吧。

由於有了規則，你能夠任意去改變客戶的業務規則，由於有了規則，你能夠把DAO, SERVICE打包成規則上傳後規則會經過CLASS LOADER自動加載而運用到客戶現有的系統中從而實現不重啓機器又能達到改動規則的目的，由於有了規則引擎，改變規則的事情能夠交由客戶的業務人員去作，由於他們本身的業務是常常的在變的，而咱們程序員要作的就是給客戶提供這些A,B,C,D,,E,F,G的元素，而後讓客戶本身去組合。

我還看到過有用」僞規則「的開發商，這樣的開發商真的要被人罵了，就是他已經有了規則這樣的思想了，把規則的組織去交由客戶，可是他沒有用規則引擎而是作了一堆的STORE PROCEDURE，差很少有2百個之多。而後客戶若是要改規則了，只要改其中的20幾個STORE PROCEDURE，而後他們還會教客戶如何拿個ORACLE的PLSQL/DEVELOPE客戶端去讓客戶本身寫CASE WHEN。。。天哪，把客戶的業務人員也變成了IT開發人員，你夠牛B，很少評價了。

請考慮PORTAL，或者是基於WEBSERVICE的SCA編程模型，而不是本身作一堆的WAR包，而後WAR包間互相用api調用的方式來依賴，原本你已經把模塊分離了，這下好，模塊又依賴到了一塊兒，僞耦合。

有時在面對大量上傳，文檔管理模塊時請考慮使用CMS系統或者理念，而不要本身去用記數據庫的方式去實現版本控制，更不用提CMS所具備的權限整合能力了。

作一個工程，涉及到工做流，規則引擎，CMS，SSO，PORTAL，原本這個工程已經挺大了，你除了把要實現的業務代碼實現一遍，你還要本身拿個SSH，去實現工做流，規則，CMS, SSO, PORTAL本已經有的那些底層功能，那我問你，究竟是在作項目仍是在作這些產品，你說我都本身實現，HOHO，你牛B，等你作出來後，客戶早就飛走了，項目早結束了。

回過頭來看IBM與TCS爲何成功

因此回過頭來，咱們說由於IBM把它的精力集中在了開發這些BPM, CMS, SSO, BUSINESS RULZ ENGINE中間件上面了，同時，許多企業也認清了目前的大環境以及如今的客戶對於項目的這一系列快，變動不觸及到原有，任意替換，分析模塊等要求，所以這些開發商須要有相應的，成熟的，穩定的組件拿來用啊。

因此IBM專作這些組件，靠這些組件它發了財了。

IT界有句笑話嗎，說：有人說山上有黃金，因而來了許多人去挖黃金，結果誰都沒發財！那誰最後發了財呢？山底下那個賣鏟子的老頭髮了財了。

那TCS呢，TCS憑藉着他第一個是印度人廉價的優點，第二個它及時的把從原來的作外包，變成了」方案外包「，就是我不僅，不光光只有人頭給了你，而是我可以爲你的項目，你的需求，從軟硬件上提出一個總體的solution，就像我在回答咱們的那個美國的chief architect的問題時所說的那些，數據庫層我怎麼樣作，安全層我怎麼樣作，擴展性怎麼樣作，對於上傳文檔管理我是怎麼去解決的，對於流程化的東西我是怎麼去解決的。

他可以提出大量的這樣的solution，而後它把諮詢顧問人員派到你客戶這邊，而後開發人員在印度、在China這邊的這種「offshore（離岸式）」方式來進行開發。

而後這樣的一個系統一旦上線，咱們說了，由於它是一個」解決方案「級別的，那圍繞着這樣的系統會有一堆的需求變動，後續開發，集成，甚至和第三方集成，那都是會被TCS吃下來的。

這就叫」斬首行動「，就是我吃掉了你的」大頭「後面的零碎的其它的外圍系統就都是個人了。我要吃時，隨時能夠吃，我不想吃時，分點羹給你啊，對吧！

因此國內的一些企業，由其是傳統外包，巨頭外包或者是一些一直作項目而如今發覺項目愈來愈難接的公司，大家須要轉形了。

對這些企業我想引用我前公司的的一位領導，他同時也是個人技術人生第一導師的話來講：外面其實有不少項目，可是它們不來找你，而你，找不到項目適合你來作。

結束語

基本我先總結這些吧，因此，程序員們，大家看看，大家要學的東西還有哪些？

SSH不是沒有用，SSH是基礎，是1+1=2，是九九算數表，由於你在作接口時，在開發一些底層的東西時仍是須要用到SSH的，而對於一些只有「組件」才能作的事，留給組件去作吧。

SSH不是沒有用，SSH更重要了，由於它已經成了你邁向更高階的一個踏板，沒有了這個踏板，你很難上車，就算上了車你也是騎不穩的。

若是你還還處在迷茫中，那麼就是說你尚未翅膀，但你也想飛翔，那麼這些東西夠你學一生的了，相信擁有一雙翅膀絕對是值得你去追求的吧？

SOA是一個理念，如今的SOA又包括了雲計算，社交網絡，企業級MOBIE應用的混合應用，SOA+雲，SOA+MOBILE, SOA+雲等等等是近20年可能僅有的掙錢的機會了。

由於SOA把原有的企業級開發人員，再次變成了真正的IT開發人員，在SOA理念的指導下去開發系統，IT開發人員更須要去關注於技術和業務的infrastructure即業務組合的架構和技術框架上去，而不是去實現業務；實現業務交給了業務人員，這是一種返璞歸真即從新回到了IT人員作技術，業務人員作業務的時代中去了。

我固然這邊也只是發表一下本身的意見。

我本身總結了一下，由其是還處在迷茫期的程序員，有人說：到底我幹了4年，5年我還能幹技術嗎？還要學點什麼，還差點什麼，那我總結出來下面這麼一張圖，從上往下看：

這張圖我把它分爲3層。

從上面第一層來看，我列舉出了一些行業界的優秀組件，這些組件都是和業務無關的，但又都是用來組合和集成大型業務系統時所須要用到的。所以我以爲是有必要都去熟悉，學習，運行一下的，若是有志向，應該每個都會用而且知道分別能夠在哪一種場景下運用以及它們在運用和集成到你的框架時的優缺點、注意項。

當中這一層，我以爲是一個準備走技術道路的J2EE開發人員所必須具有的，要否則你無從去了解和設計出一個跨數據庫，跨平臺，擴展性，安全性的J2EE系統了。

最底下一層，是爲了去知足當中這一層和最上面這一層所要具有的」基本功「，這就和1+1=2同樣，這個不會，你也不要去談四則運算了。

要學的東西還有不少。

你若是要來問我：還學點什麼，相信此文能夠回答你的問題。

誰說技術道路走不到底？誰說30歲左右就要換PM的角色？

技術道路也能夠走下去啊！

software engineer, senior software engineer, team leader, architect, senior architect, chief architect, principal architect。

嗯，principal architect，差很少到了這層我應該是vice president的待遇了，哈哈哈哈，估計那時我已經50歲了吧，可我依然走技術，嘿嘿！