本文將對前端架構遺漏的知識點進行補充說明，包括文檔輸出、系統分解、組件提取和發布優化這四個部分
1、在多人協作過程中會存在一些問題:
a、文檔制定的寫作要求比較高, 要有結構化, 邏輯清晰, 寫得好, 寫得快, 還要注意排版才能適合他人閱讀;
b、系統比較複雜文檔篇幅會很長, 達到幾百頁以上難以花過長時間通篇閱讀,照成很多細節一帶而過;
c、規格能夠滿足需求不一定符合開發邏輯, 制定者需要與開發人員協商;
d、既要滿足需求又要滿足開發者的閱讀;
e 、措詞的歧義, 個人理解上有差異, 丟三落四, 內容不完整, 出現錯字等等;
2、在後續工作與復用方面，也會存在問題:
a、難以形成最終版本的規範, 後續需要不斷修改再修改, 修改會給後續人員帶來額外的開銷;
b、如果需求發生變化需要重新設計規範, 軟體的體系結構也需要大大小小的修改;
c、規範的重用性與製定者的設計水平息息相關;
d、復用後的文檔同樣難免會出現丟三落四, 內容遺漏, 涵蓋原有設計未被修改或未刪除等問題;
# 在實際開發中，對系統進行分解的難點和需要考慮的問題如下:
1、分解的主要困難在於怎麼拆分,拆分的是否合理;
2、各個業務功能都有聯繫, 從哪裡進行拆分?
# 3.拆分的模組可不可以再拆分?
4、分解的粒度是否合理, 每個模組都有各自的細分, 拆分到模組級別還是類級別?
5、分解容易造成過渡分解或過早分解, 增加成本還會帶來風險;
6、拆分的模組是否可以復用?
7、分解後是否能夠很好的整合?
8、保證對交互稿做到100%的分解, 並且不允許漏掉任何一個模組, 稍有疏漏就會對後續開發造成影響;
# 9.如何依照時間規定內完成分解, 否則整體進度要延期;
根據交互提取通用組件，需要進行以下操作
1、把交互稿依照層次劃分，提取相似的部分；
## 2、再進一步劃分，提取更小的組件； 3、確保每個組件相對獨立，和其它組件沒有重複的地方； 4、拆出來的組件盡可能簡單，可以被重用； 5、例如按鈕，圖標，分頁，導航，菜單，列表，輪播圖等等； 6、將這些元件組合起來能夠還原交互稿； 發布最佳化 專案發佈時，需要進行以下最佳化 1、檔案快取。配置超長時間的本地緩存，節省頻寬，提高效能；採用內容摘要作為快取更新依據，實現精確的快取控制，同時實現資源的非覆蓋式發布， 保證平滑升級# 2、靜態資源CDN部署，最佳化網路請求回應 3、資源合併與最佳化。檔案合併，模組化會導致HTTP請求大量增加；圖片優化，包括圖片壓縮和雪碧圖合併（看起來像現在都流行用iconfont實現這塊）等#
以上是前端架構的知識點的詳細內容。更多資訊請關注PHP中文網其他相關文章！
