​Как взаимодействуют frontend и backend ?

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

Архитектура взаимодействия
Фронтенд: Это часть веб-приложения, с которой взаимодействует пользователь. Она включает HTML, CSS и JavaScript, а также фреймворки и библиотеки, такие как React, Vue.js и Angular. Фронтенд отвечает за отображение данных, обработку событий и обеспечение интерактивности.

Бэкенд: Это серверная часть веб-приложения, которая управляет бизнес-логикой, обработкой данных и взаимодействием с базой данных. Бэкенд может быть написан на разных языках программирования, таких как C#, Python, Ruby, Java, PHP и других. Он включает веб-серверы, базы данных и API.

HTTP-запросы и ответы
Фронтенд и бэкенд взаимодействуют через HTTP-запросы и ответы. Фронтенд отправляет запросы на сервер (бэкенд), который обрабатывает их и отправляет ответы обратно на фронтенд.

Запрос данных:
- Фронтенд отправляет HTTP GET-запрос на сервер, чтобы получить данные.
- Бэкенд получает запрос, извлекает данные из базы данных и отправляет их обратно в виде JSON-ответа.

// Фронтенд (JavaScript с использованием Fetch API)
fetch('https://api.example.com/data')
  .then(response => response.json())
  .then(data => {
    console.log(data); // Обработка данных на фронтенде
  })
  .catch(error => {
    console.error('Error:', error);
  });

Отправка данных:
- Фронтенд отправляет HTTP POST-запрос на сервер с данными для создания нового ресурса.
- Бэкенд получает запрос, обрабатывает данные и сохраняет их в базе данных, затем отправляет ответ о статусе операции.

// Фронтенд (JavaScript с использованием Fetch API)
fetch('https://api.example.com/data', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ key: 'value' })
})
  .then(response => response.json())
  .then(data => {
    console.log(data); // Обработка ответа на фронтенде
  })
  .catch(error => {
    console.error('Error:', error);
  });

WebSocket
Для взаимодействия в реальном времени между фронтендом и бэкендом используется WebSocket. Он позволяет устанавливать постоянное двустороннее соединение между клиентом и сервером, что полезно для приложений с обновлениями в реальном времени, таких как чаты или онлайн-игры.

// Фронтенд (JavaScript с использованием WebSocket API)
const socket = new WebSocket('ws://example.com/socket');

socket.onopen = () => {
  console.log('WebSocket is open now.');
  socket.send(JSON.stringify({ message: 'Hello Server!' }));
};

socket.onmessage = (event) => {
  console.log('Received:', event.data);
};

socket.onclose = () => {
  console.log('WebSocket is closed now.');
};

RESTful API и GraphQL

RESTful API: Это стиль архитектуры API, который использует стандартные HTTP методы (GET, POST, PUT, DELETE) для взаимодействия с ресурсами. Каждый ресурс идентифицируется уникальным URL, а данные передаются в формате JSON или XML.

GraphQL: Это язык запросов для API, который позволяет клиенту запрашивать именно те данные, которые ему нужны. В отличие от REST, где каждый ресурс имеет свой URL, в GraphQL есть единая точка доступа (endpoint), и запросы могут быть более гибкими и оптимизированными.

👉 @seniorFront

👩‍💻 Работа с датами и временем

Напишите функцию, которая принимает дату в виде строки и определяет, сколько дней прошло с начала года до этой даты. Функция должна учитывать високосные годы и возвращать корректное количество дней для любой заданной даты в формате YYYY-MM-DD.

Пример: Для даты "2024-03-01" функция должна вернуть 61, так как 2024 год является високосным и к 1 марта прошло 61 день.

Решение задачи🔽

function daysSinceYearStart(dateString) {
const date = new Date(dateString);
const startOfYear = new Date(date.getFullYear(), 0, 1);

const msPerDay = 24 * 60 * 60 * 1000;
const diffInMs = date - startOfYear;

return Math.ceil(diffInMs / msPerDay);
}

// Пример использования:
console.log(daysSinceYearStart("2024-03-01"));
// Ожидаемый результат: 61


Original post link: t.me/frontendnoteschannel/4339
Forwarded and filtered by @smartfeed_bot

​Как перестать отвлекаться по мелочам, избавиться от прокрастинации и стать продуктивнее как минимум в 2 раза?

Если ты не можешь долго сконцентрироваться на одной задаче и часто отвлекаешься на что-то другое - то эта статья специально для тебя!

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

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

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

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

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

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

👉 @seniorFront

👩‍💻 Как работает деструктуризация объектов и массивов в JavaScript?

Деструктуризация — это удобный синтаксис в JavaScript, который позволяет извлекать значения из массивов и объектов и присваивать их переменным. Это делает код более лаконичным и удобным, особенно при работе с объектами с множеством свойств.

➡️ Пример:

// Деструктуризация объекта
const user = { name: 'Alice', age: 25 };
const { name, age } = user;
console.log(name); // 'Alice'
console.log(age);  // 25

// Деструктуризация массива
const colors = ['red', 'green', 'blue'];
const [firstColor, secondColor] = colors;
console.log(firstColor);  // 'red'
console.log(secondColor); // 'green'

🗣️ Деструктуризация полезна для удобного доступа к значениям из объектов и массивов, минимизируя дублирование кода и делая его более читаемым.

🖥 Подробнее тут


Original post link: t.me/frontendnoteschannel/4342
Forwarded and filtered by @smartfeed_bot

🛠 Пиши код так, как будто завтра будешь его рефакторить

Часто думаешь: «Главное, чтобы сейчас работало, потом доработаю»? Проблема в том, что «потом» может никогда не наступить.

👉 Совет: пиши код с учётом, что через неделю или месяц придётся к нему вернуться. Разбивай на маленькие функции, выбирай понятные имена, оставляй заметки. Это сэкономит тебе время и нервы, когда всё-таки придётся с ним работать.


Original post link: t.me/frontendnoteschannel/4354
Forwarded and filtered by @smartfeed_bot

Будущее микросервисов: уйдем ли мы к монолитам 2.0

Споры об архитектуре не утихают и, наверное, не утихнут никогда. Некоторые компании, начавшие использовать микросервисы, сегодня переоценивают сложность подхода и возвращаются к монолитам, но уже с использованием более современных инструментов. Другие же, только сейчас внедряют микросервисы в свои проекты.

Автор же этой статьи предлагает не сравнивать их друг с другом, начиная очередной спор, а рассмотреть концепцию монолитов 2.0, узнать, что за ней стоит и почему компании возвращаются к упрощению.

#микросервисы


Original post link: t.me/tproger_web/5185
Forwarded and filtered by @smartfeed_bot

​В чём разница между классической функцией и стрелочной?

Классические функции (объявленные через ключевое слово function) и стрелочные функции (введённые в ES6 через => синтаксис) являются двумя способами объявления функций, но между ними есть несколько важных различий:

Синтаксис

Классическая функция:

function add(a, b) {
  return a + b;
}

Стрелочная функция:

const add = (a, b) => a + b;

Предлагают более краткий синтаксис для написания функций, особенно если функция состоит из одного выражения.

Контекст this
В классических функциях контекст определяется тем, как функция была вызвана. В стрелочных функциях контекст наследуется из окружающего контекста (лексический контекст this), где функция была объявлена.

Пример с классической функцией:

const obj = {
  id: 42,
  counter: function() {
    setTimeout(function() {
      console.log(this.id); // this ссылается на глобальный объект или undefined в строгом режиме, а не на obj
    }, 1000);
  }
};

Пример со стрелочной функцией:

const obj = {
  id: 42,
  counter: function() {
    setTimeout(() => {
      console.log(this.id); // this корректно ссылается на obj, так как стрелочная функция наследует this из окружения
    }, 1000);
  }
};

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

Пример с классической функцией:

function Person(name) 
{
  this.name = name;
}
const person = new Person("Alice");

Попытка использовать стрелочную функцию как конструктор:

const Person = (name) => {
  this.name = name;
};
// const person = new Person("Alice"); // Ошибка: Person не является конструктором

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

👉 @seniorFront

Как работает псевдокласс :has() в CSS

Псевдокласс :has — это мощный инструмент в CSS, который позволяет выбирать элементы, основываясь на их содержимом или дочерних элементах. Другими словами, он даёт возможность стилизовать элементы на основе контекста внутри них, чего раньше невозможно было сделать только средствами CSS.

Как это работает?

element:has(selector) выбирает элемент, который содержит определённого потомка или соответствует указанному селектору.

/* Выбрать карточки, содержащие кнопку */
.card:has(button) {
    border: 2px solid blue;
}

Здесь будут выделены только те .card, внутри которых есть <button>.

Зачем он нужен?

1. Работа с родительскими элементами. Например, стилизовать <div>, если внутри него есть конкретный элемент.

2. Условное форматирование. Например, вы можете выбрать контейнеры, в которых есть определённое состояние, например, отмеченный чекбокс.

/* Стилизовать родительский div, если внутри есть отмеченный чекбокс */
div:has(input[type="checkbox"]:checked) {
    background-color: lightgreen;
}

#простымисловами #css

​Когда пора менять работу?

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

Этот способ, или, скорее, инструмент носит акроним AIGCC.

Чтобы его запомнить, можно использовать следующую мнемонику:

Am I Growing Complacent Currently? (дословный перевод: «Становлюсь ли Я самодовольным?», смысловой перевод: «Скатился ли я в зону комфорта?»)

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

Accomplishment (достижение): описывает собственные достижения, которыми Вы гордитесь или о которых не стыдно рассказать

Impact (влияние): описывает отношение или, скорее даже, важность той работы, что была совершена; насколько она ценна

Growth / Future alignment (соответствие с собственными целями): описывает насколько полученный опыт соотносится с собственными карьерными целями и планами

Challenge (вызов): описывает наличие или отсутствие сложных задач, которые продвигают Вас вперёд

Community (сообщество): описывает Ваше отношение к коллегам, к руководству, к ценностям и целям организации

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

На скриншоте ниже, моя собственная карьерная рефлексия с использованием именно этого инструмента

Набор метрик для оценки, перечень вопросов, ответы на которые помогают оценить значение метрики за последний квартал, и, общая оценка за квартал.

Значениями метрик могут быть только «Да» и «Нет». Каждая «да» — это 20% к результату квартала.

Так вот, оценив свой карьерный путь за квартал, мы получим итоговый результат за квартал. Именно, с помощью него и можно ответить на главный вопрос этой статьи — «Когда пора менять работу?». Если результат двух последних кварталов равен 40% и ниже, то это явный сигнал о том, что, возможно, стоит поискать что‑то ещё.

👉 @seniorFront

Порты в веб-разработке: от локальной разработки до продакшена

Эта статья предназначена в первую очередь для веб-разработчиков. Я не являюсь экспертом в области сетей, администрирования или DevOps, поэтому представленный материал не углубляется в сетевые аспекты.

Из любопытства, я как то задался вопросом практического использования разных номеров портов: что они означают для разработчиков, почему используются определенные порты, и какие приложения чаще всего запускаются на них. Цель статьи — пролить немного света на эти “магические” циферки с точки зрения их прикладного применения веб-разработчиками.

👉 @seniorFront


Original post link: t.me/seniorFront/4927
Forwarded and filtered by @smartfeed_bot

Создаем React с нуля

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

Подробности: https://www.rob.directory/blog/react-from-scratch

#react #туториал


Original post link: t.me/tproger_web/5203
Forwarded and filtered by @smartfeed_bot

Полезные ИИ для веб-разработчиков

Вчера в открытом доступе появилась китайская нейросеть DeepSeek, новость о которой обвалила фондовый рынок США Чуть ранее вышло обновление китайской Qwen2.5-Plus, которая якобы ещё мощнее, чем DeepSeek и ChatGPT. Они обе бесплатны и неплохо справляются с написанием кода, это админ проверил лично.

Сейчас же я хочу поделиться с вами исследованием, которое провёл веб-разработчик. В нём он изучил бесплатные инструменты для помощи в веб-разработкеи провёл разбор каждого.

Изучаем и выбираем инструменты для себе по ссылке: https://habr.com/ru/companies/timeweb/articles/873430/

P.S.: так как исследование проводилось до выхода китайских «убийц OpenAI», они в исследование не попали.

#ml #ии


Original post link: t.me/tproger_web/5206
Forwarded and filtered by @smartfeed_bot

Небольшой лайфхак, как избежать ненужных useEffects, когда пишешь на реакте.

#react


Original post link: t.me/tproger_web/5210
Forwarded and filtered by @smartfeed_bot

#вопросы_с_собеседований
Что такое цикл событий (event loop) и как он работает?

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

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

Это, по сути, бесконечный цикл, в котором выполняются многочисленные обработчики событий. Если очередь пустая  — движок браузера ждет, когда поступит событие. Если непустая — первое в ней событие извлекается и его обработчик начинает выполняться. И так до бесконечности.


Original post link: t.me/senior_front/2409
Forwarded and filtered by @smartfeed_bot

Как правильно работать с DOM в JavaScript в 2025 году?

Работа с DOM (Document Object Model) — это основа веб-разработки. С каждым годом появляются новые, более эффективные способы манипуляции элементами страницы. Давайте разберём, как сегодня правильно работать с DOM в JavaScript, чтобы код был быстрым, удобным и безопасным.

1. Получение элементов

Вместо старых getElementById и getElementsByClassName сегодня лучше использовать querySelector и querySelectorAll. Они более универсальные и понятные.

const title = document.querySelector("#title"); // Получает 1 элемент (по id)
const buttons = document.querySelectorAll(".btn"); // Получает список всех кнопок с классом .btn

querySelector и querySelectorAll позволяют находить элементы так же, как в CSS (.класс, #id, input[type="text"] и т. д.). А также querySelectorAll возвращает не «живую» коллекцию, а обычный статичный список (NodeList), что логичнее при итерации.

2. Изменение текста и HTML

Всё зависит от того, что именно нужно поменять.

textContent — если надо изменить только текст (без HTML).

title.textContent = "Привет, мир!";

Не используйте innerHTML, если вставляете данные от пользователя — это дыра в безопасности (XSS-атаки). Если всё же используется innerHTML, убедитесь, что данные проверены.

title.innerHTML = "<strong>Важное сообщение!</strong>";

insertAdjacentHTML — отличная альтернатива innerHTML, если нужно добавить HTML в определённое место, не перезаписывая весь элемент.

title.insertAdjacentHTML("beforeend", "<span> 👋</span>");

3. Изменение классов

Правильный способ через classList, потому что `className`заменяет все классы сразу, из-за чего можно случайно удалить важные стили.

title.classList.add("highlight"); // Добавит класс
title.classList.remove("hidden"); // Удалит класс
title.classList.toggle("active"); // Переключит класс (если был — уберёт, если не было — добавит)

4. Изменение стилей

Не стоит вручную писать style.cssText, потому что он затирает всё, что было до этого. Используйте style для отдельных свойств.

title.style.color = "red";
title.style.fontSize = "24px";

Если нужно много стилей — лучше добавьте или измените класс. Так проще, централизованно и удобнее управлять дизайном.

title.classList.add("error"); // В CSS заранее определите .error { color: red; }

5. Создание и добавление новых элементов

Лучший способ — использовать createElement, а не innerHTML.

const newDiv = document.createElement("div"); // Создаём элемент <div>
newDiv.textContent = "Новый блок!";
newDiv.classList.add("box");  
document.body.appendChild(newDiv); // Добавляем в конец <body>

Если нужно добавлять элементы в разные места:

appendChild() — добавляет в конец родителя.

prepend() — добавляет в начало.

before() и after() — добавляют перед или после элемента.

title.after(newDiv); // Вставит newDiv сразу после title

// С помощью append() можно сразу добавлять текст и несколько элементов
const container = document.querySelector(".container");
container.append("Просто текст", document.createElement("span"));

6. Удаление элементов

Самый актуальный способ — remove().

newDiv.remove(); // Удалит элемент из DOM

Раньше приходилось делать так (и это было неудобно):

newDiv.parentNode.removeChild(newDiv); // Старый подход

7. Обработчики событий (современный подход)

Раньше часто использовали`onclick`, но перезаписывает предыдущие обработчики и плохо управляется. Лучше используйте addEventListener.

const button = document.querySelector("#myButton");

button.addEventListener("click", () => {
  alert("Кнопка нажата!");
});

Мы рассказали только часть советов. Если знаете что-то ещё важное, о чем мы не рассказали тут, поделитесь в комментариях.

#простымисловами #фронтенд

​Как стоит оценивать задачи, чтобы улучшить прогнозирование сроков?

Одной из самых частых проблем, с которыми сталкиваются команды, является неточность планирования сроков выполнения задач.
Разработчик говорит: «Это на пару часов». Проходит день, потом два, и выясняется, что в процессе работы всплыли интеграционные проблемы, тестировщики нашли баги, а кто‑то еще ждет согласования. В итоге задача, которую оценили в несколько часов, затягивается на несколько дней или недель.

Почему так происходит? Потому что абсолютные оценки в часах не работают. Они не учитывают неопределенности, возникающие в процессе работы:

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

Как же тогда планировать и прогнозировать сроки выполнения задач?

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

Как это сделать:
- Фиксируйте, когда задача была взята в работу и когда она реально была завершена (включая тестирование и релиз).
- Отслеживайте не только время разработки, но и задержки, связанные с ожиданием ответов, согласованиями и релизами.
- Разделите задачи по размеру (например, S, M, L, XL) и собирайте статистику по каждому типу.

2. Оценивать задачи не в часах, а в относительных единицах
Когда команда оценивает задачи в часах, это создает иллюзию точности, которая на самом деле приводит к ошибкам. Вместо этого лучше использовать относительные оценки, например:

- Story Points (по ряду Фибоначчи: 1, 2, 3, 5, 8 и так далее).
- Оценку в «футболках» (XS, S, M, L, XL).

Как это работает:
- Находим в бэклоге самую маленькую задачу, принимаем ее за 1 SP (или XS).
- Сравниваем другие задачи с ней и оцениваем их относительно друг друга.
- Планируем спринт и смотрим, сколько SP команда реально завершает за итерацию.
- Через 3–5 спринтов накапливается статистика, на которую можно опираться при планировании.

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

3. Использовать статистику выполнения прошлых спринтов
Если вы работаете по Scrum, можно анализировать, сколько Story Points команда выполняла в прошлых спринтах.

Как это сделать:
- Фиксируйте скорость команды (Velocity) — среднее количество выполненных SP за спринт.
- Учитывайте тенденции — если команда стабильно делает 30 SP за спринт, то планировать на следующий спринт 50 SP бессмысленно.
- Анализируйте вариативность — насколько часто сроки отклонялись от запланированных, какие были причины.

Когда у вас есть такие данные, можно с высокой точностью прогнозировать, что реально успеет сделать команда в следующем спринте.

👉 @seniorFront

Позиционирование элементов с помощью JS

Для позиционирования элементов на странице веб-сайта можно использовать CSS свойства, такие как position, top, left, right, bottom. Однако, в некоторых ситуациях может потребоваться изменять эти свойства динамически с помощью JavaScript.

Для изменения кастомных CSS свойств с помощью JavaScript можно использовать метод setProperty() объекта style. Для этого необходимо указать имя свойства и его значение.

Использование setProperty() позволяет создавать анимации и другие эффекты на странице, которые изменяют CSS свойства элементов динамически.


Original post link: t.me/senior_front/2426
Forwarded and filtered by @smartfeed_bot

​Как использовать японские подходы в IT. Часть 1: петля за петлей

В этом цикле статей мы поговорим о том, как устроены процессы «у них», почему они не всегда работают «у нас» и как их адаптировать для IT. Здесь не будет много душных цитат и ссылок на книги типа «Дао Toyota». Только кристаллизованный личный опыт: ошибки, наблюдения и выводы одного русского парня.

Разберись в корне проблемы (root cause, 5 why)
Как бы сделали на производстве раньше: связали нить и стали ткать дальше, будто ничего не было. Этот процесс уже стал привычным, порождая проблемы с возвратом. Проблема привела к простой мысли: если нить рвется, то станок надо остановить и сделать так, чтобы она не рвалась.

Если что-то идет не так — остановись (дзидока)
Нить — это совокупность волокон, сплетенных между собой. Мы можем не заметить, если одно из волокон надорвется, но нить станет более хрупкой. Что говорить о том, когда рвется сама нить.

Дзидока (jidoka) — принцип «целой нити», когда, например, процесс создания ткани продолжается до тех пор, пока все подпроцессы функционируют корректно. Если что-то идет не так — работа останавливается. Наша задача — сделать так, чтобы производство не останавливалось (только если мы этого не хотим) в целом, как целая нить.

Но как сделать, чтобы нить не рвалась? Усовершенствовать станок!

Постоянно совершенствуй (kaizen)
Тоёда-сан шел по циклу Деминга:
- Замечал проблему.
- Придумывал решение.
- Записывал, что идет не так.
- Менял это.
Однако он не мог знать этого, так как до разработки цикла оставались еще десятки лет. Годы жизни Сакити Тоёда — 1867–1930 годы.

Обменивайся опытом и учи (nemawashi)
Тоёда-сан пытался запустить производственный процесс, путешествовал по миру, учился, но долгое время ощутимых результатов не было. Однако все изменилось позже благодаря двум «воспитанникам» системы — Тайити Оно и Сигэо Синго, которые были в Toyota почти с самого начала.

Оно-сан, путешествуя по США, был поражен устройством работы супермаркетов: все точно находилось на полках тогда, когда это было нужно, и никакой суеты — в отличие от производства Toyota. Помня об идеях Тоёда-сан (Киитиро), он разработал концепцию Just-in-Time (JIT). Если по-простому — все должно быть на своих местах ровно в тот момент, когда это требуется, и только тогда. Если рабочему нужен ключ — он должен быть под рукой. Нужен компонент для монтажа — он тоже должен быть доступен.

Для реализации принципа были построены процессы внутренней доставки по системе Kanban — с использованием карточек-инструкций. Как в супермаркете: у покупателя есть список покупок, он наполняет корзину и доставляет ее куда нужно. Profit!

Точно вовремя (JIT)
Синго-сан, сотрудничая с Оно-сан, углубился еще дальше и заметил, что помимо нехватки материалов производство теряет время из-за дефектов оборудования и ошибок сотрудников. Можно ли устранить дефекты с минимальными временными затратами? Можно, если ремонтировать оборудование во время работы и знать, когда оно сломалось. Это называется быстрой переналадкой или Single-Minute Exchange of Dies (SMED).

Для этого станки упростили до выполнения одной-двух операций. Это позволило сделать их проще, более ремонтопригодными и заменяемыми. Кроме того, рядом с рабочими станциями стали размещать наборы компонентов для ремонта.

Узнавай о проблеме и не давай делать ошибки (andon и poka-yoke)
После наладки механической части производства Синго-сан и Оно-сан поняли, что нужно обучать персонал. Но как объяснить процесс неподготовленному рабочему? Очень просто — с помощью Kanban-доски. Как и карточки на производстве, Kanban-доска наглядно показывает, из чего состоит процесс и какие операции нужно выполнить. Это упростило контроль и сделало обучение сотрудников более быстрым.

Показывай наглядно (Kanban)
Как видите, история сделала круг и система Kanban стала применяться повсеместно. Сегодня ее «заимствуют» все, делая вид, что в этом есть что-то сложное. Смешной факт: на нескольких собеседованиях интервьюеры утверждали, что я не знаю, как работать с Kanban. Наивные!

👉 @seniorFront

​Scrum-то какой! За что критикуют спринты

На первый взгляд, гибкая разработка и сопутствующие методологии уже лет двадцать как стали новой нормой. Но если копнуть поглубже, немало инженеров и сегодня считают, что появление в компании консультантов по Scrum — повод срочно обновить резюме. Разбираемся, за что не любят спринты, кто виноват и можно ли с этим что-то сделать.

Четыре причины недовольства

1 — Гонка за показателями. Классический спринт дробит процесс разработки на двухнедельные промежутки, в течение которых команда постепенно движется к цели. В теории тикеты в пределах одного спринта должны закрываться равномерно, но на практике бывает иначе. Некоторые разработчики отмечают, что в конце спринта часто начинается кранч — гонка за выполнением задач. Чтобы уложиться в сроки, команда помечает тикеты как завершенные, даже если осталось доделать еще 5% работы, а все недоделки перетекают в новые задачи. Еще хуже, когда команда применяет хаки и костыли, чтобы уложиться в срок, жертвуя качеством.

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

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

4 — Субъективная оценка производительности. Один из краеугольных камней, который появляется в каждом первом материале с критикой Scrum — сложности в оценке того, какой объем работы команда может реализовать за спринт. Вне зависимости от того, происходит оценка в человекочасах или стори пойнтах, точно спланировать объем работы, который не будет ни чрезмерным, ни недостаточным, крайне затруднительно.

И российские, и зарубежные специалисты при этом сходятся в одном: во-первых, оценить среднюю скорость/мощность/производительность команды (сколько стори поинтов команда может выполнить за спринт) можно только постфактум, по результатам двух или более спринтов, но никак не за «один пристрелочный подход». А во-вторых, даже эти оценки будут очень приблизительными, потому что команда не существует в вакууме: сотрудники уходят в отпуск и на больничный, у них рождаются дети, они увольняются, они, в конце концов, могут столкнуться с выгоранием или разочарованием в работе — все это влияет и на состав команды, и на ее скорость. А излишне оптимистичные оценки — это новый источник стресса, и привет, причина для недовольства номер 1 (кранч и гонка за показателями).

👉 @seniorFront