前端開發胡扯

前端開發胡扯

js嘛入門確實容易。一個記事本編輯、瀏覽器查看就OK。

不按期更新。徹底想到啥說啥！歡迎指教！

流程

只是項目開發流程！！！畢竟眼界和格侷限制了自個人想象力。

產品方案 > 需求&設計 > 需求討論（開發、測試 跟進和評估 可行性、時間週期、成本等）> 相關開發組開發 & 測試用例（包括部分測試腳本等）> 測試（開發自測、單元測試、SIT 集成測試、UAT 產品&設計等驗收測試）> 一鍵部署 > 後續迭代。

產品方案怎麼落地不太懂。

產品

一個想法、服務、功能點

• 好比 營銷活動、會員服務等內部產品通常 涉及的 利益方比較少；溝通和實施起來比較容易！
• 全網積分兌換、乘車碼 等涉及到跨組織的就比較難協調各方利益。

產品可行性。

• 是否合規、當前技術是否可行（好比目前大熱的AI智能都難以達到咱們的指望）等。
• 根據可行性考慮是否須要 調整 和 分拆 可實施的階段性產品。

產品方案。

• 不一樣可行性方案間成本和收益的評估和選擇；固然想大廠也能夠多團隊、多方案內部競爭。

注：產品方案通常還只是一個大概的、各方負責人確認的可執行的實施方案。後續還須要各方就達成的方案協調推動、各司其職。（後面只談開發方相關的一些我的想法；畢竟財務、市場等其餘方的工做流程不懂）

需求

需求 就是以書面的形式 儘可能具體的把可執行的產品方案 告訴團隊內 各成員。以便一線員工能夠有效的溝通和協調去推動方案的實施和落地。因此沒有需求是確定無法動工的。就算是簡單的產品方案，非 小創團隊（注：小創團隊，非公司！！！）最好仍是要需求文檔；避免頻繁的更改、推諉。徒增內部的溝通成本和返工成本！

• 版本迭代：大版本、長週期的需求 能夠分拆；經過快速迭代，能夠減小風險、根據反饋調整後續需求，提高用戶體驗。
• 需求儘可能具體、考慮邊界狀況。好比用戶系統：用戶忘記密碼、忘記帳號的業務流程；各類提示語等。

需求預溝通

• 需求 發送 設計、開發、測試、運營等項目開發相關方負責人（羣發也行；提早了解一下，作個心理準備）
• 原型設計、定稿（具體的高保真設計圖能夠晚一些）。開發方案、測試用例等。
• 充分溝通、調整以後 出需求稿、定排期。

需求溝通：

• 產品、開發、測試、運營 相關方經過短會最終確認一下 排期、版本功能點。

準備下一個 產品方案的需求文檔！

設計

需求排期後根據設計終稿 儘快出 高保真圖。避免影響前端UI開發。

終稿交付就能夠投入到下一個需求的設計中去了！

開發層面

• 可擴展和配置化、多技術棧支持！
• 單開項目維護UI的開發。各項目間經過版本控制。基礎組件儘可能維持穩定。
• 可採用 配置文件（vari）、基礎樣式（base 無類、純dom標準化瀏覽器 樣式和common 項目基礎樣式）、組件文件（component、page）等 樣式文件維護。這樣方便 zepto、vue、react等技術棧共用樣式。具體樣式腳本 less、sass、stylus等均可以！
• 組件內的變量 儘可能繼承（默認取）配置值。方便在各組件中修改默認值，而不是直接聯動。

UI 組件化

• ui分基礎控件和業務組件。

基礎控件 應該是無關業務的。任何公司團隊均可以使用，好比boostrap。這一類的通用UI控件在PC、特別是CMS後臺管理平臺是很是好用的（核心關注點在功能實現上）。而移動端不多有通用型的UI控件流行，公司層面不但願千篇一概、同時移動佈局相對簡潔。因此基礎的通用UI控件目前主要針對公司內各團隊使用，避免一個APP（公司）不一樣業務團隊的產品五光十色、重複開發等。

特殊 定製的 UI 控件能夠 在項目中新增配置 文件覆蓋（較多時、固然也能夠更新到基礎控件中去）或者項目代碼中覆蓋（較少時）

業務組件 和產品需求相關。隨着產品迭代週期變化；抽離出來是方便各頁面共用時避免重複開發。

具體能夠 參考element ui 等實現方案！

字和顏色

• 字體問題不談（須要單獨引入字體文件，用戶手機定製主題字體問題在安卓機比較多）
• 子高 問題不談 （不一樣字體的子高不同）

只談 行高、行間距、字號（字體大小）

因此設計稿中儘可能 行高、行間距、字號。

• 字號越少越好維護和管理。方便配置管理！ 切換夜間模式或者不一樣主題色方面比較方便。
• 顏色 同上

備註

以上字號和顏色 儘可能少的建議 主要是針對 基礎UI和業務組件UI。特殊活動頁或者定製（節日）啥的想怎麼炫酷和腦洞都行。只要大家開心就行。

圖標

• 圖標 按業務或者尺寸 分類都行。
• 經過工具生成雪碧圖。
• 大量使用也能夠 維護一份iconfont 圖標庫（設計維護）
• 基礎公用的icon 儘可能單色。

邊界

• 設計圖多考慮一下邊界狀況的展現。

沒有結果展現、多（少）於設計個數、超出（少於）設計行數 等！

開發

都說IT碼農、搬磚工。說明平常的業務開發確實不難。畢竟產品邏輯 需求都已經幫忙寫的很清楚了;開發只是經過代碼去實現產品邏輯而已。難在架構，但沒有大的業務量 每每談不上架構。因此大多數開發更多的問題在於規範和開發環境。

開發規範

• 千人千面。GitHub上也有不少大公司開源的推薦規範
• 建議：借鑑他人好的規範，慢慢造成本身團隊的開發規範。
• 規範維護：採用 eslint。

支持通用的規範配置。

個性化的內部規範能夠在GitHub上新建一個項目；去維護本身的規範插件。

經過打包腳本控制規範的執行。不符合規範的代碼不允許打包編譯！

小部分無法插件自定義的規範能夠在代碼走查或者AB角中審覈！

開發文檔

• 最好經過測試腳本和規範的代碼維護。核心代碼仍是維護一下文檔比較好。或者經過工具生成；避免更新不及時形成的溝通問題！
• 業務代碼 文檔仍是算了吧。可能業務更新的，文檔或者註釋沒更新啥的 反而形成沒必要要的麻煩！（只能第一次開發時有空多寫點註釋！）或者業務代碼要求通常代碼一半註釋吧！反正業務文檔是有點難以維護。因此開發交接他人的業務代碼通常更願意重寫！

代碼結構

• 經過抽離一些基礎服務、共用層 簡化平常開發；更好的聚焦在業務代碼實現上！
• 總的來講就是 確保項目搭建好以後，平常開發只須要關心本身的業務邏輯，其餘的功能 都經過標準化的 API 輸出給 各頁面調用。 無需關心內部封裝實現、依賴、配置等；只關心入參出參 的黑盒子！
• 前端來講能夠 抽離 客戶端交互、通用的ajax封裝、和其餘業務基礎服務。

核心的共用層代碼最好 有自動化測試 代碼。保證核心代碼質量，同時也方便升級和維護。對外輸出或者多團隊共用的最好提供開發文檔（建議經過工具直接輸出）。

部署一個測試頁面也是 有必要的。畢竟前端瀏覽器、手機、系統平臺兼容性問題仍是挺多的。而不是等到具體業務使用時發現 核心代碼的兼容性問題。

• 後端 基礎的路由層、業務層、數據層。具體開發一樣只須要 關心 具體接口的 業務實現。

路由層標準化 接口的入參、出參和基本的校驗。

後臺 相對來講 沒有複雜的兼容性環境。核心代碼的自動化腳本更好維護。

• 統一參數格式。

參數傳遞方面我我的偏心對象單一參數。node 的(err,data)也不錯。共用層面的代碼 固定形式的參數 最好造成統一。具體什麼格式均可以吧；只要避免像業務代碼那樣千人千面的傳參格式就好！

• 統一狀態碼。

統一 成功回調 （100）;參數層面錯誤（1xx）;數據庫層面錯誤（3xx）、業務層面錯誤（4xx）等狀態碼的配置。最好經過狀態類的方法調用，避免人爲設置錯誤的維護問題！

聯調

• 開發中分 客戶端、後臺、前端等 是爲了你們專一在最擅長的地方協調分工高效的完成項目！本質上聯調就是調用一個API；和調用本身的基礎服務沒啥區別，只是跨平臺致使的環境問題更多一些！
• mook階段各平臺 同步開發，能夠經過mook 數據確保基本邏輯。聯調階段最好仍是有 和測試、生產相近的 開發環境。
• 經過 統一開發平臺 客戶端能夠隨時更新 開發調試包；前端、後臺能夠隨時 打包部署 到開發環境。儘可能把更多的問題在開發環境中發現和解決！

代碼管理

• git版本管理這沒啥說的，看看第一大同志社區github就足夠說明了。
• 開發聯調完，提測到測試環境 就要準備 下一個迭代版本的需求開發中去了。因此這時候打版本分支並行開發。等發佈生產以後 再合併到主幹中來。至於生產以後的bug能夠經過生產的tag代碼緊急修復，不急的小bug能夠在下個版本中更新上去！

測試

測試、開發的合理比例是多少不是很清楚。但測試是確保代碼沒bug的最後一關。開發容易順着產品邏輯去實現；忽略了用戶的各類逆操做致使的bug。對於生產上的平常bug，我我的認爲測試應該負主要責任。

測試的工做一樣也是在需求溝通會以後就開始針對每一個版本功能點寫測試用例。 儘量的覆蓋不一樣的操做流程。

版本問題

• 測試包的部署 和開發環境同樣；經過一個統一的開發平臺打包部署。只是權限在測試，同時對每一個測試包 生成一個tag。
• 測試環境非嚴重影響系統運行的bug儘可能不要頻繁的發包，有bug先經過開發平臺 提給對應的開發 在開發環境中解決。通常附上 復現流程、場景。等bug集中解決或者確認 修復以後再 經過 打包部署複測一下！
• sit測試以後，可讓產品方進行uat測試。都測試驗收 以後就能夠經過最新的測試tag包 生成一個生產包。
• 規範版本流程 和開發的規範 同樣；都是爲了平常核心的工做只需 專一在版本的功能點上。 而不是浪費在頻繁變動、環境不可控等人爲致使的故障排查上。保證測試環境 準生產環境的穩定性都不爲過。

運營

• 產品數據、生態的維護。生產穩定的保證。

cms

• 做爲平臺的數據來源，維度越豐富越好，校驗越嚴越好。
• 再保留原始錄入的狀況下，有些能夠預處理的數據儘可能也在cms中解決。避免在用戶使用的 實時處理；提高用戶體驗！
• cms相對於外部用戶系統來講性能上要求沒那麼高。建議採用node；

一方面能夠直接讓前端開發，這樣能夠緩解大部分公司前端人員配置緊缺的問題（雖然客戶端通常也少，不過對於大多數的混合開發的APP來講，客戶端只是一個能夠定製功能的純容器；相對來講工做量沒那多大）；

另外一方面在內部積累必定開發經驗的狀況下，後續能夠把node投入到營銷活動、頁面直出、中間服務等開發中！

發佈

• 平常的版本發佈，我認爲只須要提交一下系統平臺；都運營那邊就能夠自動化部署。
• 很是規的可能須要提供一下其餘的配置、依賴等。
• 同 開發、測試同樣。儘可能自動化、規範化，畢竟腳本比人更穩定、可靠！更多的去完善腳本、數據收集、統計、系統預警等。

參考