# 如何說服你的團隊採用CSS Grid

如何說服你的團隊採用CSS Grid

原文地址

做者：CSSInRealLife@創做時間：2019-03-09
翻譯&校驗：freedom

你是否是想使用CSS Grid佈局但又難以說服你的團隊其餘成員（你的同事或者你的領導）？ 最近有人問我，有什麼建議能夠說服對CSS Grid持有懷疑態度的團隊在他們的工做流中採用CSS Grid。 雖然我本身在這方面沒有遇到任何重大障礙， 但我常常聽到一個這樣的故事。 你已經準備好潛入並使用最新的現代佈局技術，卻只有更高的權利才能推進。

儘管有點使人沮喪，可是存在便是合理。讓咱們打破它吧！

做爲旁註，這些想法來自我在網絡代理商的經驗。 我並非要聲稱要分享每一個人的經驗，而其餘環境可能須要採用不一樣的方法。 可是我認爲這裏有一些廣泛並且有效的建議。

他們爲何須要說服力？

瀏覽器支持
**
不採用Grid的最多見緣由是瀏覽器支持。 雖然Grid在全球範圍內擁有大約85％的瀏覽器支持，但其餘15％的瀏覽器已經中止支持。 這些用戶中有很大一部分是在IE上，從IE10開始，它實際上支持CSS Grid的舊語法。 （我將留下你是否想在某天想支持舊語法的問題，但若是你想沿着這條路走下去，這裏有一篇好文章。）這些用戶須要的佈局至少是可用。 這讓我想到了第二個問題......

時間成本
**
若是並不是全部瀏覽器都支持CSS屬性，則須要提供合理的回退。 在單獨使用單個屬性的狀況下（例如混合模式），編寫額外的一行或兩行可能至關簡單，使用戶可以以有用（或者次優）的方式體驗你的內容。 這是漸進式加強。

使用像Grid這樣的一個完整規範，若是你將其做爲主要佈局策略，它將不只影響一個或兩個元素，並且影響整個網頁。 因此這是一個略有不一樣的故事。 你須要確保提供合理的回退，不管你使用哪一種策略來支持舊版瀏覽器。 我不會否定有時這須要一點時間。

若是你團隊的其餘成員還不熟悉Grid，那麼在讓每一個人都熟悉新的佈局策略時，還須要考慮時間因素。 須要讓你們離開現有項目一天左右投資這項培訓，他們可能會感到緊張。

可維護性
**
有些團隊可能會擔憂，當團隊中的其餘人拿起你的項目進行工做時，他們會發現維護起來比較困難，由於你使用的是不熟悉的CSS，而不是X框架。 與此相關，使用Grid構建佈局有不少不一樣的方法。 例如，若是一我的使用網格線命名而另外一我的使用grid-template-areas命名，則可能會產生至關不一致的代碼庫，而且可能會讓須要從新接手該項目的人感到頭痛。

全部這些緣由歸結爲時間和金錢的成本。 咱們須要作的是讓你的團隊相信Grid能夠爲二者提供幫助。

Grid能夠解決什麼問題？

如今讓咱們看一下使用Grid如何幫助解決上述問題，甚至解決更多的其餘問題：

複雜佈局能夠節省大量的時間
**
Grid極大地簡化了之前佈局須要大量hack和polyfill)的過程。 若是你須要使用較舊的佈局方法破解複雜設計，那麼你將浪費寶貴的時間。 固然，你還須要爲舊版瀏覽器提供可用的後備方案，但一般不須要花費大量時間。

若是你的團隊使用較舊的佈局技術編寫本身的網格框架，那麼這一切也須要不少時間和精力。

擁抱創造力
**
若是設計師、開發人員和團隊想要突破界限並構建真正富有創意的現代佈局，從人羣中中脫穎而出並擁抱網頁設計思惟的新時代，那麼Grid就是其中不可或缺的一部分。 Grid使咱們可以構建之前用CSS沒法實現的佈局。

性能更好
**
許多項目爲了實現網格系統導入了大型，笨重的CSS框架。即便是最小的類也可能最終添加了許多額外的類，這些都會增長CSS文件的重量。 對於與「標準」列和行不一樣的複雜佈局，你可能須要求助Javascript庫。 在我看來，咱們幾乎確定在2019年已經不須要藉助額外的JS來處理佈局（除了極少數例外）。 CSS Grid能夠用不多的代碼處理許多複雜的狀況。

還有一些跡象代表，使用flexbox建立網格設計的性能較差 - 儘管我沒法在相同級別的細節上找到更多資源。

更方便維護
**
由於Grid只是原生CSS，因此它不會有被破壞的風險，或者你必須在一年的時間內重構項目的風險。 它本質上是穩定的。 瀏覽器支持只會變得更強大。 相反，依賴框架或者庫會破壞項目。 他們須要維護。 你可能必須在一兩年內從新訪問一個項目，但卻發現它使用的是再也不主動維護的舊網格框架，或者你使用的版本已過期而你沒法找到文檔。 衆所周知的像Bootstrap這樣的框架可能不太可能出現這個問題，但它們會帶來性能權衡。

一樣，投資你的團隊學習網格是對將來的安全投資。 它不是一個在幾年內就會過期的框架，它的CSS基礎仍然存在。 這些技能將在將來許多年內發揮做用。

如何說服你的團隊？

網站沒必要在全部瀏覽器中看起來都同樣
**
我相信最大的障礙是有一個對Grid常見的誤解，認爲普遍採用Grid就是網站在全部瀏覽器中看起來都同樣。 不幸的是，一般領導認爲就是這種狀況，或者沒法與客戶溝通清楚。 沒有人但願你的客戶在運行IE9的古老吱吱做響的機器上打開你漂亮，閃亮的新網站，並馬上大吃一驚，它不能辜負設計。

這意味着你須要將案例提早進行漸進式加強，並確保在更高級別進行通訊。 讓領導和設計師瞭解舊瀏覽器的侷限性，以及實現設計在全部瀏覽器看起來相同所須要的成本。 這不該該是一個一個項目須要考慮的，而是整個組織的策略。

我知道改變整個組織的思惟方式聽起來很難，並且不太可能在一晚上之間發生。 我看到的一個想法是設計師實際設計一個簡化版的網站，做爲徹底支持版本的後退版本呈現給客戶端，就像它們呈現移動和平板電腦版本的設計同樣。 經過這種方式，客戶端意識到某些瀏覽器將得到更簡單的佈局，而且沒有什麼大驚喜。 此外，設計師實際上能夠以一種看起來很好的方式設計它，而不是依賴於開發人員的解釋。 雖然不可避免地會涉及更多的設計時間，但在開發方面能夠節省不少。 我但願看到這種方法變得更加廣泛。

如今試試吧！

你沒必要全力投入Grid - 它不必定是一種全有或全無的方法。 引入Grid的最佳方法之一是從較小的UI模塊開始。 這樣你就有機會在視覺上展現它的好處，並但願學好它 - 或者至少激起你團隊裏其餘成員的好奇心。 經過展現而不是直接說出來的方式一般更好。

使用網格與現有佈局系統並無什麼不妥，並且人們對此感到滿意。 這給了你學習下一部分的時間......

制定策略
**
正如我以前提到的，有不少方法可使用Grid構建佈局。 你須要考慮你和你的團隊將如何實施制定的策略，以確保一致性，確保維護不會成爲問題。 你可能會認爲，一旦每一個人都學會了基礎知識，那麼他們可使用他們喜歡的任何方法來完成工做，或者你可能決定僅僅使用行號進行放置並避免grid-template-areas，例如，爲了不混淆。 你可能決定爲最多見的佈局需求建立一些實用的程序類，或者你可能決定將網格代碼與組件緊密耦合。

你還須要考慮瀏覽器支持策略。 你應該使用@supports並將全部Grid代碼包裝在其中，仍是僅限於嚴格要求的地方？ 你作個研究並提供一個計劃。 你的策略可能會隨着時間的推移而發生變化，但你須要證實本身已經考慮過這個問題，以便爲你的團隊提供最順暢的過渡策略。

提出方案
**
嘗試並抓住機會向你的團隊或領導提交你的方案。 若是你能讓別人以爲他們也是討論方案的一份子，他們就更有可能加入。 此外，可能還有一些你沒有想過的陷阱，他們能夠指出，大家能夠一塊兒克服。

在組織內推進變革一般很難。 你最好的選擇是突出好東西，確保你考慮任何缺點，試着搶先發現並解決問題。 最後，你會獲得一些盟友！ 一塊兒促進變革會容易得多！