Всем привет! 👋

Работая почти 10 лет в разработке, всё чаще замечаю, что многие фронтендеры приходят в профессию без формального IT-образования. Недавно наткнулась на статью, где автор — тоже без классического CS-бэкграунда — делится принципами, которые помогают ему принимать правильные решения «здесь и сейчас».

Мне, человеку с бакалавриатом и магистратурой, было особенно интересно почитать, что же он там написал 🙂

---

🧩 Про «умные» принципы, которые иногда только мешают

Автор пишет, что популярные советы вроде
YAGNI (You Aren’t Gonna Need It),
DRY (Don’t Repeat Yourself)
и «преждевременная оптимизация — корень всех зол»
звучат умно, но в реальной жизни часто создают больше путаницы.

И вот принцип, который действительно помогает ему в работе — правило трёх.

---

📌 Правило трёх

Рефакторить или оптимизировать код стоит только после того, как вы написали его три раза:

1️⃣ Первый раз — просто пишете код, который делает только то, что нужно.
2️⃣ Второй раз — появляется та же логика, и вы буквально копируете её, немного адаптируя.
3️⃣ Третий раз — у вас уже три подобные реализации, и теперь ясно, что обобщать, как упрощать и какой уровень абстракции действительно нужен.

Зачем так делать?
Потому что после трёх повторений вы уже точно знаете:

* что в логике действительно общее,
* что можно упростить,
* какой абстракции хватает,
* и не уйдёте в ненужный оверинжиниринг.

---

⚙️ Принцип «Make it work → Make it right → Make it fast»

Очень хочется оптимизировать всё сразу — но быстрый код часто менее читаемый.

Кент Бек предлагает простой порядок:

🔹 Работает? Если нет — сначала добейтесь этого.
🔹 Делает правильно? Если нет — исправьте логику, входы, поведение.
🔹 Достаточно быстро? Если нет — вот теперь можно оптимизировать.

Смысл простой: нет смысла улучшать код, который пока даже не работает или работает неправильно.

---

✔️ Как итог

Хорошие принципы помогают писать код, который:

* легко читать,
* легко понимать,
* легко изменять,
* легко тестировать.

А плохой код «плох по-разному»: слишком много ответственности, мешанина уровней абстракций, странные оптимизации, лишняя логика.

---

Ссылка на статью:
https://piccalil.li/blog/programming-principles-for-self-taught-front-end-developers/

Это не было бы так смешно, если бы не было правдой 😄
К сожалению, многие фронты порой настолько зациклены на том, чтобы просто сделать «работающий код», что забывают о «хороших манерах» — например, о том, что не только 200 считается успешным результатом. Есть ещё 201, 204 и другие кейсы ✅

И вообще, помимо привычных 200, 400, 404 и 500, существует множество других статус-кодов, которые могут значительно упростить логику на фронте и сделать API более понятным.

Я уже как-то писала пост с HTTP Code Cheatsheet — можете обратить внимание 👇
https://news.1rj.ru/str/frontenddevelopernews/60

Привет! ✨
Собрала полезные материалы для фронтендеров:

1. https://bespoyasov.ru/front-not-pain/
«Фронтенд — это не больно!» — статьи о том, как фронтендеру работать без стресса: взаимодействовать с дизайнерами, бэкендерами и тестировщиками, бороться с рутиной и выгоранием, организовывать рабочий процесс.

2. https://solidbook.vercel.app/
Подробная книга о принципах SOLID. Помогает разобраться, как строить гибкую, предсказуемую и поддерживаемую архитектуру.

3. https://www.patterns.dev/vanilla/module-pattern/
Большая коллекция популярных паттернов разработки в JavaScript, объяснённых просто и визуально. В том числе модульный паттерн и многие другие.

4. https://refactor-like-a-superhero.vercel.app/ru
Практическое руководство по рефакторингу. Чёткие советы, примеры и техники, которые помогают улучшать код без боли и риска всё сломать.

5. https://www.youtube.com/playlist?list=PLaIuVNKRYUyEoKnY0UwapHPk8fEaREHPA
Подробный видеокурс по Figma. По мне часто фронтендеру не хватает этого навыка даже в базовом виде.

Всем привет!
Наткнулась в интернете на статью, где автор делится вопросами, которые ему задавали на интервью в Amazon

Вопросы, которые задавали:

1. Что такое aria-label, aria-labelledby, aria-live — и для чего они нужны?
2. В чём разница между тегом <header> и заголовками <h1>…<h6>?
3. Что такое семантические классы и семантическое именование классов?
4. Каков будет вывод этого JavaScript-кода? (код про event loop)
5. Как «расплющить» (flatten) массив без array.flat()?
6. Реализация компонента Star Rating на React

Главные инсайты:

🔹 Никогда не недооценивайте базу. Даже если вы отлично работаете с React — важно помнить основы языка.

🔹 Коммуникация — это навык. Умение объяснить, *почему* вы делаете так, а не иначе, не менее важно, чем написать рабочий код.

🔹 Провал — это не приговор. Одно неудачное собеседование не определяет вашу ценность.

Если вам интересно — можете почитать оригинал: https://ujjwal3009.medium.com/frontend-developer-interview-amazon-f61e780add81

💡 Идеальный программист

Навыки, которые присущи идеальному разработчику! 😍

Спустя долгое время в разработке я для себя вывела набор качеств, которые реально делают программиста крутым. И вот какие навыки я считаю самыми важными:

1️⃣ Умение не просто выполнять то, что написано в задаче, а понимать — нужно ли это вообще?
Продуктивность не измеряется количеством написанных строк кода.

2️⃣ Умение понятно излагать свои мысли
(в переписке, на созвонах, на ревью — где угодно)

3️⃣ Иметь свою точку зрения и уметь аргументировать её

4️⃣ Быть командным игроком и понимать, что у всех разный уровень
и это нормально 🙌

5️⃣ Постоянно развивать свои навыки и не терять энтузиазм к работе 🔥

А вы что думаете по этому поводу?

🎄 Advent of JavaScript

https://adventjs.dev/

Что это такое:

* 24 дня — 24 задачи на JavaScript / TypeScript / Python
* уровень задач от простых до реально сложных
* отлично прокачивает алгоритмы и логику
* и да, это бесплатно) пользуйтесь)

Всем привет!
Сегодня прослушала подкаст «Веб-стандарты» #509
и узнала для себя несколько новых и интересных вещей:

— Оказывается, существует специализированный браузер для веб-разработчиков, созданный именно для разработки и тестирования веб-сайтов, а не для обычного просмотра — Polypane
https://polypane.app/

— В подкасте обсуждали статью
https://polypane.app/blog/not-all-browser-apis-are-web-apis/
с говорящим названием о том, что не все браузерные API на самом деле являются «чисто браузерными».
Забавно, что API, которые мы всегда считали стандартными (например, Geolocation API, поддерживаемый и W3C, и MDN), для одних браузеров является платным, а для Chromium — нет.

— Слышали когда-нибудь про файл LLMs.txt?
Это Markdown-файл для сайтов, предназначенный для предоставления контента, удобного для LLM.
Одно из ключевых преимуществ — снижение нагрузки на сайт.
https://llmstxt.org/

— И тут становится ещё интереснее. Думаю, многие из вас слышали новость:
6 января основатель Tailwind CSS Адам Ватан уволил 3 из 4 разработчиков из-за, цитирую, «жестокого влияния AI на наш бизнес».
Он подробно описал ситуацию в треде на GitHub, отклонив pull request с предложением сделать документацию, оптимизированную под нейросети:
https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957

> Трафик на нашу документацию упал примерно на 40% с начала 2023 года, несмотря на то, что Tailwind популярнее, чем когда-либо. Документация — это единственный способ, которым люди узнают о наших коммерческих продуктах, а без клиентов мы не можем позволить себе поддерживать фреймворк.

Подробности тут:
https://dev.to/kniraj/tailwind-css-lays-off-75-of-engineering-team-as-ai-tools-disrupt-revenue-model-1l3d

— К слову, трафик MDN тоже снизился — во многом из-за активного использования LLM.

— В подкасте обсуждали ещё одну статью, но я хочу сначала внимательно её прочитать и уже потом поделиться своими мыслями.

В целом подкаст мне очень понравился, интересно было следить за дискуссией ребят, поэтому я решила сразу поддержать их на Patreon 💙
Ниже будет репост этого выпуска 🎧

Выпуск №509. Никита Дубко и Вадим Макеев про антивебные API для веба, как LLM и помогает, и убивает Tailwind и про нездоровую зависимость от бандлеров.

— Лайв на Ютубе
— Слушайте на Ютубе
— Ссылки на сайте