《編寫高質量代碼-Web前端開發修改之道》筆記--第二章 團隊合做

本章內容：

揭祕前端開發工程師

欲精一行，必先通十行

增長代碼的可讀性--註釋

提升重用性--公共組件和私有組件的維護

冗餘和精簡的矛盾--選擇集中仍是選擇分散

磨刀不誤砍柴工--前期的構思很重要

制訂規範

團隊合做最大的難度不是技術，是人

揭祕前端開發工程師

• CSS佈局是前端開發工程師的基本功，必定要熟練；
• 不只要會使用原生的JavaScript，還要會是使用JavaScript類庫和Ajax;
• 瞭解一門後臺語言
  1. 1.有助於編寫方便服務端工程師套腳本的模板；
  2. 2.在寫Ajax應用的時候，能夠本身模擬服務器端輸出，方便調試；
  3. 3.對前端和服務端如何配合有清晰的大局觀認識，瞭解數據傳遞的整個流程，以配合工程師共同制定複製效果的實現方案。
• 富媒體應用，如flash-ActionScript 開發。（附屬技能，多一技傍身，更強生！）

欲精一行，必先通十行

看到這個標題，有沒有想到「豆瓣-張克軍」畫的那張圖？一入眼是否是感受很恐怖？仔細看看，我相信很多人至少通一半。除了必要的專業技能，多瞭解瞭解那些須要通的內容，確實對咱們的幫助很大。

精一行之粒度細化問題：

1. 精的粒度越小，則就業範圍越小--自身使用價值也就越小；
2. 前端行業界限很是不明顯，多個領域滲透。例：ActionScript開發，須要前端與後端的配合，若是沒有相應的知識及整個流程，工做中則會困難重重。

十行：只須要知道，不須要精。在前端領域中，一專多能是很是有必要的。

增長代碼的可讀性--註釋

團隊合做中，必要的一種手段。不管有計劃的「直接團隊合做」和意外的維護他人代碼的「間接團隊合做」，保證代碼的可讀性良好的絕佳武器就是註釋。也有人在談論註釋的維護，說代碼被改，而不改註釋的問題，這種現象徹底是不負責的表現，扣他兩次工資，通報批評他兩次，也就漲記性了。頑疾必須重藥醫！畢竟你本身寫的代碼在過一段時間回來再看沒有註釋也會雲山霧罩不是？！

提升重用性--公共組件和私有組件的維護

團隊合做很容易產生的問題就是--冗餘。多我的分別寫了同一功能代碼，形成資源及其維護上的浪費。

避免冗餘最好的辦法就是根據代碼的重用度分爲共用組件和私有組件兩類。設計共用組件時須要考慮讓接口保持彈性，而且高度模塊化。共用組件的穩定性也要保持高度警戒，通常提供「讀」的權限。可考慮用SVN或規範團隊約定。

冗餘和精簡的矛盾--選擇集中仍是選擇分散

組織公共組件的粒度:

1.組織粒度越大，文件越集中，加載和管理越方便，但無用代碼越多；

2.組織粒度越小，文件越分散，加載和管理越麻煩，但無用代碼越少；

咱們要加載方便就要適當的捨棄精簡性，要保證精簡性就要適當放棄加載的方便性。咱們要認識到一點：完美的解決方案是不存在的，咱們只能在精簡和冗餘中儘可能找其中的平衡點。以JavaScript類庫中的jQuery和YUI來作對比，jQuery選擇了集中，YUI則是分散。

咱們得認識到，只可能儘可能減小冗餘，不可能根除冗餘。

磨刀不誤砍柴工--前期的構思很重要

對中大型網站來講，若是尚未一個考慮成熟的前端框架前就開始寫代碼是會帶來很是多的問題的，如代碼冗餘、多人合做容易衝突、代碼組織沒有規律等。

前期構思很重要。具體來講，構思的主要內容主要包括規範的制定、公共組件的設計和複雜功能的技術方案等。通常來講，前期構思佔整個項目30%-60%的時間都是正常的。

制訂規範

規範對於團隊合做是很是重要的。它能有效指導團隊成員按照一個統一的標準進行開發，儘可能讓開發過程平滑，減小沒必要要的衝突，提升開發效率並保證軟件的質量。

團隊合做最大的難度不是技術，是人

學會與人相處也是工程師必須的一門課，它的重要性甚至超過了技術自己。切記，能獨立決策的問題的都是小問題，須要與人協商的問題纔多是大問題，要學會與人相處。