Redux: Реанимируем легаси проект

Тут всё как в обычном CSS. Более подробный CSS-path имеет более высокий приоритет. xl здесь ретебьет md, потому что завязан на data-атрибут

Redux: Реанимируем легаси проект

Когда я делаю фичи, то пишу код сначала в одном файле и по мере необходимости его разбиваю на части. С tailwind я просто беру кусок JSX--ины, делаю ctrl+x и ctrl+v в новом файле. Всё. С css-модулями такой подход к написанию кода будет более медленным и менее удобным, чем с tailwind

Пиши простой код

Наверное, это был проект, написанный по FSD :)

Жизнь в Финляндии: честный опыт

Но рыба в Финляндии действительно вкуснее, и её много. В Питере хрен найдешь не сухую красную рыбу горячего копчения. И это очень грустно!

Redux: Реанимируем легаси проект

export const Button = (props) => {
  return (
    <button
      data-full-width={props.fullWidth}
      data-rounded={props.rounded}
      data-disabled={props.disabled}
      className='h-10 px-5 sm:px-10 rounded-md w-full sm:w-auto
                 cursor-pointer outline-none border-none
                 flex sm:inline-flex items-center justify-center 
                 transition-all ease-linear duration-300
                 text-thin-14 sm:text-regular-16 
                 data-[full-width]:flex data-[full-width]:w-full
                 data-[rounded]:rounded-xl
                 data-[disabled]:opacity-50 data-[disabled]:pointer-events-none
                 sm:hover:bg-purple-3 active:bg-purple-2'>
      {props.children}
    </button>
  )
}

/* main.css  */

@import "tailwindcss";
@layer components {
  .text-thin-14 {
    font-size: 14px;
    font-weight: 300;
    line-height: 14px;
    letter-spacing: 0.02em;
    font-family: lalala;
  }

  .text-regular-16 {
    font-size: 16px;
    font-weight: 400;
    line-height: 16px;
    letter-spacing: 0.02em;
    font-family: lalala2222;
    color: #afceff;
  }
}

Redux: Реанимируем легаси проект

На каждую технологию найдется свой проект, в котором ничего хорошего не было :)

Ну вы там выше писали, что проект был большой, и над ним работало несколько команд параллельно. Я в таких условиях Tailwind не использовал. Вполне допускаю, что при росте команды он будет вставлять палки в колеса. В больших командах использовал только CSS модули. Tailwind использовал в команде из трёх человек максимум.

Но это не отменяет личных предпочтений :) Если мне нужно написать что-то для себя, то я возьму Svelte и Tailwind и напишу фронтенд почти с закрытыми глазами. Но ни Svelte, ни Tailwind не популярны на "рынке труда"

Redux: Реанимируем легаси проект

На каждую технологию найдется свой проект, в котором ничего хорошего не было :)

Ну вы там выше писали, что проект был большой, и над ним работало несколько команд параллельно. Я в таких условиях Tailwind не использовал. Вполне допускаю, что при росте команды он будет вставлять палки в колеса. В больших командах использовал только CSS модули. Tailwind использовал в команде из трёх человек максимум.

Но это не отменяет личных предпочтений :) Если мне нужно написать что-то для себя, то я возьму Svelte и Tailwind и напишу фронтенд почти с закрытыми глазами. Но ни Svelte, ни Tailwind не популярны на "рынке труда"

Redux: Реанимируем легаси проект

В простынях нет ничего страшного. Самый большой минус простыни лишь в том, что она выглядит некрасиво на слайде для конференции или в листинге кода внутри книжки :)

Redux: Реанимируем легаси проект

Я понимаю вас, тоже писал на модулях и SCSS, но они в моём личном рейтинге стоят на втором месте. Всё, что вы написали, справедливо, но лично мне гораздо удобнее и быстрее работать с Tailwind.

Это удобство сложно объяснить, это что-то на уровне того, как вы (и я в личных беседах) пытаетесь объяснить удобство Mobx людям, которые его никогда не пробовали. У них всегда в запасе есть какие-то теоретические возражения, которые на практике при работе с Mobx даже и не встречаются. С Tailwind, на мой вкус, такая же история.

Честно говоря, когда впервые увидел что вам Tailwind не нравится, то сильно удивился, потому что по всем остальным глобальным вопросам во фронтенде мы, кажется, сходимся :)

Redux: Реанимируем легаси проект

Такие длинные классы только выглядят непривычно, но на практике работу ускоряют очень прилично (ссылок на пабмед не будет, это личный опыт). Если одинаковую вёрстку нужно использовать в нескольких местах, её можно обернуть в компонент, но вы это и так понимаете, просто вредничаете:

export const Content = ({ children }: PropsWithChildren<{}>) => {
  return (
    <div className="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
      <div className="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">
        {children}
      </div>
    </div>
  );
};

Для меня лично самый большой плюс Tailwind'а -- это отсутствие головной боли от придумывания бесконечного количества имён для классов. Пусть лучше будет bg-green-100 text-green-900 text-sm, чем name-wrapper, user-wrapper-container и прочие абсолютно искусственные наименования, которые никак не помогаю понимать и быстро менять код

Почему заводить «Алису» в доме с детьми — плохая идея?

На уроках русского языка в белорусских школах пишут "белорусский". А на уроках беларускай мовы пишут "беларускі". "Беларуский" -- это уже трасянка, которую почему-то любят в интернетах.

Роберт, ты мне не дядюшка

Вся книга на таких примерах строится. Ещё один пример, который "ближе к жизни и не алгоритмический" в комменте разобрал: https://habr.com/ru/articles/875426/comments/#comment_27818290

Роберт, ты мне не дядюшка

Это не моя трактовка, это трактовка российского издания 2016 года выпуска. Вырван ли это текст из контекста? Да! Поэтому в цитате стоит многоточие в квадратных скобках и написана страница, где текст можно почитать целиком.

Дал ли я свою трактовку прочитанному? Да! Всё люди пропускают потребляемую информацию через собственный фильтр. Но если посмотреть на то, насколько сильно российское айти-сообщество тащиться от этой книги, такую трактовку дал не только я.

Роберт, ты мне не дядюшка

В книге есть примеры и реального кода. В другой ветке его прокомментировал: https://habr.com/ru/articles/875426/comments/#comment_27818290

Роберт, ты мне не дядюшка

А в чём здесь идея? В длинных нечитаемых названиях методов, скрытых сайд-эффектах и неявном дата-флоу? Код для бизнеса от такого лучше не станет.

Если что, в книге есть не только такой алгоритмический пример. Всю третью главу Мартин ссылается на листинг 3.7. Это реальный код из библиотеки для тестирования Fitnesse. В нём чуть больше ста строк кода, поэтому уберу под спойлер, но его обязательно стоит почитать.

Пример реального чистого кода

package fitnesse.html;

import fitnesse.responders.run.SuiteResponder;
import fitnesse.wiki.*;

public class SetupTeardownIncluder {
  private PageData pageData;
  private boolean isSuite;
  private WikiPage testPage;
  private StringBuffer newPageContent;
  private PageCrawler pageCrawler;


  public static String render(PageData pageData) throws Exception {
    return render(pageData, false);
  }

  public static String render(PageData pageData, boolean isSuite)
    throws Exception {
    return new SetupTeardownIncluder(pageData).render(isSuite);
  }

  private SetupTeardownIncluder(PageData pageData) {
    this.pageData = pageData;
    testPage = pageData.getWikiPage();
    pageCrawler = testPage.getPageCrawler();
    newPageContent = new StringBuffer();
  }

  private String render(boolean isSuite) throws Exception {
     this.isSuite = isSuite;
    if (isTestPage())
      includeSetupAndTeardownPages();
    return pageData.getHtml();
  }

  private boolean isTestPage() throws Exception {
    return pageData.hasAttribute("Test");
  }

  private void includeSetupAndTeardownPages() throws Exception {
    includeSetupPages();
    includePageContent();
    includeTeardownPages();
    updatePageContent();
  }


  private void includeSetupPages() throws Exception {
    if (isSuite)
      includeSuiteSetupPage();
    includeSetupPage();
  }

  private void includeSuiteSetupPage() throws Exception {
    include(SuiteResponder.SUITE_SETUP_NAME, "-setup");
  }

  private void includeSetupPage() throws Exception {
    include("SetUp", "-setup");
  }

  private void includePageContent() throws Exception {
    newPageContent.append(pageData.getContent());
  }

  private void includeTeardownPages() throws Exception {
    includeTeardownPage();
    if (isSuite)
      includeSuiteTeardownPage();
  }

  private void includeTeardownPage() throws Exception {
    include("TearDown", "-teardown");
  }

  private void includeSuiteTeardownPage() throws Exception {
    include(SuiteResponder.SUITE_TEARDOWN_NAME, "-teardown");
  }

  private void updatePageContent() throws Exception {
    pageData.setContent(newPageContent.toString());
  }

  private void include(String pageName, String arg) throws Exception {
    WikiPage inheritedPage = findInheritedPage(pageName);
    if (inheritedPage != null) {
      String pagePathName = getPathNameForPage(inheritedPage);
      buildIncludeDirective(pagePathName, arg);
    }
  }

  private WikiPage findInheritedPage(String pageName) throws Exception {
    return PageCrawlerImpl.getInheritedPage(pageName, testPage);
  }

  private String getPathNameForPage(WikiPage page) throws Exception {
    WikiPagePath pagePath = pageCrawler.getFullPath(page);
    return PathParser.render(pagePath);
  }

  private void buildIncludeDirective(String pagePathName, String arg) {
    newPageContent
      .append("\n!include ")
      .append(arg)
      .append(" .")
      .append(pagePathName)
      .append("\n");
  }
}

Тут ровно такой же паттерн, как и в алгоритмическом примере: неявный дата-флоу и скрытые мутации. Есть только один плюс -- тут не такие длинные названия методов.

По поводу скрытых мутаций. Можно подумать, что Мартин не рассматривает изменение переменных своего класса как мутацию. Но вот цитата прямо из этой же третьей главы (страница 69).

Побочные эффекты суть ложь. Ваша функция обещает делать что-то одно, но делает что-то другое, скрытое от пользователя. Иногда она вносит неожиданные изменения в переменные своего класса -- скажем, присваивает им значения параметров, переданных функции, или глобальных переменных системы. В любом случае такая функция является коварной и вредоносной ложью, которая часто приводит к созданию противоестественных временных привязок и других зависимостей.

Я согласен с цитатой на все сто процентов. Но что мы видим в коде, который Мартин считает чистым, правильным и достойным находиться в его книге? Метод render принимает объект pageData и делает скрытую мутацию этого объекта в методе updatePageContent. Я бы никогда в жизни не ожидал, что передав pageData в статический метода SetupTeardownIncluder.render я получу мутацию. Почему рендер вносит какие-то изменения в контент страницы? Где здесь пресловутый принцип единственной ответственности?

У меня очень много вопросов к этому реальному коду! Зачем он сохраняет переменную isSuite на уровне инстанса класса? Если явно прокинуть её в методы, то код получится более... явный и простой в чтении. Почему он не использует собственный принцип "Один уровень абстракции на функцию" из этой же главы (страница 61), а вместо этого в метод render пихает сборную солянку: установку значения для переменной, два вызова приватных методов, возврат результата выполнения pageData.getHtml()? Я не джавист, но решил немного отрефакторить этот код. После рефакторинга сразу видно, что класс просто утилитарный, которому не нужно никакое внутреннее состояние, а мутация пусть и осталась (её здесь никак не убрать), но зато находится на самом видном месте. При желании весь этот код можно просто поместить внутрь класса PageData.

public class SetupTeardownIncluder {
  public static String render(PageData pageData) throws Exception {
    return render(pageData, false);
  }

  public static String render(PageData pageData, boolean isSuite) throws Exception {
    if (!pageData.hasAttribute("Test")) return pageData.getHtml();

    StringBuffer newPageContent = new StringBuffer();
    newPageContent
      .append(getContent(pageData, "SetUp", "-setup"));
      .append(pageData.getContent());
      .append(getContent(pageData, "TearDown", "-teardown"));
    
    if (isSuite) {
      newPageContent
        .insert(0, getContent(pageData, SuiteResponder.SUITE_SETUP_NAME, "-setup"));
        .append(getContent(pageData, SuiteResponder.SUITE_TEARDOWN_NAME, "-teardown"));
    }

    pageData.setContent(newPageContent.toString());
    return pageData.getHtml();
  }

  private static String getContent(PageData pageData, String pageName, String arg) {
    String pagePathName = getPagePathName(pageData, pageName);
    if (!pagePathName) return "";

    StringBuffer content = new StringBuffer();
    return content
      .append("\n!include ")
      .append(arg)
      .append(" .")
      .append(pagePathName)
      .append("\n")
      .toString();
  }
  
  private static String getPagePathName(PageData pageData, String pageName) {
    WikiPage testPage = pageData.getWikiPage();
    WikiPage inheritedPage = PageCrawlerImpl.getInheritedPage(pageName, testPage);
    
    if (inheritedPage == null) return null;

    PageCrawler pageCrawler = testPage.getPageCrawler();
    WikiPagePath pagePath = pageCrawler.getFullPath(inheritedPage);
    return PathParser.render(pagePath);
  }
}

Воспользуюсь фишечкой Роберта Мартина и изложу своё мнение о своём же рефакторинге в виде беспрекословных истин и не буду извиняться за свою категоричность. Код получился гораздо более явный и простой для понимания. В этот код легче и быстрее внести изменения, если этого потребует бизнес. Каждая функция внутри класса имеет явный инпут и аутпут и понятный дата-флоу, поэтому об этих функциях проще размышлять и их легко тестировать. Такой код достоин называться профессиональным.

Роберт, ты мне не дядюшка

Можно немножко навалить контекста. Изначально это был длиннющий код Кнута, который автор и решил "оптимизировать".

Длиннющий код — это не совсем то, что написал Кнут. Такой код получается, если конвертировать Кнутовский WEB в обычный код. Улучшать его — это что-то вроде рефакторинга JS файлов, скомпилированных из тайпскриптовых сорсов. Можно, но зачем?

Сам код написан в концепции Literate Programming и разбит на аккуратные составные части. Кнут тоже отделяет генерирование простых чисел от записи этих чисел в файл, и не сваливает весь код в одну кучу.

То есть, Мартин действительно рефакторит портянку. Но он сам получил эту портянку довольно странным образом и на нескольких страницах героически сражается с ней.

Роберт, ты мне не дядюшка

Сам Мартин в первой главе на страница 35 пишет вот так:

Мы излагаем свои мнения в виде беспрекословных истин и не извиняемся за свою категоричность. Для нас, на данном моменте наших карьер, они являются беспрекословными истинами. Они составляют нашу школу мысли в области чистого кода.
[...]
Мы утверждаем, что если вы последуете нашему учению, то это принесёт вам такую же пользу, как и нам, и вы научитесь писать чистый и профессиональный код.

Довольно близко к библии, заповедям и догмам.

Роберт, ты мне не дядюшка

Можно провести эксперимент и написать эти длинные названия по-русски

private static isPrime(candidate: number): boolean {
  if (this.являетсяНаименееРелевантнымКратнымСледующегоБольшегоПростогоМножителя?(candidate)) {
    this.кратныеПростымМножителям.push(candidate);
    return false;
  }
  return this.неКратенНиОдномуИзПредыдущихПростыхМножителей?(candidate);
}

Роберт, ты мне не дядюшка

Ни одна из этих разных школ не обладает абсолютной истиной. Тем не менее в рамках конкретной школы мы действуем так, будто её учение и арсенал приёмов верны.
[...]
Считайте, что эта книга является описанием Школы учителей Чистого кода. [...] Мы утверждаем, что если вы последуете нашему учению, то это принесет вам такую же пользу, как и нам, и вы научитесь писать чистый и профессиональный код. Но не стоит думать, что наше учение "истинно" в каком-то абсолютном смысле. Существуют другие школы и мастера [...].

Так он тут пишет, что никто не обладает абсолютной истиной. Но следование "Школе учителей Чистого кода" обязательно принесёт пользу и научит писать профессиональный код. Лично я читал эту книгу, чтобы сделать свой код "профессиональным", поэтому эти два абзаца забайтили меня не на поиск "других школ", а на следование учению "Школы учителей Чистого кода".

Если бы у книги цель была не в погружении в своё "учение", то альтернативные "школы" хотя бы были приведены списком. Я нашёл этот отрывок (Глава 1, страница 35). Ни до, ни после нет никаких примеров других "школ". Но зато есть несколько восхитительных цитат в начале страницы:

Мы излагаем свои мнения в виде беспрекословных истин и не извиняемся за свою категоричность. Для нас, на данном моменте наших карьер, они являются беспрекословными истинами. Они составляют нашу школу мысли в области чистого кода.
[...]
Они [ученики школы] посвящают себя изучению того, чему учит конкретный мастер, часто отказываясь от учений других мастеров.

Короче, для меня вся эта страница -- очень мощная агитка, которая призывает следовать "учению" Роберта во имя написания профессионального кода. Смотря на то, как глубоко эта книга сидит в головах многих программистов, агитка сработала на "отлично".

Роберт, ты мне не дядюшка

Потому что книгу 2008 до сих пор рекомендуют к прочтению, спрашивают про чистый код на собесах и срутся по поводу чистоты на код-реаью. Когда новая книга завирусится так же сильно, можно будет и её прочитать и покритиковать.