Фёдор Борщёв

Заметки с тегом «Школа»

Форма, функция и красота

В «Коммуникации Систем» мы много говорим о понятиях system form и system function. Форма — это как система выглядит: на какие модули разбита, с какими данными работает. Функция — то, что система делает: как реагирует на ввод, что отдаёт на вывод.

Форма и функция выходят далеко за рамки IT и проектирования. Это, скорее, про красоту. Вещи, в которых форма подчинена функции — красивы. Вещи, в которых функция размыта, а форма сложна — некрасивы и неприятны.

К примеру макбуки, Dell бизнес-серий, дорогие thinkpad — красивы: дают много возможностей владельцу и не отвлекают формой. Игровые ноутбуки и всякие дешёвые асусы — некрасиво, потому что их главная функция — блистать на полке в магазине. Есть и исключение — Framework: вроде бы и красивые штуки, но вот функция, которую они выполняют, — быть ремонтопригодный в домашних условиях, — вряд ли понадобится кому-то в здравом уме.

А сколько же на улице некрасивых машин! Дорогие немцы, в большинстве своём — некрасивы: функции размыты, а форма требует постоянного обслуживания. Исключение — разве что Майбахи, заточенные под перевозку одного пассажира, или BMW M-серии, сделаные для кольца: с такими функциями можно и хрупкую форму потерпеть. Маленькие SUV, которыми забит рынок — некрасивы: форма как у дешёвых ноутбуков, пригодна только стоять в автосалоне и говорить неискушённому потребителю «не думай, купи меня, я сгожусь на любой случай жизни».

Чувство прекрасного отдыхает на утилитарных пикапах вроде Toyota Tundra или том, что в штатах называют «траками»: они много возят, когда надо — быстро едут, а простое шасси и атмосферный мотор будут хоть 20 лет выполнять свою функцию. Очень красивы велосипеды на которых ездят курьеры: быстрые, лёгкие, ничего лишнего.

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

Форма эволюционирует вместе с функцией. К примеру Медиум когда-то был отличным средством для публикации лонгридов, а в процессе эволюции превратился в пейвольную помойку — очевидно, новая форма стала более выгодна владельцам. Или взять любой продукт Яндекса — почти везде его функция со временем перестаёт интересовать владельцев. Так навигатор превратился в тормозные «карты», а сервисы доставки еды и такси превратились в мигающий попапами и требующий кучи лишних кликов Yandex Go. Вообще, «экосистема» это что-то на шейрхолдерском, а не на пользовательском.

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

Ищем, куда девается время программистов

В октябре 2024 года прочитал в Алматы короткий вводный доклад о том, чем полезен DevEx, и как он вообще работает. Если никогда не слышали — посмотрите, если слышали — посмотрите школьный курс.

LMS для Школы Сильных Программистов

У Школы Сильных Программистов была небольшая LMS. Делать её решили потому, что принятый в индустрии Getсourse превращает редактирование уроков в мучение (в школе привыкли писать и редактировать в Notion), а пафосные опенсорсные LMS вроде moodle годились для чего угодно, кроме обучения взрослых людей. К тому же почти во всех курсах внедрена сложна фича, которую не найти в готовых продуктах — p2p-проверка домашки, когда одни студенты смотрят и ревьюят работу других: это экономит время экспертов и здорово повышает доходимость.

Первую версию в школе написали на коленке — рендерили материалы из ноушена, но уже с профилем студента (для диплома), минимальной навигацией и кнопочкой сапорта. Написали, запустили, прожили год, а потом устали — код был не очень: фичи не попилишь, едущую вёрстку не поправишь.

Решили, раз уж все гипотезы доказаны, просто переписать всё без новых фич, но с нестыдным кодом. Сформулировали вот такую задачу:

  • Нормальный код покрытый тестами
  • Хороший дизайн и UI-kit
  • Удобная мобильная версия для чтения на ходу

Старт

Для старта работ у нас было:

  1. Бекенд на Django, покрытый тестами
  2. Код текущего фронтенда LMS
  3. Большой пост с описанием функциональности

Старый код рефакторить было бесполезно, так что решили выкинуть всё и написать всё с нуля, ориентируясь на пост с постановкой задачи. Причин для такого решения было две:

  1. Писать хорошую дизайн-систему с нуля проще, чем рефакторить старую
  2. Cтарая LMS была написана на Vue 2, а в то время уже вышел Vue 3, в котором появилась поддержка Typescript, а ещё крутой туллинг в виде Vite и Pinia

С решением не ошиблись, получилось быстро и круто.

Редизайн LMS мы решили делать прямо в коде. Используя старую LMS как вайрфреймы, мы собрали все страницы внутри Storybook на мокнутых данных из фейкера.

Чтобы дизайн был консистентным и не отнимал много времени, мы взяли Tailwind — его атомарность позволяла быстро примерять разные варианты, а токенизированность упрощала создание компонентов в единой стилистике.

Материалы

Материалы для LMS пишутся в ноушене и отдаются на фронтенд через хитрое API. Бекенд нужен, чтобы контролировать доступ к материалам, кешировать их (чтобы грузилось быстрее, чем в самом ноушене) и немножечеко его менять, чтобы было просто рендерить на фронте.

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

Забегая вперёд: такое решение — единственная сложная часть LMS. Реализации рендеринга на Vue печальные: одна очень плохо написана, а другая редко обновляется. Сейчас мы форкнули удачную реализацию и обновляем её сами (к счастью, ноушен ничего не меняет, поэтому это не много работы).

Почему просто не использовать маркдаун? Маркдаун нужно уметь писать, а курсы в школе пишут не только программисты. Кроме того, наладить простое (git — это не простое) совместное редактировние текстов в маркдауне — тяжёлая задача.

Домашки

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

Ответы на домашку ученики пишут в удобном WYSIWYG редакторе. Редактор собран на основе tiptap. Чтобы оживить общение между студентами, мы добавили возможность оставлять реакции.

Профиль студента

По окончании каждого курса школа выдаёт кайфовый диплом: можно положить в LinkedIn, добавить в резюме или просто повесить на стенку. Чтобы в диплом было вписано корректное имя пользователя, мы сделали раздел «профиль», где студенты заполняют свои данные На странице настроек ученик управлет своими данными, а также указывает информацию, которая появится на дипломе.

К моменту работы над этой страницей уже скопилось достаточно полей, которым нужна была валидация. Делать хорошую валидацию сложно и долго, а делать среднюю — просто долго. Хотелось найти вариант, над которым не придётся думать, но при этом он будет точно понятен пользователям.

На бекенде уже была сделана хорошая валидация с понятными текстами ошибки. Чтобы забыть про валидацию на фронтенде раз и навсегда ответы с бекенда в выводятся в тосты. Перехват ошибок делается на уровне axios и все ошибки ловятся автоматически, без использования try … catch.

Релиз и что дальше

От старта до готовности к релизу прошло три месяца. Чтобы не релизить в праздники, мы решили потратить декабрь на дополнительные фичи, а после нового года выкатили её для всех учеников.

Релиз прошел плавно. В том, что так будет, мы были уверены — код был хорошо покрыт тестами.

Дополнительно убедиться в том, что новые фичи не развалили все прямо перед релизом, помогали тесты на визуальный регресс. Они сравнивают скриншоты актуального интерфейса с тем, как он выглядит в мастере, и показывают различия если что-то поменялось. Чтобы написать такой тест, нужно добавить историю в Storybook и написать тест который ходит туда через Playwright, делает скриншот и сравнивает его. Через такой такой тест не пройдут ошибки, затрагивающие рендер, в том числе ошибки на уровне CSS.

Код проекта открытый. Посмотреть можно на гитхабе.

Технологии: vue3, pinia, vitest, playwright.

Разработчик и автор статьи: Тимур Брачков.

В гостях у Ивана Самолова

Недавно меня позвал в гости Иван Самолов. Поговорили буквально обо всём, что меня волнует — о бизнесе с Саматом, о том, как (не) нанимать программистов, как системно вести подход к личному бренду и о том, откуда в телеграме в последний год взялось столько мусорных ИТ-каналов.

Отдельная важная часть — о Школе Сильных Программистов: в этом интервью я впервые публично сформулировал наши цели и подходы.