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

Почему нельзя выбирать между проектным и процессным управлением

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

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

Работать надо не головой, а компьютером

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

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

Наконец то: Гвидо ван Россум намерен достигнуть двукратного увеличения производительности в 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

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