Таких проблем не должно быть, если Тимлид синхронизирован с командой, понимает ее темп и возможности. Опытный Тимлид имеет хороший уровень экспертизы и погружение в контекст команды разработки – это позволяет дать наиболее адекватную оценку по срокам
Мне кажется, что тут слово синхронизирован взято в абсолют. Предположу, что в Тинькофф есть тим лиды, которые не спускаются в кодовую базу, так как попросту не хватает времени. Не знаю, какое соотношение в компании тим лидов, которые кодят, и которые проводят/не проводят ревью кода. Вторых может быть даже больше, судя по описанию обязанностей. Если тим лид не пишет код, то он вряд ли может предположить, как будет решаться та или иная задача
Давайте на примере. Допустим тим лид оценил эпик/задачу на 100ч/попугаев, учитывая прошлый опыт. Затем разработчик осознаёт, что задачу надо будет решить, используя кеш или БД или облако, что приведёт к увеличению трудозатрат вдвоё (или даже больше). Или даже упростим пример. Разработчик в ходе работы над задачей понял, что потребуется провести ADR (перепроектировать/расширить архитектуру). Хочется тут понять 2 вещи:
Это всё заранее прорабатывает тим лид, чтобы оценить примерные трудозатраты? А разработчики в компании максимум решают, какой паттерн использовать
Если тим лид этого не делает и даёт лишь высокоуровневую оценку, то как часто бывают случаи, когда в задаче стоит n часов/попугаев, а в результате получается сделать за >= 2*n часов/попугаев?
Если на второй вопрос ответ не часто, то, по-видимому, тим лиды дают оценку с запасом х3-х4, а то и более от реальных трудозатрат разработчика
Правда: в работе такое действительно встречается и приходится называть сроки на очень ранних этапах разработки. Всегда можно взять время на анализ задачи, но тимлиду необходимо понимать и транслировать бизнесу риски на ранних этапах разработки проекта в условиях неопределенности.
А не бывает потом проблем с тем, что команда говорит: "сроки спустили сверху, а нам за них отвечать?" или "сам назвал сроки, сам в них и влезай"
Не думали ставить отдельные встречи с командой для оценки трудозатрат по предстоящим задачам? Как относитесь к такому подходу?
Проводятся ли в компании архитектурные ревью? Если есть, то кто их проводит
Хочется поблагодарить за серию прекрасных статей автора, а также вас за не менее прекрасный перевод
На мой взгляд, данная статья не до конца раскрыла тему хранения данных:
Автор не расписал толком, как использовать tmpfs (временное хранилищие). Хотя эта одна из основных тем в заголовке статьи
Можно получить чуть больше информации о том, как я могу, например, проверить, что том создан? Будет это симлинк или физический том
Как я могу создать том в отличной от структуры данных контейнера директории через Dockerfile? Что-то вроде такого from=/som/src/path to=/other/path/in/local/storage
Знаю, есть гугал, но хотелось бы увидеть хотя бы комментарии от переводчиков статьи. Заранее спасибо, кто ответит на вопросы выше ☝?
Есть возможность в долгих циклах вызывать метод ниже.
public static void isInterrupted() throws CancellationException {
if (Thread.currentThread().isInterrupted()) {
throw new CancellationException("Можно указать какой тред, например");
}
}
// пример использования
public static void main() {
while(true) {
isInterrupted();
// какой-то код
}
for (int i = 0; i < 100_000; i++) {
if (i % 100 == 0) {
isInterrupted();
}
}
}
И так далее… Можно просто размазать по коду в любых местах
Для начала хотелось бы поблагодарить за проделанную работу.
При расчете медианы зарплат, как учитывались вакансии, в которых не указаны значения.
Допустим берем 1000 вакансий, в 300 из них "Н/Д".
Avg = (Sum / 1000) или (Sum / 700)?
В связи с этим следующий вопрос. Это число "1000" одинаково для всех языков?
Например, взяли 1000 вакансий Java и 1000 вакансий JS, в итоговый подсчет вошло 700 и 900 соответственно.
Java: Avg = (Sum / 700) и JS: Avg = (Sum / 900)
или
Java: Avg = (Sum / 700) и JS: Avg = (Sum / 700)?
Хочу заметить, что GIST индекс один из самых трудных в освоении и использовании, поскольку имеет большой функционал. В своём проекте при полнотекстовом поиске использовал именно GIN индекс, так как работает он куда быстрее, чем GIST, хотя занимает больше места. Возможно Вы раскроете плюсы и минусы этих индексов при таком поиске в следующей статье, поэтому не буду забегать вперёд.
Моё мнение, что какими-то базовыми знаниями качественный тестировщик должен обладать. Иногда разработчик может не заметить банальной ошибки(например, сравнение строк через "==" или неправильное наименование поля "adress" вместо "address"). И чтобы не переоткрывать задачу, можно самостоятельно пофиксить.
В нашей компании компании, к сожалению, придерживаются политики, что только разработчик должен тестить своё творение
До России практика внедрения DevOps начала доходить около 5 лет назад...
и до сих пор не дошла.
За статью спасибо! Перешёл по ссылке из статьи. Правильно понимаю, что вы обучаете основам DevOps даже людей с нулевыми знаниями разработки, т.е. требований к обучающимся нет?
Я бы больше акцентировал внимание на курсах JavaRush, так как данная статья нацелена именно на новичка. Неплохо бы ещё добавить разновидности в некоторые пункты: а) IDE, ё) фреймворки для изучения.
Мне кажется, что тут слово синхронизирован взято в абсолют. Предположу, что в Тинькофф есть тим лиды, которые не спускаются в кодовую базу, так как попросту не хватает времени. Не знаю, какое соотношение в компании тим лидов, которые кодят, и которые проводят/не проводят ревью кода. Вторых может быть даже больше, судя по описанию обязанностей. Если тим лид не пишет код, то он вряд ли может предположить, как будет решаться та или иная задача
Давайте на примере. Допустим тим лид оценил эпик/задачу на 100ч/попугаев, учитывая прошлый опыт. Затем разработчик осознаёт, что задачу надо будет решить, используя кеш или БД или облако, что приведёт к увеличению трудозатрат вдвоё (или даже больше). Или даже упростим пример. Разработчик в ходе работы над задачей понял, что потребуется провести ADR (перепроектировать/расширить архитектуру). Хочется тут понять 2 вещи:
Это всё заранее прорабатывает тим лид, чтобы оценить примерные трудозатраты? А разработчики в компании максимум решают, какой паттерн использовать
Если тим лид этого не делает и даёт лишь высокоуровневую оценку, то как часто бывают случаи, когда в задаче стоит n часов/попугаев, а в результате получается сделать за >= 2*n часов/попугаев?
Если на второй вопрос ответ не часто, то, по-видимому, тим лиды дают оценку с запасом х3-х4, а то и более от реальных трудозатрат разработчика
Статья интересная, спасибо!
У меня есть вопросы по этому подходу:
А не бывает потом проблем с тем, что команда говорит: "сроки спустили сверху, а нам за них отвечать?" или "сам назвал сроки, сам в них и влезай"
Не думали ставить отдельные встречи с командой для оценки трудозатрат по предстоящим задачам? Как относитесь к такому подходу?
Проводятся ли в компании архитектурные ревью? Если есть, то кто их проводит
Хочется поблагодарить за серию прекрасных статей автора, а также вас за не менее прекрасный перевод
На мой взгляд, данная статья не до конца раскрыла тему хранения данных:
Автор не расписал толком, как использовать tmpfs (временное хранилищие). Хотя эта одна из основных тем в заголовке статьи
Можно получить чуть больше информации о том, как я могу, например, проверить, что том создан? Будет это симлинк или физический том
Как я могу создать том в отличной от структуры данных контейнера директории через Dockerfile? Что-то вроде такого from=/som/src/path to=/other/path/in/local/storage
Знаю, есть гугал, но хотелось бы увидеть хотя бы комментарии от переводчиков статьи. Заранее спасибо, кто ответит на вопросы выше ☝?
Для тех, кто хочет почитать продолжение Часть 2
Есть возможность в долгих циклах вызывать метод ниже.
И так далее… Можно просто размазать по коду в любых местах
Для начала хотелось бы поблагодарить за проделанную работу.
При расчете медианы зарплат, как учитывались вакансии, в которых не указаны значения.
Допустим берем 1000 вакансий, в 300 из них "Н/Д".
Avg = (Sum / 1000) или (Sum / 700)?
В связи с этим следующий вопрос. Это число "1000" одинаково для всех языков?
Например, взяли 1000 вакансий Java и 1000 вакансий JS, в итоговый подсчет вошло 700 и 900 соответственно.
Java: Avg = (Sum / 700) и JS: Avg = (Sum / 900)
или
Java: Avg = (Sum / 700) и JS: Avg = (Sum / 700)?
эт божественно
В номинации "Лучшие вопросы" я бы выделил 3 и 4. Уж больно интересные и полезные
За статью спасибо!
Есть ещё какие-то способы попасть на конференцию?
Как же долго я ждал продолжения) Спасибо!
Хочу заметить, что GIST индекс один из самых трудных в освоении и использовании, поскольку имеет большой функционал. В своём проекте при полнотекстовом поиске использовал именно GIN индекс, так как работает он куда быстрее, чем GIST, хотя занимает больше места. Возможно Вы раскроете плюсы и минусы этих индексов при таком поиске в следующей статье, поэтому не буду забегать вперёд.
ЖДУ ПРОДОЛЖЕНИЯ
Очень интересно и познавательно! Спасибо
Моё мнение, что какими-то базовыми знаниями качественный тестировщик должен обладать. Иногда разработчик может не заметить банальной ошибки(например, сравнение строк через "==" или неправильное наименование поля "adress" вместо "address"). И чтобы не переоткрывать задачу, можно самостоятельно пофиксить.
В нашей компании компании, к сожалению, придерживаются политики, что только разработчик должен тестить своё творение
и до сих пор не дошла.
За статью спасибо! Перешёл по ссылке из статьи. Правильно понимаю, что вы обучаете основам DevOps даже людей с нулевыми знаниями разработки, т.е. требований к обучающимся нет?