前端程序員能力不足？表如今哪幾點，你須要增強的地方！

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

那麼問題就暴露出來了，當對先後端能力要求、測試要求不同多不同可貴時候，前端就會團隊中處於短板，這在中小公司很常見。由於優質的前端是稀缺資源。

突出問題一　前端能力不足

問題列表

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

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

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

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

開發時過於粗糙，不能綜合考慮各類數據狀況、操做的容錯性很差

貌似其餘職能沒毛病

解決方案

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

普及模塊化開發的基本方式，加強寫註釋、團隊協做的培養

學會本身的妥善分類，對於需求、缺陷等明確分類，參照前端總體分類

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

請問各個其餘職能有作好本身的事情麼，是否夠專業，如今只是由於前端的問題是暴露出來的而已，咱們的後臺、設計、產品、測試都無可挑剔嗎。若是真這樣，爲何不把前段淘汰或者這些人去更好的公司謀求更好的待遇和發展空間。

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

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

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

測試應該有本身基本的測試準則，不要每次都沒有準則，沒有原則的去測試所有的需求，個性化的測試咱們要儘可能規避，儘可能約定統一的規則，儘可能參照原型以及需求來進行相關的測試，默認認爲若是符合產品設計的90以上的要求，那麼這輪測試纔是符合產品和開發預期的，而不是直接70以上的測試提的問題都是產品從沒提過的、沒說要作的。

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

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

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

問題１：爲何以前bug的有那麼多，還能上線

問題２：爲何那麼多的bug都必須是當天提，當天改的，有這樣嚴重麼

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

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

突出問題四　前端暴露出來不少分支提交問題

１首要責任在前端

２前端作很差，爲何不讓有能力的人去作，或者交給他怎麼作

３是否是不少源代碼不是前端寫的也讓前端背鍋

４項目架構不明顯，增長了前端開發修改的難度，建議儘早先後端分離，而不是四不像的結構和合做方式

突出問題五　團隊協做

團隊協做須要有基本的協做常識，互相幫助，怎樣才能讓對方更方便高效的協做，創建基本的規則，若是不能保證各類個性化的要求的，就要給其餘職能提供最基本的原則性的支持。

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

每一個職能對於專業能力認識不夠，專業能力不足致使不少後續問題。因此職能主管或者職能培訓是必須的。