Почистване на CSS кодовата база
Току-що се присъединихте към съществуващ проект за заместване на заминаващ разработчик. Или може би просто са се заели със стария си проект няколко години по-късно. Изглеждате ужас и отвращение, когато погледнете кода. Можете да направите само едно: изчистете цялата тази бъркотия. Срещали ли сте нещо подобно преди? Почти сигурно, рано или късно, всеки ще се изправи пред него.
Знаете, че почистването на CSS е голяма задача. Трябва да се направи много за ограничен период от време - особено когато клиентите/шефовете/колегите силно съветват да не пипат това, което работи. Дори не знаете откъде да започнете.
Но днес късметът е на ваша страна - готов съм да споделя с вас моите решения за почистване на кода и да ви дам съвети как да ги използвате. Наистина се свежда до най-простите неща.
Обшиването е нашето всичко
Първото нещо, което съм свикнал да правя, когато трябва да разбера кодова база, е свързването. Свързването е процес на изпълнение на програма, търсеща потенциални грешки и лоши практики. Вярвам, че изчистването на нашия код е първата стъпка към добрия код. Етимологията на думата linting може да бъде намерена в тази тема на StackOverflow.
Sass има Ruby linter, наречен SCSS-lint. Можете да го персонализирате сами или да изтеглите конфигурацията, препоръчана от Sass-Guidelines, за да започнете веднага. Също така Node.js има sass-lint, те не са 100% съвместими и може да работят по различен начин.
Опитайте да стартирате SCSS-Lint в директорията на Sass за грешки. Шансовете са много големи, че ще получите много грешки. Обикновено след това искате да спрете да експериментирате с почистване на код. Бъди търпелив. Сега можете да опитате да направите конфигурацията по-малко строга по отношение на правила, които не са много важни за вас (като например формата за определяне на цветовете) или да хванете бика за рогата и да използвате пълната сила на облицовката.
Коригиране на намерените грешки
Време е да се оправи, какво трябва да се поправи. Това може да стане по два начина. Първият е да проверите всички файлове на свой ред и да поправите всички грешки и недостатъци, като неуспешно именуване на променливи, прекомерно влагане на селектори и лошо форматиран код. Вторият (предпочитаният от мен) използва find and replace. Не знам за вас, но обичам регулярните изрази и винаги обичам да ги използвам в работата си.
Наскоро създадох хранилището scss-lint-regex на GitHub, за да събера всички регулярни изрази за свързване на едно място. Не забравяйте да го разгледате, ако имате проблеми с свързването на голям проект. И бъдете внимателни с намирането/замяната, понякога това води до неочаквани странични ефекти. След всяка промяна стартирайте git diff, за да разберете какво се е променило, това ще гарантира, че няма да добавяте грешки към кода си.
След като приключите с редактирането с търсене/замяна, няма да можете да избегнете ръчното редактиране на местата, които трябва да бъдат прецизирани (грешно отстъпване, липса или излишък на празни редове, липсващи интервали и т.н.). Отнема много време, но ще ви помогне много в следващата стъпка, така че е важно да направите това, преди да продължите напред.
Бележка на преводача
Преразглеждане на структурата на проекта
Това, което наистина ме притеснява, когато се присъединя към съществуващ проект, е липсата на подходяща архитектура на проекта. Може би в самото начало на работата имаше някакъв проект, но с времето нещата излизат извън контрол и първоначалната идея се губи. Но все пак е изключително важно.
Изборът на методологията на проекта не е толкова важен, основното е, че го имате и не ви създава дискомфорт. Може да бъде SMACSS, 7-1 или ITCSS - изборът е ваш. Опитайте се да преструктурирате кода си според избраната от вас техника. Склонен съм да използвам модела 7-1, който разработихме в Sass Guidelines, така че ще ви дам няколко съвета, които да ви помогнат, ако изберете този път.
Започнете със създаването на директория на доставчик, като тази стъпка обикновено е ясна. Преместете в него всички допълнителни библиотеки от разработчици на трети страни (библиотеки, които не са зависимости за npm или Bundler).
Тогава нека отидем в директорията с резюмета. Всички променливи, комбинации, функции и заместители трябва да бъдат разположени тук. Можете да ги подреждате както искате, докато не разберете всички променливи и комбинации във вашата кодова база. На този етап аз също идентифицирам незадължителни променливи (и комбинации), защото често се налага да се справям с променливи, използвани веднъж или два пъти.
След като разберете, ще трябва да решите коя от следващите две стъпки да предприемете първо. Можете да се опитате да се уверите, че цялото съдържание на основната директория е наистина основни стилове, а не стилове на компоненти. Или проверете дали директорията за оформление съдържа всичко, свързано с оформлението на страницата и дали този код е документиран правилно.