隨著前端越來越多的被提上日程，用戶對(duì)產(chǎn)品的體驗(yàn)度要求越來越高，產(chǎn)品除了實(shí)用的特性還必須滿足方便用，美觀，交互好，人性化等一系列的操作，誰的產(chǎn)品先做到這些，就能獲取用戶的青睞。那么這樣一來，前端無形當(dāng)中追加了很多工作量，所以前后端分離是趨勢，不可能要求后臺(tái)去很多精力花費(fèi)在幫我們吧數(shù)據(jù)和前端的靜態(tài)效果以及相關(guān)的資源整合上。讓大家分別去做各自擅長的事情。

那么問題就暴露出來了，當(dāng)對(duì)前后端能力要求、測試要求不一樣多不一樣難得時(shí)候，前端就會(huì)團(tuán)隊(duì)中處于短板，這在中小公司很常見。因?yàn)閮?yōu)質(zhì)的前端是稀缺資源。

突出問題一　前端能力不足

問題列表

某些特性化的，有難度的需求做不來

代碼的模塊化，可維護(hù)性不強(qiáng)

修改ｂｕｇ的能力以及效率有限

分不清楚優(yōu)化、需求、缺陷、bug不同等級(jí)

開發(fā)時(shí)過于粗糙，不能綜合考慮各種數(shù)據(jù)情況、操作的容錯(cuò)性不好

貌似其他職能沒毛病

解決方案

需求走前端部門統(tǒng)一評(píng)審，按照難度等級(jí)、可實(shí)現(xiàn)等級(jí)、替代方案處理，不計(jì)入基本的開發(fā)中

普及模塊化開發(fā)的基本方式，增強(qiáng)寫注釋、團(tuán)隊(duì)協(xié)作的培養(yǎng)

學(xué)會(huì)自己的妥善分類，對(duì)于需求、缺陷等明確分類，參照前端整體分類

基本的培訓(xùn)，案例分享，在產(chǎn)品不做相關(guān)處理的時(shí)候，希望前端應(yīng)該有的基本處理

請問各個(gè)其他職能有做好自己的事情么，是否夠?qū)I(yè)，現(xiàn)在只是因?yàn)榍岸说膯栴}是暴露出來的而已，我們的后臺(tái)、設(shè)計(jì)、產(chǎn)品、測試都無可挑剔嗎。如果真這樣，為什么不把前段淘汰或者這些人去更好的公司謀求更好的待遇和發(fā)展空間。

突出問題二　需求不明確，測試提需求加優(yōu)化

首先不可否認(rèn)，測試可以提一些優(yōu)化或者特殊的需求，但是如果這個(gè)比例遠(yuǎn)遠(yuǎn)超過了bug本身的比例，那么這部分就是不合理的，應(yīng)該從以下幾個(gè)角度避免。

產(chǎn)品原型最大程度的明確應(yīng)該有的產(chǎn)品細(xì)節(jié)，包括各種數(shù)據(jù)，數(shù)據(jù)可能情況，意外情況，用戶交互，交互效果，數(shù)據(jù)驗(yàn)證，插件，等等。舉例說明：產(chǎn)品不能說這個(gè)地方需要輪播圖，而應(yīng)該說是這個(gè)頁面什么位置出現(xiàn)多大規(guī)格的幾張輪播圖，最多幾張，最少幾張，播放效果如何，有沒有默認(rèn)圖，跳轉(zhuǎn)的鏈接是什么，圖片來源是什么，什么格式等。

測試應(yīng)該有自己基本的測試準(zhǔn)則，不要每次都沒有準(zhǔn)則，沒有原則的去測試全部的需求，個(gè)性化的測試我們要盡量規(guī)避，盡量約定統(tǒng)一的規(guī)則，盡量參照原型以及需求來進(jìn)行相關(guān)的測試，默認(rèn)認(rèn)為如果符合產(chǎn)品設(shè)計(jì)的90以上的要求，那么這輪測試才是符合產(chǎn)品和開發(fā)預(yù)期的，而不是直接70以上的測試提的問題都是產(chǎn)品從沒提過的、沒說要做的。

項(xiàng)目經(jīng)理控制好整個(gè)的測試聯(lián)調(diào)過程，保證基本的缺陷都解決的情況下，盡量在開發(fā)周期內(nèi)完成具體功能模塊完整的上線，對(duì)于不能很好的實(shí)現(xiàn)的，被砍掉的需求要做到下一版本的迭代，而不是全部列入bug修改中。

測試以及聯(lián)調(diào)修改過程中沒有周期版本性概念，一直是不間斷的斷續(xù)的提問題，而對(duì)于所有問題沒有任何規(guī)律性，等同于過篩子，期望是整體過一遍功能后，模塊仔細(xì)測，保證模塊可用，而不是每個(gè)模塊都測點(diǎn)，最后每個(gè)都有問題，都不能上。

突出問題三　線上版本bug多，發(fā)現(xiàn)就及時(shí)改

問題１：為什么之前bug的有那么多，還能上線

問題２：為什么那么多的bug都必須是當(dāng)天提，當(dāng)天改的，有這樣嚴(yán)重么

問題３：我們提的bug有沒有規(guī)律性，是無意發(fā)現(xiàn)的還是必然的，我們是否經(jīng)常進(jìn)行大規(guī)模的一次產(chǎn)品優(yōu)化，吧這些納入到開發(fā)狀態(tài)，而不是一味的不斷續(xù)的改問題

問題４：當(dāng)天問題當(dāng)天改，能改完么，改的這些bug誰會(huì)記錄，屬于哪個(gè)產(chǎn)品版本

突出問題四　前端暴露出來很多分支提交問題

１首要責(zé)任在前端

２前端做不好，為什么不讓有能力的人去做，或者交給他怎么做

３是不是很多源代碼不是前端寫的也讓前端背鍋

４項(xiàng)目架構(gòu)不明顯，增加了前端開發(fā)修改的難度，建議盡早前后端分離，而不是四不像的結(jié)構(gòu)和合作方式

突出問題五　團(tuán)隊(duì)協(xié)作

團(tuán)隊(duì)協(xié)作需要有基本的協(xié)作常識(shí)，互相幫助，怎樣才能讓對(duì)方更方便高效的協(xié)作，建立基本的規(guī)則，如果不能保證各種個(gè)性化的要求的，就要給其他職能提供最基本的原則性的支持。

人員角度的互相幫助，責(zé)任是要追究的，但是團(tuán)隊(duì)需要互相體諒，共同承擔(dān)壓力和責(zé)任的，遇到問題要溝通問他，幫他解決問題。只有最上面的人才是boss，可以只關(guān)心任務(wù)和結(jié)果，每個(gè)團(tuán)隊(duì)的具體成員都關(guān)心的是自己如何去實(shí)現(xiàn)，有什么難度，如果做不到，誰可以幫我；如果做得好，怎么分享給其他人；如果自己有能力有經(jīng)驗(yàn)去幫別人做點(diǎn)事情。

每個(gè)職能對(duì)于專業(yè)能力認(rèn)識(shí)不夠，專業(yè)能力不足導(dǎo)致很多后續(xù)問題。所以職能主管或者職能培訓(xùn)是必須的。

總結(jié)

以上是生活随笔為你收集整理的前端程序员能力不足？表现在哪几点，你需要加强的地方！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。