# 如何说服你的团队采用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代码包装在其中，仍是仅限于严格要求的地方？ 你作个研究并提供一个计划。 你的策略可能会随着时间的推移而发生变化，但你须要证实本身已经考虑过这个问题，以便为你的团队提供最顺畅的过渡策略。

提出方案
**
尝试并抓住机会向你的团队或领导提交你的方案。 若是你能让别人以为他们也是讨论方案的一份子，他们就更有可能加入。 此外，可能还有一些你没有想过的陷阱，他们能够指出，大家能够一块儿克服。

在组织内推进变革一般很难。 你最好的选择是突出好东西，确保你考虑任何缺点，试着抢先发现并解决问题。 最后，你会获得一些盟友！ 一块儿促进变革会容易得多！