«В чём причина?» — такой первый вопрос я бы советовал задавать перед решением каждой ошибки и задачи.
«Вижу следствие» — в начале своего пути разработчик чаще всего стремится исправить ошибку как она есть, а не разобраться глубоко, какой причиной она была вызвана.
Простой реальный пример с проекта, над которым я сейчас работаю.
Заголовок страницы написан заглавными буквами «ПРОДУКТЫ» вместо «Продукты».
Следствие: видно сразу — быстро поправить и забыть про этот баг. Минимум приложенных усилий.
Причин может быть несколько:
Нет договоренности с дизайнерами, в каком едином стиле должны быть заголовки. Решение - обсудить с дизайнерами и стандартизировать работу с заголовками.
Неправильно переопределена глобальная тема для Typography: кто-то когда-то давно так сделал. Решение - изучить темы и привести к единому виду.
Предыдущий разработчик или дизайнер (легаси) думал, что заголовки всегда должны быть заглавными буквами и делал их такими во всех своих страницах. Решение - просмотреть другие страницы и поправить их тоже.
Переход от бездумного комбайна по исправлению следствий до поиска причин и их исправлений характеризует один из основных качественных ростов разработчика от Junior до Middle‑Senior.
Важно! — иногда лучше решить ошибку сразу быстро, а потом завести задачу на исправление причины в целом.
Если у вас есть свои примеры, напишите в комментариях. Думаю, такой опыт будет полезен для новых разработчиков.
Фильм «Хористы» и Акция‑Реакция
Для более глубокого понимания этой темы предлагаю вам посмотреть гениальную комедийную драму «Хористы» 2004 года и подумать над вопросом: «Я сейчас работаю через Акцию или Реакцию?», где учителя — это фреймворки и библиотеки, а ученики — это наши ошибки и задачи.
Трейлер на https://www.kinopoisk.ru/film/51481/ - а сам фильм вы знаете где можно посмотреть бесплатно :)
В чём причина появления фреймворков?
На глобальном уровне фреймворки стараются минимизировать количество таких возможных причин. Правда, архитектурные решения фреймворка не всегда удачны и они порождают новые виды причин, с которыми мы работаем ежедневно.
Фреймворки и библиотеки декларируют решаемые проблемы на их главной странице.
Несколько положительных примеров:
$mol - актуальность через отсутствие версионирования, реактивность по умолчанию, локализация и тестирование из коробки, уменьшение бойлерплейта шаблонов верстки.
React - упрощение шаблонов верстки, огромная экосистема, популярность благодаря Facebook.
Vue - приятная и понятная документация, удобные шаблоны, хорошая оптимизация и сборщик на VIte с HMR.
Фреймворк выбирается один раз на проект, а задачи и ошибки в проекте появляются каждый день.
Основная идея данной статьи
Над текущей (будущей) ошибкой или задачей задайте себе вопрос «В чём причина?» — это поможет улучшить качество вашей работы и откроет новые варианты её решения. Это может быть сложно.
Постарайтесь этот вопрос довести до автоматизма для лучшего качества вашей работы.
Комментарии (23)
Abobcum
11.08.2023 16:35+7Поддерживаю, лучше задавать этот вопрос 5 раз подряд.
К сожалению, у меня на работе первый вопрос "кто виноват", а второй "как его наказать". Ох уж это советское наследие.
LyuMih Автор
11.08.2023 16:35Спасибо.
Это моя реальная история - мне такой вопрос (в чём проблема?) задалл тимлид и направил думать в этом русле.
У нас на работе был следующий механизм "как его наказать" - кто накосячил, тот и должен исправить. Даже если уже прошло несколько релизов.
Это было больно, но отрезвляюще
PereslavlFoto
11.08.2023 16:35+1Итак, тимлид задал вопрос, в чём проблема. Ему ответили, что проблема простая: эта ерунда с сайтом никому не интересна и никто не относится к ней всерьёз, потому что она не приносит дохода. Следовательно, накосячил сам тимлид и он должен исправить приоритеты. Но у него нет времени заниматься всякой ерундой вроде вебсайта. А если он будет отрывать людей от работы ради вебсайта, сам же потеряет в доходах.
Что дальше?
LyuMih Автор
11.08.2023 16:35В статье расматревался вопрос от тимлида к веб-разработчику и вебсайт являлись для обоих источником доходов, а не всякой ерундой.
Не могу ответить на твой вопрос "Что дальше?", т.к. не понял кто ответил тимлиду. Вроде как по комменатрию явно не веб-разработчик.
А может у нас разные тимлиды попадалисьPereslavlFoto
11.08.2023 16:35+1Ах, если бы вебсайты были источником дохода для веб-разработчиков, тогда веб-разработчикам не пришлось бы наниматься! Они просто создавали бы сайты и имели оттуда доход.
Тимлиду ответили его подчинённые. Те самые люди, которые занимаются веб-сайтом, и одновременно с этим занимаются разной другой работой.
dyadyaSerezha
11.08.2023 16:35+2И все же я бы сначала ограничился простым фиксом и поговорил с автором коммита этого заголовка. А уж если такая фишка встречается неоднократно, тогда можно и потратить дополнительно4 время на поиск другой причины.
Fen1kz
Интересный список положительных примеров, первым (лол) в списке идет местячковый фреймворк от местного тролля :D
Вопрос к троллю - в чем прикол пиарить свой $trash фейками?
zede
Вы правда верите, что все кто хвалят $mol это фейки?
Я могу понять неоднозначную реакцию на автора, но сама технология от этого не становится $trash-ом, как вы позволяете себе выражаться (с высокой долей вероятности не попробовав его толком)
mayorovp
Фреймворк, создающий сайты, которые принципиально не способны индексироваться поисковыми системами — это именно что $trash. А ещё и с неиндексируемой документацией — это $trash в квадрате.
LyuMih Автор
Согласен, это из минусов одностраничников SPA, которую в идеале бы решить. Она частично была решена, но пока не на уровне Next.js.
Вроде у чистого React SPA есть похожие проблемы с индексацией
mayorovp
Проблемы SPA решаются, как на уровне поисковых роботов, так и через SSR.
Но $mol добавляет сюда ещё и неотключаемую виртуальную прокрутку.
nin-jin
Разумеется отключаемую. Учитывая, что $mol наиболее гибкий фреймворк из ныне существующих, подобные инсинуации выглядят глупо. Впрочем, вам выставлять себя на посмешище не привыкать.
mayorovp
О неотключаемости виртуальной прокрутки я узнал из надёжного источника — комментария автора $mol на Хабре. И кто здесь выставляет себя на посмешище-то?
nin-jin
Тот, кто не понимает очевидного сарказма.
nin-jin
Не надоело ещё эту чушь тиражировать?
https://yandex.ru/search/?text=%24mol+site%3Ahyoo.ru
mayorovp
А теперь попробуем найти кусок текста и упс: site:hyoo.ru "зачастую импортируются сложносоставные имена типа"
Вот на этой странице текст есть, но в индекс он не попал: https://mol.hyoo.ru/#!section=docs/=xps6z2_b92esq
nin-jin
Hardcoin
Это далеко не всем нужно. То, что закрыто логином и паролем и не должно индексироваться.
LyuMih Автор
Да.
Делали лендинг на самых простых технологиях, которые хорошего индексировались и показывали отличные WebVitals. Они были
А сам личный кабинет и приложение были уже на субдомене, где индексация и СЕО не нужны, т.к. и так уже пришли через лендинг. Все оставались довольным
mayorovp
С одной стороны — да, так и есть. С другой стороны, использование для публичной и приватной частей разных технологий влечёт за собой необходимость делать одно и то же по два раза.
LyuMih Автор
Однажды дизайнер сам сделал лендинг на https://elementor.com/ и остался очень доволен своей работой)
А мы уже к нему прикрутили личный кабинет, хех
LyuMih Автор
Спасибо, это эпичный дебютный первый комментарий на мою первую статью)
1. Не фейк, можешь написать в личку убедиться https://t.me/mikhail_eco_coach . Всегда открыт к беседе
2. Написал для себя пару пет проеков на моле, разобрался в нём, мне понравилось. Продолжаю работать официально на реакте.
3. Как и написал, каждый фреймворк ставит во главу угла решение конкретного ряда проблем. $trash фреймворк не является исключением. Список можно продолжать до бескончости.
Если ещё остались вопросы, задавай