Русский
Русский
English
Статистика
Реклама

Coding

Перевод Улучшаем производительность Java-микросервиса парой простых приемов

10.03.2021 18:12:48 | Автор: admin

Привет, Хабр. Для будущих студентов курса "Highload Architect" подготовили перевод материала.

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


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

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

Spring Boot это быстрый способ создания микросервисов на Java. В этой статье мы рассмотрим, как улучшить производительность Spring Boot-микросервиса.

Что будем использовать

Мы будем использовать два микросервиса:

  • External-service (внешний сервис): "реальный" микросервис, доступный по HTTP.

  • Facade-service (фасад): микросервис, который будет читать данные из external-service и отправлять результат клиентам. Будем оптимизировать этот сервис.

Что нам нужно

  • Java 8

  • Jmeter 5.3

  • Java IDE

  • Gradle 6.6.1

Исходный код

Прежде всего, скачайте исходный код, который мы будем улучшать, отсюда.

External service

Сервис был создан с помощью Spring Initializer. В нем один контроллер, имитирующий нагрузку:

@RestController public class ExternalController {   @GetMapping(/external-data/{time})  public ExternalData getData(@PathVariable Long time){  try {  Thread.sleep(time);  } catch (InterruptedException e) {  // do nothing  }  return new ExternalData(time);  } }

Запустите ExternalServiceApplication. Сервис должен быть доступен по адресу https://localhost:8543/external-data/300 .

Facade service

Этот сервис также был создан с помощью Spring Initializer. В нем два основных класса: ExternalService и ExternalServiceClient.

Класс ExternalService читает данные из сервиса External Service с помощью externalServiceClient и вычисляет сумму.

@Service public class ExternalService {   @Autowired  private ExternalServiceClient externalServiceClient;   public ResultData load(List<Long> times) {  Long start = System.currentTimeMillis();  LongSummaryStatistics statistics = times  .parallelStream()  .map(time -> externalServiceClient.load(time).getTime())  .collect(Collectors.summarizingLong(Long::longValue));  Long end = System.currentTimeMillis();  return new ResultData(statistics, (end  start));  } }

Для чтения данных из external service класс ExternalServiceClient использует библиотеку openfeign. Реализация HTTP-клиента на основе OKHttp выглядит следующим образом:

@FeignClient( name = external-service, url = ${external-service.url}, configuration = ServiceConfiguration.class) public interface ExternalServiceClient {   @RequestMapping(  method = RequestMethod.GET,  value = /external- data/{time},  consumes = application/json)  Data load(@PathVariable(time) Long time); }

Запустите класс FacadeServiceApplication и перейдите на http://localhost:8080/data/1,500,920,20000.

Ответ будет следующим:

{  statistics: {  count: 4,  sum: 1621,  min: 1,  max: 920,  average: 405.25  },  spentTime: 1183 }

Подготовка к тестированию производительности

Запустите Jmeter 5.3.1 и откройте файл perfomance-testing.jmx в корне проекта.

Конфигурация теста:

Нагрузочный тест будем проводить по следующему URL-адресу: http://localhost:8080/data/1,500,920,200

Перейдите в Jmeter и запустите тест.

Первый запуск Jmeter

Сервер стал недоступен. Это связано с тем, что в ExternalService мы использовали parallelStream(). Stream API для параллельной обработки данных использует ForkJoinPool. А по умолчанию параллелизм ForkJoinPool рассчитывается на основе количества доступных процессоров. В моем случае их три. Для операций ввода-вывода это узкое место. Итак, давайте увеличим параллелизм ForkJoinPool до 1000.

-Djava.util.concurrent.ForkJoinPool.common.parallelism=1000

И запустим Jmeter еще раз.

Второй запуск Jmeter

Как вы видите, пропускная способность (throughput) увеличилась с 6 до 26 запросов в секунду. Это хороший результат. Кроме того, сервис работает стабильно без ошибок. Но тем не менее среднее время (average time) составляет 9 секунд. У меня есть предположение, что это связано с затратами на создание HTTP-соединение. Давайте добавим пул соединений:

@Configuration public class ServiceConfiguration {      @Bean  public OkHttpClient client()  throws IOException, CertificateException, NoSuchAlgorithmException, KeyStoreException, KeyManagementException, NoSuchProviderException {     okhttp3.OkHttpClient client = new okhttp3.OkHttpClient.Builder()  .sslSocketFactory(sslContext.getSocketFactory(), trustManager)  .hostnameVerifier((s, sslSession) -> true)  .connectionPool(new ConnectionPool(2000, 10, TimeUnit.SECONDS))  .build();   OkHttpClient okHttpClient = new OkHttpClient(client);   return okHttpClient;  }

Таким образом, приложение может поддерживать до 2000 HTTP-соединений в пуле в течение 10 секунд.

Третий запуск Jmeter

Пропускная способность улучшилась почти в три раза: с 26 до 71 запросов в секунду.

В целом пропускная способность улучшилась в 10 раз: с 6 до 71 запросов / сек, но мы видим, что максимальное время запроса (maximum time) составляет 7 секунд. Это много и влияет как на общую производительность, так и на задержку в UI.

Поэтому давайте ограничим количество обрабатываемых запросов. Сделать это можно, используя указанные ниже свойства Tomcat в application.properties:

server.tomcat.accept-count=80server.tomcat.max-connections=80 server.tomcat.max-threads=160

Приложение будет отклонять запросы на подключение и отвечать ошибкой "Connection refused" (отказ соединения) всем клиентам, как только количество подключений достигнет 160.

Четвертый запуск Jmeter

Теперь максимальное время составляет меньше пяти секунд и число запросов увеличилось с 71 до 94 запросов в секунду. Процент ошибок ожидаемо увеличился до 29%. Это все ошибки "Connection refused".

Заключение

В этой статье мы продемонстрировали реальный сценарий повышения производительности в 15 раз с 6 до 94 запросов / сек без каких-либо сложных изменений кода. Кроме того, упомянутые выше шаги позволяют снизить стоимость инфраструктуры, такой как AWS. Возможно, для вашего следующего проекта вам стоит подумать об использовании микросервисов. Хотя одна из тенденций последних лет переход к бессерверной архитектуре, но вы должны всё взвесить при переходе к такой архитектуре.

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


Узнать подробнее о курсе "Highload Architect".

Смотреть открытый вебинар по теме Репликация как паттерн горизонтального масштабирования хранилищ.

Подробнее..

Перевод Ускоряем код на Python с помощью Nim

20.02.2021 12:17:51 | Автор: admin

Привет, хабровчане. В преддверии старта курса "Python Developer. Basic" подготовили для вас перевод интересной статьи. Также приглашаем на открытый вебинар Карьера для "Python Developer. Basic".


Python один из самых популярных и доступных языков программирования, но далеко не самый быстрый. Многие создатели библиотек и фреймворков прибегали к использованию расширения на С, чтобы их код работал быстрее, чем код на нативном Python.Этот способ вполне рабочий, но если вы не знакомы с С, сборка мусора и управление памятью станут вашим адом на Земле. И тут на сцену выходит Nim.

Что такое Nim?

Nim статически типизированный, компилируемый, объектно-ориентированный язык программирования. Nim создавался, чтобы быть таким же быстрым как С и таким же выразительным как Python, и к тому же, расширяемым как Lisp. Благодаря синтаксическому сходству с Python, Nim станет отличным выбором языка для расширения, если с C вам не по пути.

Начало работы с Nim

Чтобы начать писать на Nim, его нужно установить в свою систему. Скачайте и установите его с сайта nim-lang.org.

Как только вы закончите, мы начнем писать свой первый код на Nim. Во-первых, мы создаем файл, я назову его hello.nim, а вы можете назвать его как захотите. Теперь мы откроем его в любом текстовом редакторе и напишем:

static:    echo("Hello, world!")

Сохраните и закройте файл, затем откройте терминал из текущей директории и введите:

nim compile hello.nim

И вуаля! В консоль выведется Hello, World!. После получения первого представления о Nim перейдем к основной теме статьи.

Встраиваем Nim в приложения на Python

Nim поставляется с модулем nimpy и nimporter, которые доступны для Python.Последний можно установить с помощью pip install nimporter. Эти два пакета будут иметь важное значение при совместной работе двух языков.

Чтобы продемонстрировать возможности Nim, мы создадим простой тест, который будет сравнивать скорость работы обоих языков, на примере функции находящей n-ое число последовательности Фибоначчи.

Давайте создадим папку под названием Benchmark с 3 файлами внутри:

  • main.py файл, который мы будем запускать

  • nmath.nim файл с версией функции fib на Nim

  • pmath.py файл с версией функции fib на Python

Сначала напишем функцию fib на Python:

def fib(n):    if n == 0:        return 0    elif n < 3:        return 1    return fib(n - 1) + fib(n - 2)

А теперь переместимся в nmath.nim. Для начала нам нужно импортировать nimpy:

import nimpy

Прямо как в Python, не так ли? А теперь сама функция:

import nimpyproc fib(n: int): int {.exportpy.} =    if n == 0:        return 0    elif n < 3:        return 1    return fib(n-1) + fib(n-2)

Давайте разберемся

Мы определяем функцию fib с помощью ключевого слова proc. Дальше указываем тип возвращаемого значения как целочисленный, а (вау, что это такое?) {.exportpy.} сигнализирует Nim, что эта функция предназначена для использования в другом модуле Python. В остальном все также, как в Python.

Тестирование на время

В main.py создадим простой бенчмарк:

import nimporterfrom time import perf_counterimport nmath  # Nim imports!import pmathprint('Measuring Python...')start_py = perf_counter()for i in range(0, 40):    print(pmath.fib(i))end_py = perf_counter()print('Measuring Nim...')start_nim = perf_counter()for i in range(0, 40):    print(nmath.fib(i))end_nim = perf_counter()print('---------')print('Python Elapsed: {:.2f}'.format(end_py - start_py))print('Nim Elapsed: {:.2f}'.format(end_nim - start_nim))

Вот и все!

Пакет importer позволяет импортировать Nim в обычные модули Python, которые будут использоваться также, как и собственные. Круто, не правда ли?

Чтобы запустить код, просто введите python main.py в командную строку и смотрите, что будет!

Python Elapsed: 33.60Nim Elapsed: 1.05

Заключение

Вот и все, что нужно сделать, чтобы быстро встроить Nim в Python. Nim оказался примерно в 30 раз быстрее, но имейте ввиду, что разница в скорости может варьироваться в зависимости от выполняемой задачи. Чтобы узнать больше о Nim, рекомендую ознакомиться с официальной документацией и почитать про него в Википедии.

Что ж, на этом я закончу свой туториал! Спасибо, что дотерпели до конца. Надеюсь, эта статья окажется для вас полезной.


Узнать подробнее о курсе "Python Developer. Basic".

Смотреть запись открытого demo-урока Три кита: map(), filter() и zip().

Подробнее..

Как быть тимлидом и продолжать программировать

19.11.2020 20:15:16 | Автор: admin

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


Хочу сказать отдельное спасибо Алисе Мироненко за подготовку транскрипта. Видео версия доклада:

Небольшой дисклеймер: то, что я буду говорить, можетдля вас не работать. Ваша ситуация может быть совсем другой.Если честно, не люблю, когда идет менеджерский доклад и говорят: Вот это точновам подойдет.Ноянадеюсь, будетполезнотем,чей кейссоответствуеттому, о чём я буду говорить.

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

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

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

Потом человек с таким опытом приходит к нам на позицию разработчика.

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

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

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

Но расстояние между лидоми менеджером такое же, как междуджуномилидом.

У наснет времени учиться на менеджеров это главнаяпроблема.

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

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

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

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

Если мы решилиуглубиться в разработку, у нас должна быть инженерная нагрузка, хотя бы 30%. Возникает вопрос: А разве эти 30%насспасут? Да, об этом сегодня и поговорим как добиться этих 30% эффективной работы, чтобы мы продолжали развиваться как настоящие инженеры.


Давайте начнем с того,когда тимлиду стоит заниматься разработкой. Я сделал небольшойчеклист.

Возможно, у вас есть время на разработку, если:

  1. Вы занимаетесьмикроменеджментом.

  2. Пишете много документации в стол.

  3. Вы единая точка коммуникациина проекте.

  4. Ваша команда только пишет код.

  5. У вас много тет-а-тет митингов.

  6. Вы инициатор большинстваэтих митингов.

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

В целом ясчитаю, что совмещениеролейуправленцаи инженера зависит от трех вещей:

1) Стадии развития вашей команды

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

Потом, когда люди поняли, кто есть кто, они начинают притираться друг к другу и наступает длительный этап норминга, на котором производительность медленно растет, доходит до пика на этапе перформинга и потихоньку падает.

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

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

2) Уровня квалификации и мотивации ваших сотрудников

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

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

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

Есть классическая табличка на эту тему:

Единственный возможный вариант освободить себе время на разработку делегировать задачи достаточно мотивированной и квалифицированной команде.

3) Уровня коммуникации на проекте

Возможноститратитьвремени на разработку не будет, если есть проблемы в коммуникации на проекте.

Например,mushroommanagement(управление по принципу меньшезнаешь крепче спишь), когда вы являетесь единой точкой коммуникации и никто больше не знает, что происходит.

Очевидно, что в таком случае у вас не будет времени на инженерную деятельность.

Как настроить коммуникацию?

Вариант:если я единая точка коммуникации,я возьму и самоустранюсь.

Главная проблема будет в том, что появится неформальный лидер. Понятие неформальный лидер неприятное, потому чточасто неформальные и формальные лидеры не одно лицо. Это становится проблемой для формального лидера.

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

Как перестать быть единой точкой коммуникации?

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

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

  • Познакомьте заказчика с командой через task manager.

  • Организуйте встречу с командой в привычном для заказчика месте и времени. Не приводите сразу всех.

  • Ведите первые митинги как обычно, тет-а-тет с заказчиком, но с командой на фоне.

  • Передавайте часть инициативы коллегам, например: Вот Евгений знает эту систему лучше всех, пусть расскажет.

  • Поднимайте на встречах вопросы, которые можно адресовать команде. Пусть на них отвечают, не ожидая вас.

  • Позвольте вашим коллегам вести митинги и переписки напрямую с заказчиком, но в первое время будьте рядом.

  • Всегда будьте в копии и на связи с заказчиком.

  • Это было про коммуникацию, теперь прото,как делегировать.

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

Делегирование это отдельная тема, сейчас я остановлюсь только на нескольких моментах.

Не забывать, чтоваши функции не очевидны другим.

Давать задачи тем сотрудникам, которые способны с ними справиться.Если есть задача вести коммуникацию с кучей разных людей из разных стран, вряд ли стоит давать ее скромному интроверту с уровнем английского А1.

Делегирование должно развивать сотрудников.Помните, что чем больше вы делегируете человеку, тем лучше он справляется со своими полномочиями. Поэтому, если первый раз произошло полное фиаско и человекне справился с функциями, которые выделегировали, лучше дать ему возможность еще раз попробовать эту задачу, возможно, он чему-то научился. Как это понять? Важная часть делегирования контроль. Еженедельный контроль, ежедневные митинги и прочее.

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

Мы поняли, когда можно браться за разработку: команда не находится на этапешторминга,мы умеем делегировать.

Давайтетеперь подумаем,как бороться с отвлечением и управлять вниманием

В чем проблема борьбы с отвлечением для тимлидов? В том, что классические подходы к тайм-менеджменту focus time, помидорка, скалирование времени и другие не работают, если сотрудники не уважают ваше время.

Но что делать с вопросами коллег? Важно отвечать на них хотя бы в течение получаса.

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

Для тимлидов отметим важный момент: пишем через 15 минут правильно.

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

Рассмотрим еще одну проблему возврат в контекст.

Вы программируете, у вас в голове: Задача-метод-класс. Вас отвлекли, контекст пропал. Выответили сотруднику, нужно вернуться в контекст.

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

Мультитаскинг большая проблема тимлида, и здесь могут помочьвиртуальные рабочие столы.

На виртуальном рабочем столе программирования у вас может быть открытIDE, браузер, требования.

На виртуальном столе, где у вас релиз в продакшен, Jenkins/TeamCity, Splunk/Kibana, чат с DevOps. То же самое с обсуждением требований: Skype/Teams, Jira, Confluence.

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

Пора программировать

Мы настроили время, коммуникацию, справились с отвлекающими факторами, налили чаёк Имы парализованы.

У насантипаттерн аналитики-паралитики.

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

Как вы думаете, о чём будет думать архитектор нефтекомплекса, когда ему надо чинить трубу? Пройдет ли этот биметаллэконормы? А как на давление повлияет всжигателе? В данном случае архитектор просто не сможет починить эту трубу, потому что не справится с такой когнитивной нагрузкой.

У нас то же самое. Разработка ПО это комплексная задача. Бизнес-контекст, архитектура, коди прочее. От нас как от тимлидов требуют думать глобально.

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

Напоследок хотелось бы поговорить про выбор программерскойроли, когда вы тимлид

Давайте рассмотрим основные роли:

Ключевой разработчик, который делает основную бизнес-логику, разрабатывает ядро продукта.

Если вашабольшая команда,времени на это может не быть. Стоит вовремя отдать эту роль, когда команда растет, иначе вы можете превратиться впрототипщика(человек, который пилитпрототипы,а доведение проекта до ума оставляет на откуп команде).

Затыкательдыр человек, который приходит, когда нам чего-то не хватает для полного счастья.

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

Еще одни руки еще один программист,которыйпросто еще что-то делает фикситбаги, например.

Этот подход работает, потому что тимлид с такой ролью хорошо знает систему. Тут важно не статькодерскимбалластом.

И мое любимое кодерскийбалласт. Человек, которого лучше бы не было.

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

Резюмируя: как быть тимлидом и продолжать программировать.

Когда?

  • Когда команда на стадиинормингаилиперформинга.

  • Когда люди квалифицированы и мотивированы.Когда настроена коммуникация.

Как?

  • Прямая коммуникация.

  • Делегирование.

Рекомендации

  • Управлять отвлекающими факторами.

  • Микродекомпозироватьзадачи.

  • Облегчить переключение фокуса внимания.

  • Трезво выбирать роль.

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru