web開發(fā)有哪些必須的挑戰(zhàn)_web網(wǎng)站開發(fā)有哪些挑戰(zhàn)
Web軟件開發(fā)工程師可以分為Web前端和后端開發(fā)。那什么是Web前端,什么是Web后端呢?下面由學(xué)習(xí)啦小編為大家整理的web前端開發(fā)的挑戰(zhàn),希望大家喜歡!
web前端開發(fā)的挑戰(zhàn)
第一大挑戰(zhàn):兼容性
瀏覽器種類非常多,IE、Firefox、Chrome、Opera、還有眾多的IE加殼瀏覽器,類似搜狗、傲游、360,再加上這些瀏覽器的移動(dòng)終端版本。需要有Web標(biāo)準(zhǔn),前端的知識(shí)大部分通用于各個(gè)瀏覽器,但還是會(huì)有歷史遺留問題,不同版本的瀏覽器有不同的問題。特別是市場(chǎng)占有率最高的IE系,雖然IE 9/10看起來相當(dāng)標(biāo)準(zhǔn),但向之前版本間各有各的問題,向前兼容非常頭疼。如果不積累點(diǎn)經(jīng)驗(yàn),面對(duì)疑難雜癥那是一頭霧水。
第二大挑戰(zhàn):交互的復(fù)雜度
CSS和DOM提供的接口水平過低,而BOM提供的控件只有input、select、textarea這幾種最基本的,稍復(fù)雜一點(diǎn)的UI效果,都要前端自己利用CSS和DOM去組合創(chuàng)造。看到一個(gè)需求,腦子里第一步要想如何利用CSS、DOM這些基本的零件組合成最終的效果,實(shí)現(xiàn)最終效果其實(shí)是一個(gè)“創(chuàng)造”的過程,比如說tabView,treeView,richEditor,colorPicker這種看起來常見的組件,其實(shí)在前端里都是沒有現(xiàn)成可用的,需要自己去實(shí)現(xiàn)。
前端語言的 膠水性需求 太強(qiáng)。CSS、DOM、JS是三種不同的技術(shù),這也是前端知識(shí)系統(tǒng)中要掌握的最重要的三個(gè)基本功。前端的效果是通過CSS、DOM、JS三者配合起來最終呈現(xiàn)出來的,脫了任何一個(gè)技術(shù)都寸步難行,時(shí)刻要同時(shí)考慮多個(gè)方向的知識(shí)點(diǎn)。前端編程像是開了三個(gè)線程同時(shí)在跑,復(fù)雜度成倍增長(zhǎng)。
第三大挑戰(zhàn):代碼可維護(hù)性
復(fù)雜度的提升直接影響代碼的維護(hù)性。CSS+DOM+JS的組合實(shí)在太強(qiáng)大了,同一個(gè)效果可以有多種完全不同的實(shí)現(xiàn)方式,每一種實(shí)現(xiàn)方式都會(huì)有不同的開發(fā)難度、擴(kuò)展性、可維護(hù)性。解決方案太多,看到一個(gè)效果首先會(huì)先想到如何用CSS和DOM里那些low level的接口實(shí)現(xiàn),這是一個(gè)“創(chuàng)造”的過程,這時(shí)腦子里可能冒出好多種不同的實(shí)現(xiàn)方法,“創(chuàng)造”完了之后還要“比較”,權(quán)衡各種解決方案的優(yōu)劣,糾結(jié)一陣之后,才能選出最適合的方案。當(dāng)然,并非前端都是完美主義,一定要選一個(gè)最好的方式出來,而是因?yàn)榍岸耸荊UI編程,直接面向用戶,是最直接的產(chǎn)品呈現(xiàn)的部分,是門面。正因?yàn)槿绱?,前端也是最容易被反?fù)修改的部分。反復(fù)“修改”有多可怕,是個(gè)程序員都懂的,如果可維護(hù)性不好,那簡(jiǎn)直是惡夢(mèng)。所以前端不得不重視可維護(hù)性,不重視可維護(hù)性直接等于自虐。
第四大挑戰(zhàn):性能
第五大挑戰(zhàn):個(gè)人成長(zhǎng)
開發(fā)者的思路很重要
前端的開發(fā),如果沒有總體的設(shè)計(jì)思路,會(huì)成為一種碎片似地程序,一個(gè)效果一堆代碼,一個(gè)功能一灘腳本,一個(gè)需求片邏輯。曾經(jīng)遇到過,因?yàn)閡e調(diào)整,把整個(gè)前端的代碼除了核心數(shù)據(jù)處理函數(shù)保留,其余的全部修改的情況?;旧锨岸说拈_發(fā),處于DOM操作,數(shù)據(jù)處理,數(shù)據(jù)交互三部分,如果合理的分配這三部分的功能,那么前端的代碼就很容易擴(kuò)展和調(diào)整。
真正的前端開發(fā)挑戰(zhàn),還在于開發(fā)者的思路。兼容性,布局,CSS和JS都不是問題,問題在于如何合理地組織語言邏輯;如何正確抽象出需求中的模塊;如何用代碼處理,清楚地用代碼表達(dá)出思路、寫好注釋,給后續(xù)維護(hù)者一個(gè)可閱讀的思路。前端的改動(dòng)量,是后端的數(shù)倍,前端沒有絕對(duì),只有跟隨需求不停的修改。
Web后端開發(fā)的挑戰(zhàn)
第一大挑戰(zhàn),后端開發(fā)最重要的挑戰(zhàn),來自于規(guī)模
規(guī)模的擴(kuò)大,比如訪問量擴(kuò)大,文件存儲(chǔ)量擴(kuò)大,數(shù)據(jù)量擴(kuò)大,服務(wù)器數(shù)量擴(kuò)大等。一個(gè)前端看起來一模一樣的網(wǎng)站,某一種指標(biāo)如果擴(kuò)大十倍,幾乎都會(huì)面臨一大堆的問題和挑戰(zhàn)。另一方面,在規(guī)模擴(kuò)大以后,后端系統(tǒng)架構(gòu),一定會(huì)復(fù)雜化。原來只有一臺(tái)Server,LAMP都裝在一起。然后數(shù)據(jù)庫分出來,反向代理,負(fù)載均衡,分庫分表,Memcache,Message Queue,事務(wù)處理,CDN,NOSQL,種種架構(gòu),Server,就逐漸的演化出來了。架構(gòu)的復(fù)雜化,自然會(huì)帶來更多的問題和更多的挑戰(zhàn)。
第二大挑戰(zhàn),來自于安全
安全問題層出不窮,防不勝防。需要技術(shù)手段,也需要管理制度。
第三大挑戰(zhàn),來自于效率
能否提供足夠的處理速度,能否提供足夠的帶寬,能否保證響應(yīng)能力,這些是對(duì)外的效率。能否使用更少的服務(wù)器,能否使用更加便宜的服務(wù)器,能否使用更加節(jié)省能源的服務(wù)器,這些是對(duì)內(nèi)的效率。
第四大挑戰(zhàn),來自于需求變更
無論前端后端,都會(huì)面臨需求變更,只要是軟件開發(fā),這都是大挑戰(zhàn)。但是當(dāng)一個(gè)系統(tǒng)已經(jīng)穩(wěn)定的,高效的運(yùn)行時(shí),需求變更來了,在滿足需求之后,原本來沒有問題的部分,會(huì)不會(huì)突然崩潰,一旦崩潰,就是后端工程師的噩夢(mèng)。
第五大挑戰(zhàn),來自于教條
這個(gè)世界上有無數(shù)IT大公司,他們都很開放,都愿意分享自己的架構(gòu)與技術(shù)。于是,對(duì)于“眼界開闊”的后端工程師而言,困難不在于如何解決,而在于如何從眾多的解決方案中做出挑選。框架、實(shí)踐不斷涌現(xiàn),成功案例也不斷涌現(xiàn)。人家都用得好好的,你敢用嗎?到底是勇于嘗鮮,還是保守要緊呢?這個(gè)很難。
web前端與iOS終端異同
語言
前端和終端作為面向用戶端的程序,有個(gè)共同特點(diǎn):需要依賴用戶機(jī)器的運(yùn)行環(huán)境,所以開發(fā)語言基本上是沒有選擇的,不像后臺(tái)想用什么就用什么,iOS只能用object-c,前端只能javascript,當(dāng)然iOS還可以用RubyMotion,前端還能用GWT/CoffieScript,但不是主流,用的人很少,真正用了也會(huì)多出很多麻煩。iOS還可以用蘋果新出的swift語言,后面可能用于取代object-c,還處于起步階段,先不討論。
objc和js這兩者有個(gè)有意思的對(duì)比:變量/方法命名的風(fēng)格正好相反。蘋果一直鼓吹用戶體驗(yàn),寫代碼也不例外,程序命名都是用英文全稱并且要多詳細(xì)有多詳細(xì),力求看變量和方法名就能知道是干嘛的,例如application:didFinishLaunchingWithOptions:。而js因?yàn)槊看味家獜木W(wǎng)絡(luò)下載,要力求減少代碼體積,所以變量方法名是盡量用縮寫,實(shí)際上有代碼壓縮工具,無論變量名寫多長(zhǎng)最終上線的效果是一樣的,但大家也都習(xí)慣了用短的命名,例如上述objc的application:didFinishLaunchingWithOptions:方法在js里習(xí)慣的命名是:$()。
objc與js都是動(dòng)態(tài)語言,使用起來還蠻像,但objc是編譯型,速度快,很多錯(cuò)誤也能在編譯過程中被發(fā)現(xiàn),js是解釋型,性能依賴于解釋引擎,即使在強(qiáng)勁的v8引擎下性能也趕不上編譯型語言,語言太動(dòng)態(tài),變量完全沒有類型,寫起來爽,debug起來稍微費(fèi)點(diǎn)勁。一直感覺js輕巧靈活放蕩不羈充滿各種奇技淫巧,objc中規(guī)中矩沒c++ java那么嚴(yán)肅也沒有js那么靈活。
線程
前端開發(fā)幾乎不需要線程這個(gè)概念,瀏覽器實(shí)現(xiàn)上頁面HTML和CSS解析渲染可能與js不在同一個(gè)線程,但所有js代碼只執(zhí)行在一條線程上,不會(huì)并發(fā)執(zhí)行,也就不需要考慮各種并發(fā)編程的問題。在新的JS特性中可以創(chuàng)建worker任務(wù),這樣的任務(wù)是可以另起一條線程并行執(zhí)行的,但由于并不是所有瀏覽器都支持,不同線程傳遞數(shù)據(jù)各個(gè)標(biāo)準(zhǔn)定的還不一樣,使用場(chǎng)景也少,似乎沒有大規(guī)模用起來。對(duì)于數(shù)據(jù)庫操作/發(fā)送網(wǎng)絡(luò)請(qǐng)求這樣的任務(wù)是在不同于js代碼執(zhí)行線程的,不過這些都由瀏覽器管理,前端無需關(guān)心也無法影響這些線程,只需接收事件回調(diào),不需要處理任何并發(fā)問題。
終端開發(fā)需要大量使用多線程,iOS有一條主線程,UI渲染都在這個(gè)線程,其他耗時(shí)長(zhǎng)的邏輯或者數(shù)據(jù)庫IO/網(wǎng)絡(luò)請(qǐng)求都需要自己另開線程執(zhí)行,否則會(huì)占用主線程的時(shí)間,導(dǎo)致界面無法響應(yīng)用戶交互事件,或者渲染慢導(dǎo)致滾動(dòng)卡頓。程序邏輯分布在多個(gè)線程里跑,需要處理好各種代碼并發(fā)執(zhí)行可能帶來的數(shù)據(jù)不一致/時(shí)序錯(cuò)亂之類的問題,并發(fā)也導(dǎo)致有些bug難以排查,一不留神就掉坑,需要適當(dāng)用一些隊(duì)列/鎖保證程序的執(zhí)行順序。iOS提供了一套多線程管理的方法GCD,已經(jīng)把線程和隊(duì)列封裝得非常簡(jiǎn)單易用功能強(qiáng)大,比其他端或后臺(tái)是好很多了,但還是會(huì)花大量功夫在處理多線程問題上。
存儲(chǔ)
終端開發(fā)需要大量的數(shù)據(jù)存儲(chǔ)邏輯,手機(jī)APP不像瀏覽器,用戶打開瀏覽器必定是連著網(wǎng),但打開一個(gè)APP時(shí)很可能是離線,也很可能處于網(wǎng)絡(luò)狀況極差的移動(dòng)GPRS,所以必須把之前請(qǐng)求回來的數(shù)據(jù)保存好。保存數(shù)據(jù)后又需要與服務(wù)端最新的數(shù)據(jù)同步,如果全量同步數(shù)據(jù)量太大,耗流量速度也慢,于是需要增量同步,需要與服務(wù)端一起制定實(shí)現(xiàn)增量數(shù)據(jù)返回的方案,需要處理好客戶端與服務(wù)端數(shù)據(jù)一致性的問題。當(dāng)數(shù)據(jù)存儲(chǔ)量大結(jié)構(gòu)復(fù)雜時(shí),還需要利用好有限的內(nèi)存做cache,優(yōu)化各類存儲(chǔ)查詢性能。
前端在桌面端很少需要存儲(chǔ),除非是one page app,不存儲(chǔ)自然就不需要數(shù)據(jù)更新的一系列工作,數(shù)據(jù)都是從后臺(tái)取出拼接后直接顯示到頁面上,即使像微博有可以在頁面內(nèi)不斷加載更多數(shù)據(jù),數(shù)據(jù)也只存在于內(nèi)存,不會(huì)持久化存儲(chǔ),因?yàn)樽烂娑司W(wǎng)速穩(wěn)定,不計(jì)流量,所有數(shù)據(jù)可以直接從后端拿取,客戶端沒必要再做一套存儲(chǔ)。移動(dòng)端那些做得很像原生APP的web應(yīng)用就跟終端開發(fā)一樣了,數(shù)據(jù)同樣保存到SQLite,存儲(chǔ)邏輯以及要處理的問題都差不多。
框架
在第三方框架上web前端和iOS開發(fā)完全相反,web原生弱小又十分開放,讓大量第三方框架和類庫可以施展拳腳,而iOS原生強(qiáng)大又十分封閉,導(dǎo)致第三方框架沒有多少生存空間。
瀏覽器一開始只為內(nèi)容型的網(wǎng)頁而設(shè)計(jì),js也只是這個(gè)網(wǎng)頁上能加點(diǎn)小特效的腳本語言,在web應(yīng)用時(shí)代跟不上發(fā)展,需要很多第三方庫和框架輔助,再加上前端開發(fā)是完全開放的領(lǐng)域,導(dǎo)致庫和框架百花齊放多如牛毛,在初期多數(shù)庫的作用集中在封裝dom操作,大家不斷重復(fù)造dom操作基礎(chǔ)庫的輪子,在一段時(shí)間百家爭(zhēng)鳴后獨(dú)尊jQuery,在有使用庫的網(wǎng)站中90%以上使用jq,幾乎成了個(gè)標(biāo)準(zhǔn)基礎(chǔ)庫。后期大家已經(jīng)不再重復(fù)造這個(gè)基礎(chǔ)庫的輪子了,多了一些代碼組織和前端架構(gòu)的框架,例如一些幫助項(xiàng)目模塊化的框架require.js,MVC框架backbone/angular.js等。
iOS開發(fā)蘋果已提供了完整的開發(fā)框架cocoa,而這框架在每一代系統(tǒng)中都在升級(jí)優(yōu)化和添磚加瓦,開發(fā)模式也已經(jīng)定型,第三方框架沒有多少生存空間,大量流行的開源項(xiàng)目是一些通用組件和庫,像網(wǎng)絡(luò)請(qǐng)求庫AFNetworking,數(shù)據(jù)庫操作庫FMDB。而一些大的框架像beeFramework/ReactiveCocoa較難流行起來。
兼容
前端開發(fā)需要兼容大——量的瀏覽器,桌面的chrome,safari,ie6-ie10,firefox,以及各種套殼獵豹360等瀏覽器,移動(dòng)端iOS/Android各自的瀏覽器,以及無限的不同的屏幕尺寸??雌饋硗膳拢瑢?shí)際上也沒那么難搞,只是拿出來嚇唬下人。桌面端chrome/safari以及各種套殼的極速模式用的都是webkit,差異很小,firefox也大體遵從標(biāo)準(zhǔn)實(shí)現(xiàn),與webkit差別不大,舊的ie6/7就需要特別照顧,不過很多網(wǎng)站都不支持ie6了,移動(dòng)端更是一家親,全是webkit,除了新特性上的支持程度不一,其他差異不大。對(duì)于不同的屏幕尺寸,高端點(diǎn)的會(huì)用響應(yīng)式布局,針對(duì)不同屏幕尺寸自適應(yīng)到不同布局,一般點(diǎn)的桌面端定死寬度,移動(dòng)端拉伸自適應(yīng)寬度就搞定。
終端開發(fā)也需要兼容各種不同的系統(tǒng)版本和手機(jī)尺寸,Android不用說,iOS也有3.5/4/4.7/5.5/9.7英寸這些尺寸,不過兼容起來跟web一樣挺容易,就是自適應(yīng)寬度,iOS的UIKit把這些都處理好了,還有autolayout,sizeClass等高級(jí)特性可用,在尺寸上并不用花太多功夫。系統(tǒng)版本上iOS7為分水嶺,iOS7前后版本UI上差異比較大,需要做一些功夫兼容,不過iOS用戶更新?lián)Q代很快,預(yù)計(jì)再過一兩年iOS7以下用戶就可以忽略了。
性能
終端和前端都是面向用戶的,性能優(yōu)化目的都是盡快呈現(xiàn)內(nèi)容,以及讓程序在用戶操作下流暢運(yùn)行。終端主要關(guān)注的是存儲(chǔ)/渲染性能。當(dāng)一個(gè)APP存儲(chǔ)數(shù)據(jù)量大,數(shù)據(jù)關(guān)系復(fù)雜時(shí),數(shù)據(jù)查詢很容易成為性能瓶頸,需要不斷優(yōu)化數(shù)據(jù)存取的效率,規(guī)劃數(shù)據(jù)IO線程,設(shè)計(jì)內(nèi)存cache,利用好終端設(shè)備有限的內(nèi)存,渲染上避免重復(fù)渲染,盡可能復(fù)用視圖,尋找最高效的渲染方案。
前端關(guān)注頁面加載速度,由于web頁面的結(jié)構(gòu)/樣式/程序/資源圖片都是實(shí)時(shí)請(qǐng)求的,要讓頁面更快呈現(xiàn)內(nèi)容,就要優(yōu)化這些請(qǐng)求,讓這些資源以最快速度加載下來,包括合并圖片/合并代碼減少請(qǐng)求數(shù),壓縮代碼,并行請(qǐng)求,根據(jù)版本號(hào)緩存代碼請(qǐng)求,gzip壓縮,模塊/圖片懶加載等。此外跟終端一樣也關(guān)注渲染性能,遵從一些規(guī)則避免頁面reflow,避免使用CSS陰影這樣耗性能的特效,用CSS3動(dòng)畫代替js等。
編譯
終端開發(fā)需要編譯的過程,把程序編譯成機(jī)器語言,再與各種庫鏈接后生成平臺(tái)對(duì)應(yīng)的可執(zhí)行文件,最后由操作系統(tǒng)調(diào)度執(zhí)行。在iOS終端開發(fā)中編譯和鏈接的規(guī)則蘋果已經(jīng)在xcode這個(gè)開發(fā)工具上封裝好,一般開發(fā)可以不用關(guān)心,但有深層需求時(shí)還是需要跟編譯打很多交道,例如用編譯前端Clang自定義靜態(tài)代碼檢測(cè)規(guī)則,寫編譯腳本做自動(dòng)化編譯和持續(xù)集成,打包生成靜態(tài)庫,根據(jù)鏈接后的可執(zhí)行文件的組成優(yōu)化APP體積等。
前端開發(fā)的程序則不需要編譯過程,只需要把代碼扔給瀏覽器,瀏覽器邊解析代碼邊執(zhí)行。雖然js/css代碼寫完無需做任何事情瀏覽器就可以解析執(zhí)行,但為了上面說的性能優(yōu)化,前端代碼上線前會(huì)對(duì)所有代碼和資源文件進(jìn)行處理,這些處理包括:壓縮合并js/css,合并css sprite圖,處理模塊依賴,處理代碼資源版本號(hào),處理資源定位等。這個(gè)過程很像傳統(tǒng)程序的編譯,把給人看的代碼優(yōu)化處理成給機(jī)器看的,并解決一些依賴關(guān)系,可以算是前端的編譯過程。像grunt.js/fis這些工具可以幫助完成這個(gè)編譯過程,通常前端編譯跟上線部署結(jié)合在一起,作為上線系統(tǒng)的一部分。
安全
前端和終端的安全性問題上雖然不需要像后端考慮得那么多,但還是有些需要注意。在請(qǐng)求的安全上,終端和前端都一樣,用戶向后端發(fā)送的請(qǐng)求都需要經(jīng)過層層路由,不知道在哪里就被截獲篡改或回放了,于是需要做一些措施防御這些情況,最常見的就是身份驗(yàn)證,多是采用會(huì)過期的token形式代替用戶名密碼,防止被抓包后黑客可以永遠(yuǎn)登陸這個(gè)賬號(hào)。數(shù)據(jù)安全要求高的會(huì)用加密傳輸,或者使用https,另外還需要看情況處理一些DNS劫持,運(yùn)營(yíng)商廣告植入等問題。
其他安全問題終端很少考慮,在未越獄的iOS機(jī)器上系統(tǒng)已經(jīng)幫忙保證了整個(gè)APP運(yùn)行環(huán)境的安全,而在越獄的機(jī)器下惡意程序擁有root權(quán)限可以做任何事情,APP也難以防范。前端方面瀏覽器的特性使前端開發(fā)有幾個(gè)安全隱患,一是web頁面上任意位置都可以動(dòng)態(tài)插入js代碼,瀏覽器會(huì)無區(qū)別地執(zhí)行這些代碼,二是身份驗(yàn)證信息都統(tǒng)一保存在cookie里,三是頁面上可以隨意通過iframe嵌入其他網(wǎng)站的頁面。造成XSS、CSRF、cookie劫持這些攻擊手段,所以前端寫代碼時(shí)都需要考慮還這些安全問題,做好相應(yīng)的防范,最簡(jiǎn)單和重要的防范就是對(duì)所有用戶輸入輸出的內(nèi)容做完整的過濾,避免頁面內(nèi)被嵌入惡意代碼。
交互/開發(fā)
最后說下對(duì)這兩個(gè)領(lǐng)域在交互和開發(fā)上的個(gè)人感觸。以前在做web前端時(shí),感覺web讓人機(jī)交互倒退了十年,交互都是硬邦邦的點(diǎn)擊—啪一下出來結(jié)果,滾動(dòng)是一格格地刷新,很多人當(dāng)時(shí)在鼓吹html5可以做出多么炫的效果時(shí),實(shí)際上FLASH在十年前就可以做出來了,還比最現(xiàn)代的瀏覽器更流暢。iPhone流行后,人機(jī)交互終于恢復(fù)了應(yīng)有的水平,體驗(yàn)上比web流暢太多,指尖交互/流暢的動(dòng)畫/便捷的滑動(dòng)手勢(shì)/無限制的實(shí)現(xiàn),主流終于恢復(fù)或超越了十年前Flash的水平。