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

那么問題就暴露出來了，當對前后端能力要求、測試要求不一樣多不一樣難得時候，前端就會團隊中處于短板，這在中小公司很常見。因為優質的前端是稀缺資源。

突出問題一　前端能力不足

問題列表

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

代碼的模塊化，可維護性不強

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

分不清楚優化、需求、缺陷、bug不同等級

開發時過于粗糙，不能綜合考慮各種數據情況、操作的容錯性不好

貌似其他職能沒毛病

解決方案

需求走前端部門統一評審，按照難度等級、可實現等級、替代方案處理，不計入基本的開發中

普及模塊化開發的基本方式，增強寫注釋、團隊協作的培養

學會自己的妥善分類，對于需求、缺陷等明確分類，參照前端整體分類

基本的培訓，案例分享，在產品不做相關處理的時候，希望前端應該有的基本處理

請問各個其他職能有做好自己的事情么，是否夠專業，現在只是因為前端的問題是暴露出來的而已，我們的后臺、設計、產品、測試都無可挑剔嗎。如果真這樣，為什么不把前段淘汰或者這些人去更好的公司謀求更好的待遇和發展空間。

突出問題二　需求不明確，測試提需求加優化

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

產品原型最大程度的明確應該有的產品細節，包括各種數據，數據可能情況，意外情況，用戶交互，交互效果，數據驗證，插件，等等。舉例說明：產品不能說這個地方需要輪播圖，而應該說是這個頁面什么位置出現多大規格的幾張輪播圖，最多幾張，最少幾張，播放效果如何，有沒有默認圖，跳轉的鏈接是什么，圖片來源是什么，什么格式等。

測試應該有自己基本的測試準則，不要每次都沒有準則，沒有原則的去測試全部的需求，個性化的測試我們要盡量規避，盡量約定統一的規則，盡量參照原型以及需求來進行相關的測試，默認認為如果符合產品設計的90以上的要求，那么這輪測試才是符合產品和開發預期的，而不是直接70以上的測試提的問題都是產品從沒提過的、沒說要做的。

項目經理控制好整個的測試聯調過程，保證基本的缺陷都解決的情況下，盡量在開發周期內完成具體功能模塊完整的上線，對于不能很好的實現的，被砍掉的需求要做到下一版本的迭代，而不是全部列入bug修改中。

測試以及聯調修改過程中沒有周期版本性概念，一直是不間斷的斷續的提問題，而對于所有問題沒有任何規律性，等同于過篩子，期望是整體過一遍功能后，模塊仔細測，保證模塊可用，而不是每個模塊都測點，最后每個都有問題，都不能上。

突出問題三　線上版本bug多，發現就及時改

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

問題２：為什么那么多的bug都必須是當天提，當天改的，有這樣嚴重么

問題３：我們提的bug有沒有規律性，是無意發現的還是必然的，我們是否經常進行大規模的一次產品優化，吧這些納入到開發狀態，而不是一味的不斷續的改問題

問題４：當天問題當天改，能改完么，改的這些bug誰會記錄，屬于哪個產品版本

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

１首要責任在前端

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

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

４項目架構不明顯，增加了前端開發修改的難度，建議盡早前后端分離，而不是四不像的結構和合作方式

突出問題五　團隊協作

團隊協作需要有基本的協作常識，互相幫助，怎樣才能讓對方更方便高效的協作，建立基本的規則，如果不能保證各種個性化的要求的，就要給其他職能提供最基本的原則性的支持。

人員角度的互相幫助，責任是要追究的，但是團隊需要互相體諒，共同承擔壓力和責任的，遇到問題要溝通問他，幫他解決問題。只有最上面的人才是boss，可以只關心任務和結果，每個團隊的具體成員都關心的是自己如何去實現，有什么難度，如果做不到，誰可以幫我；如果做得好，怎么分享給其他人；如果自己有能力有經驗去幫別人做點事情。

每個職能對于專業能力認識不夠，專業能力不足導致很多后續問題。所以職能主管或者職能培訓是必須的。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。