Рубрика: Разработчикам

Наконец то: Гвидо ван Россум намерен достигнуть двукратного увеличения производительности в CPython 3.11

Наработки проекта публикуются в отдельном репозитории faster-cpython. Один из участников проекта, ранее занимавшийся разработкой JIT-компилятора HotPy для CPython, опубликовал план, в соответствии с которым считает реалистичным поднять производительность в пять раз и добиться этого результата в выпуске Python 3.13.

Читать дальше

Технический долг на проекте

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

Читать дальше

как мы решали проблему постоянных исправлений

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

Читать дальше

Скрытые расходы при переходе на микросервисы

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

Мастер-данные
Написание кода по-новому
Проектирование IT-продукта заново
Создание новой инфраструктуры
Измерение и проверка SLA
Вклад в fault tolerance на всех уровнях
Реорганизация команд
Работы по обратной совместимости
Интеграция служб поддержки
Догоняющий поток фич

Читать дальше

Waterfall которого никогда не было

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

Таком образом весь Agile это про две цели:
– Идеальный мир для Инженера
– Сокращение затрат на поддержку ИТ-продукта.

Читать дальше

Разрабы работают медленно и дорого — и люди считают нас лентяями. Просто в разработке всё сложно

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

Читать дальше

Больше всего меня раздражает в PHP комьюнити

…это то что усредненный пхпист растет в таком порядке:
1. есть сайт, мне надо что-то добавить, изменить. Или сразу: делаю сайт!
2. лезу в код, изучаю попутно на чем он сделан (задаю вопросы уровня: а это WordPress или Laravel?)
3. изучая на чем он сделан, изучаю попутно ООП (если сайт сделан на современном фреймворке)
4. изучая ООП, изучаю попутно PHP

А надо бы – с точностью до наоборот.

Никто не умеет управлять программистами — и все придумывают костыли, вместо решений

Есть компании, где процесс разработки реально работает отлично. Я скажу вам почему — они выиграли в лотерею. У них оказалось намного больше людей, которые хотят работать — с такими, как не управляй, все будет идти хорошо. Даже манагерскую мишуру с бордами они используют для дела, а их перформанс и по джировым, и по интуитивным метрикам ясно виден. И когда их менеджеры-не-разрабы приходят мешать им, у них за спиной стоит шикарный продукт, который даёт им право посылать эти говорящие головы к черту.

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

Читать дальше

А вы хороший руководитель?

1. Донесение своих мыслей и слов спокойно.
2. Прозрачное и понятное донесение своих мыслей.
3. Умение давать людям делать свою работу.
4. Умение слушать своих людей.
5. Умение управлять не жестко, а компетентно.
7. Принятие ответственности за результат работы команды.
8. Умение принимать решения и нести за них ответственность.
9. Понимание, что его задача нужна прежде всего ему, а не его подчиненным.

Читать дальше

Что делать, если в вашей команде появился «эффективный» менеджер?

ряд психологических лайфхаков, которые могут помочь сохранить нервы при работе с “эффективным” менеджером:

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

Читать дальше