前一段時間，看到阿里幾位前端大師的討論：阿里前端的困局與突圍，對這個職業的發展方向有一些思考，我上次跟winter和dh一起吃飯，也簡單聊到這個話題。
winter問了乙個問題，如果在網際網路企業跟遊戲開發的企業同時進行一次針對前端開發的大裁員，對這個企業的核心價值而言，哪種影響更大？
這個問題問得很有意思，在每個行業裡，前端開發的側重點是不一樣的，重要性也有所不同，簡單來說可以分為3個大類：網際網路、企業應用、遊戲，分別側重於：互動、架構、演算法。
在這三個大類裡，網際網路方向的前端開發最為正統，算是根正苗紅，所以在這個領域的人，對標準研究得最為透徹，對互動理解得最為深刻，目前前端方向的高手大多集中在這個領域。這個領域的人最關注的問題是相容性，對一些細節的優化把握得爐火純青。因為這個領域的業務特點，前端做的事情過於扁平，整個可發揮的餘地不夠，雖然高手眾多，但就像很多龍擠在淺水裡，常常有無用武之地的感嘆。剛才玉伯這篇文章，講述的就是這個領域中前端的困惑。
企業應用方向的前端開發其實很多時候並不在意他們用的是web還是其他類似技術，比如flex，silverlight等，對他們來說，即使是c/s的系統，也能夠發揮出很大價值。這個領域的人最關注的問題是元件化和快速業務開發。
從企業軟體的方向來說，它的業務是很豐富的，對各種前端技術的應用也都很廣泛，乙個大型的企業應用，幾乎什麼特性都能用上。相對於網際網路系統，它的客戶相對比較專業，可以排除一些低端過時的瀏覽器，所以少了很多相容的負擔，在框架選型上，也可以接受很複雜的框架，比如extjs、angularjs等，因為他們的業務特性，往往需要很複雜框架的支援。
用我所在的電信行業軟體舉例，業務複雜度非常高，一套全業務系統會有兩千左右的資料庫表，兩千個左右的業務選單，其中有些業務介面的複雜度非常驚人，而且經常會根據需求有較大變動，效能也有較高要求。
理論上來說，前端在這個領域可以領悟到很多事情，但這個領域有個最大的問題，盈利太低，不足以支撐很深入的研究。另乙個無奈的問題是，由於歷史原因，前端開發人員在這個領域並不容易受到重視。比如說資深技術人員多數是做後端開發的，認為前端很小兒科，在應屆生入職篩選的時候，也會把能力較高的弄去做後端開發，剩下的留給前端。這些原因，造成了企業應用的前端領域就像乙個又大又深的湖，裡面小魚小蝦眾多，卻很少有大魚。
我在企業軟體前端開發做了很多年，經常思考其中的一些問題，在這個領域做，總是有一種寂寞的感覺。我們這種行業，為了保證交付的及時，傾向於劃分業務開發和技術平台開發，業務開發人員並不在難解決的問題上花時間，遇到問題的時候向技術平台團隊尋求支援，把問題轉移給更專業的人，避免耽誤自己的交付時間。在他們開工之前，也由技術平台團隊預先搭建框架，他們直接在這個上面以固定的模式進行開發。兩個團隊，前者的特點是多而泛，後者的特點是少而精。
這麼做，效率比較高，但帶來乙個問題，業務開發團隊的技術水平很難提公升。因為他總是忙碌趕工，很少有時間去思考很多問題的前因後果，即使你幫他解決了問題，告訴他，他也不一定有心情去關注一遍，因為他確實很忙。可能有些有激情的人會自己花點時間研究一下，但多數人很難有這樣的心境。
這就造成了業務開發團隊和平台開發團隊的技術實力嚴重脫節。從另外乙個角度看，技術平台團隊長期專門給別人解決問題，自己卻很少全職參與某個業務專案的開發，他也很難有成就感。這還不是最大的問題，最大問題是，不管從哪個團隊，都很難成長出能夠設計最適合這些業務的前端架構的人，這恰恰是這個領域前端開發最重要的部分。
當出現各種新技術的時候，平台團隊比較容易去快速跟進，但投入通常不會很大，當取得一些進展的時候，會逐步向業務開發團隊推廣，但這個推廣的難度是很大的，因為人數的比例會比較大。當技術從乙個人向三個人推進的時候，是相對還算容易的，如果從乙個向十個或者二十個人去推進，難度就大多了。而由於傳統企業盈利規模的限制，沒辦法在每個技術方向都有較大投入，所以往往就是一兩個人去折騰，他們在探索的過程中遇到問題，是很難找到能夠交流的人的，如果自己解決不了問題，就會持續苦悶，非常寂寞。前端這個領域更是如此，現在客戶端技術這麼多，各種終端，各種瀏覽器，各種前端框架，每個上面投入乙個人，就已經是個很大團隊了，這種模式很明顯就碰到瓶頸了，因為它很直接地跟人員編制產生了衝突。擴編直接對利潤產生衝擊，但是不擴編的話，技術平台團隊的壓力就會進一步加大，除了要探索新技術，還要對越來越龐大的業務開發團隊作技術支援，每個人都痛不欲生。
這種困境怎麼解決呢，我想了很久，無計可施，也許，是時候要效仿網際網路企業的開發模式了？但是積重難返，而且傳統企業招聘的門檻遠比網際網路企業低，人員的能力有差距，也很難有網際網路企業那麼蓬勃而廣泛的技術研究氣氛，可能就更難做下去了。
可能這個領域的出路是尋找更為簡單快速的開發方式，並且把相關的外圍工具也做大做強，在業務領域中，把元件也積累沉澱出來，這時候能夠用更少的業務開發人員來實現同等規模的系統，把更多人力節約出來做技術探索和改進吧？
複雜系統設計 企業開發的困境
複雜系統設計源自我多年對企業複雜系統的設計的一些思考，類似日記吧，不斷完善。為什麼從乙個大公司的引入架構師甚至架構師組還是很難架構企業開發中的很多問題？這些問題表現出架構上的複雜性，和業務上的複雜性。有時候架構和業務的界限不清晰，非常的模糊。也可以說是架構設計不合理，也可以說是業務理解不清。業務實際...
BYOD 企業的困境與力量
科技發展日新月異，隨著智慧型裝置大規模普及，企業中越來越多的員工，希望可以使用自己熟悉的智慧型手機或平板來工作，byod bring your own device 開始成為了乙個席捲全球的風潮，以此帶來的便利性也漸漸為企業所接受。我們試想一下商店的店員，如果他們的手機可以連線到商店的銷售及庫存系統...
企業團隊無法繞開的囚徒困境
團隊合作易墜入 囚徒困境 有效持續的溝通與信任，及創造良好的團隊合作氣氛是解決團隊問題走出困境的最佳解決辦法。囚徒困境 講述的是兩個犯罪同夥落網後的故事。開始兩個罪犯閉口緘默，就是不招認，因為他們之前有約定，若然 死不認罪。於是，警察將他們分開囚禁，並分別對他們說 你若招認了，而你的同夥不招認，那麼...