работа программиста

Рассуждаем о вопросах, не связанных с тем, как писать код.

---

Существует ли идеальный код, или новый разработчик всегда хочет всё переписать?

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

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

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

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

Философия: действительно, одну и ту же систему можно запрограммировать множеством разных вариантов. Есть ли способ, позволяющий указать, какой из вариантов приближен к идеалу? Я утверждаю, что из всех вариантов кода для каждой программной системы можно выбрать наилучший — наиболее подходящий, в котором функции системы запрограммированы проще всего. Это утверждение я обосновывал, когда рассуждал об абстракциях в физике и программировании.

Codeium — нейросетевой помощник программиста

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

Как работает Codeium

Я установил его как плагин к PhpStorm. Для работы он требует войти в аккаунт, но регистрация бесплатна.

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

После нажатия на tab и перевода строки нейросеть продолжает сочинять. Вот тут одним махом предлагает написать весь оставшийся код метода:

Нейросеть «поняла» из названия метода, что мне нужна версия алгоритма для вычисления расстояния Левенштейна между строками, корректно работающая с кодировкой UTF-8 (в PHP есть встроенная функция levenshtein(), но она правильно работает только для однобайтных кодировок). Идея алгоритма оказалась правильной, но с деталями не вышло: сравнение $a[$i - 1] === $b[$j - 1] берет не символы с соответствующими номерами, а байты. После исправления этого фрагмента на mb_substr($a, $i - 1, 1) === mb_substr($b, $j - 1, 1) код заработал правильно.

Второй способ взаимодействия — это чат. Он мне показался туповатым по сравнению с ChatGPT. Я так и не понял, лучше ли работают английские запросы, или можно писать по-русски. На скриншотах выше видны шорткаты для быстрой формулировки запросов в чате: Refactor, Explain, Docstring. Explain описывает на «человеческом» языке, что происходит в коде. Возможно, пригодится в командной работе, когда программист в основном разбирается в чужом коде, а не пишет свой. Я же пробовал Codeium на своем коде, о котором я и так всё знаю, так что описание мне не пригодилось.

Главный вау-эффект

Наибольшая помощь от «искусственного интеллекта» была в переписывании кода и конфигурации из одного формата в другой. Допустим, вы меняете формат какой-нибудь конфигурации из XML в JSON или заменяете множество вызовов одного API аналогичными вызовами другого. Из классических инструментов может помочь замена с помощью регулярных выражений или мультикурсор, да и то не всегда. В примере на скриншоте ниже поможет только ручное копирование каждого значения и ввод служебных символов. А с Codeium я скопировал старый код в новый файл, начал дописывать новый код, и он, распознав закономерность, стал предлагать в автодополнении правильное продолжение на основе старого кода.

Недостатки

Теперь о недостатках, куда же без них. Во-первых, Codeium может только добавлять код. Он не может предложить удалить какой-то фрагмент. Во-вторых, он подтормаживает. Тормозит и появление фрагмента для автодополнения, и последующее редактирование текста. Заметно, что автодополнение сделано не нативно — серый текст располагается не в какой-то выпадайке, а прямо внутри редактируемого текста. И если я не принимаю подсказу, нажимая tab, а продолжаю дописывать текст или передвигаю курсор стрелками, проходит заметное время, прежде чем серый текст удалится и появятся набираемые символы. А курсор при перемещении сначала попадает в серый текст, потом серый текст исчезает и курсор оказывается в нужном месте основного текста. После этого Codeium опять подумает и добавит новую версию серого текста с подсказкой. Даже если плагин не запутается и корректно допишет вводимые символы куда нужно и расположит курсор, такое поведение напрочь убивает мгновенную обратную связь при наборе текста и делает сам набор почти невозможным. Может эти недостатки — следствие ограниченного API плагинов в PhpStorm. Но сейчас всё работает не очень приятно.

Ненативность автодополнения проявляется еще, например, при переименовании. Вот здесь я переименовываю метод так, что PhpStorm заменит его вызовы по всему проекту. На этот режим указывает голубая рамка. Codeium умудряется дописать свое мнение еще и сюда, но сам PhpStorm о нем ничего не знает. Когда я применил подсказку пару недель назад и закончил переименовывать, PhpStorm заменил вызовы по всему проекту на недополненное несуществующее название. Сейчас при попытке воспроизведения tab в режиме переименования просто не работает, подсказка не применяется. То есть Codeium выдает свой вариант, но применить его никак нельзя.

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

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

Вывод

В процессе работы перевешивают то достоинства нейросетевого помощника, то его недостатки. Забавно наблюдать, как нейросеть «читает» твои мысли, выдавая ровно тот код, который ты сам собрался написать. Правда, происходит такое не всегда. Когда нейросеть предлагает нужные фрагменты кода, их надо тщательно проверить, как за программистом-стажером. В то же время при рефакторинге встроенными в PhpStorm инструментами я отключал Codeium, потому что тогда его подсказки бесполезны, а подтормаживания интерфейса мешают.

В общем, перспективы большие. Пользовательский опыт сейчас страдает. Пробуйте сами.

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

Воскрешение access-токенов

Недавно Фёдор Борщёв написал о том, что разделение на access-токены и refresh-токены не очень-то и нужно, можно обойтись каким-то одним. На тему токенов я вспомнил об одном приеме для повышения надежности приложений в ситуациях, когда сервис авторизации недоступен.

У нас на работе для единого входа в приложения (SSO) и получения ролей используется Keycloak. В целом он работает нормально, но иногда подтекает по памяти и начинает отвечать ошибками типа 502. В этот момент приложение тоже становится недоступным: когда истекает время жизни access-токена, приложение запрашивает новый токен, получает ответ 502 и по умолчанию падает на неперехваченном исключении. Простой приложения влечет остановку основного бизнес-процесса и прямую потерю денег.

Чтобы уменьшить влияние недоступности сервиса авторизации на работающее приложение и предотвратить потерю денег, мы придумали переиспользовать истекшие токены и назвали этот прием «воскрешением». Время жизни access-токена продлевается на TTL, если сервис авторизации возвращает ошибку с кодом 5xx. В воскрешении важно не переусердствовать, коды ошибок 4xx не должны разрешать пользователю продолжать работу.

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

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

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

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

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

Храните состояние долгоживущих процессов в базе данных, а не в памяти

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

Обычно нефункциональные требования в техническом задании не сформулированы, и о них никто кроме разработчика не думает. Чтобы выделить их в явном виде, попробуйте ответить на следующие вопросы:

• Как понять, чем сейчас занимается долгоживущий процесс? Он работает или завис?
• Как понять, сколько задач он обработал за последние 10 минут? За полчаса? За сегодня?
• Что будет, если процесс упадет? (Да-да, ваш код, конечно, не падает, но обрыв соединения с базой данных и другими сервисами из-за проблем с сетью никто не отменял.) Зависнет ли обрабатываемая задача?
• Зависнет только одна задача? Или все N задач, попавшие в процесс?
• Продолжит ли выполняться задача после перезапуска процесса?
• Если продолжить выполнение задачи нельзя, вернется ли ответ в вызывающую систему об ошибочной ситуации? Будет ли он обработан? Зависнет ли задача в вызывающей системе?
• Позволяет ли ваша система потерять выполняемые задачи? Какие у вас требования к надежности? (Сравните, для примера, пропуск одного обновления данных в каком-нибудь кеше при его ежеминутном обновлении и потерю данных о финансовой транзакции.)

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

Какие преимущества получаем от хранения состояния долгоживущих процессов в базе данных?

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

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

Простота мониторинга. В подготовленной системе мониторинга достаточно написать SQL-запрос, и новая метрика готова. Если же состояние хранится в памяти процессов, нужно дополнительно программировать отправку данных в систему мониторинга. Мониторинг дает представление о работе системы, выраженное в виде метрик (например, количество обработанных задач, время выполнения и другие показатели производительности). С помощью мониторинга заинтересованные лица оперативно и даже проактивно реагируют на проблемы.

Наблюдаемость состояния в админке. Когда состояние хранится в базе данных, его легко вывести в админке. Таким образом, вы сделаете работу приложения наблюдаемым. Иначе ваше рабочее время будет уходить на однотипные вопросы коллег, реагирующих на обращения пользователей: «что случилось с заявкой №782354, запрос ушел, но ответа не было?»

Совет, вынесенный в заголовок, не нов. Делать процессы без состояния (stateless) — одно из требований к 12-факторным приложениям.

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

Мониторинг производительности приложений в New Relic

New Relic — это набор инструментов для обеспечения «observability» веб-приложений, то есть наблюдения за их внутренним состоянием. Для меня самый полезный инструмент — APM, или мониторинг производительности.

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

Зачем нужен мониторинг производительности

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

Первый полезный экран — список запросов к базе данных. Можно выбрать какой-либо запрос (на скриншоте запросы на чтение к таблице users) и увидеть среднее время выполнения в миллисекундах (query time) и количество запросов в минуту (throughput). Кроме того, есть разбиение по источникам запросов (time consumption by caller), в котором видно, с каких страниц идут выбранные запросы.

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

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

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

Например, на скриншоте выше время ответа веб-сервера составляло целых 4 секунды, а причина тому — запрос к БД. Сам запрос тоже можно открыть:

Обратите внимание на то, что все числа и строки в запросе заменены на знаки вопроса. Это сделано по соображениям безопасности для обезличивания возможных персональных данных в тексте запроса.

Установка и настройка

Установка нью-релика на сервер состоит из двух несложных частей (уровня apt install). Во-первых, нужно установить демон, который отвечает за отправку данных на серверы нью-релика. Во-вторых, нужно подключить нью-релик к вашему веб-приложению. Для PHP нью-релик устанавливается как расширение (*.so) и начинает работать после того, как вы скопируете в php.ini лицензионный ключ из личного кабинета на сайте. Расширение отправляет данные в процесс демона (очевидно, через сокет), а демон пересылает данные асинхронно. Благодаря такому подходу нет заметной просадки производительности.

Расширение нью-релика автоматически определяет и регистрирует запросы к базам данных, запросы через curl к внешним системам. Оно даже понимает, какой фреймворк используется, и берет названия маршрутов (routing) как названия транзакций. Данные на всех скриншотах выше собраны автоматически, для их сбора я ничего дополнительно не настраивал.

Продвинутое использование через API

Расширение нью-релика предоставляет API. Через него я определял свои транзакции из долгоживущих процессов и регистрировал метрики. Например, в сервисе генерации формул я профилирую некоторые шаги генерации как будто это обращения к некоторым базам данных (за это отвечает функция newrelic_record_datastore_segment(); возможно, тут подошли бы другие функции, но меня и так всё устраивает):

<?php

class Helper
{
    public static function newRelicProfileDataStore(callable $callback, string $product, string $operation, string $collection = 'other')
    {
        if (\extension_loaded('newrelic')) {
            return \newrelic_record_datastore_segment($callback, [
                'product'    => $product,
                'operation'  => $operation,
                'collection' => $collection,
            ]);
        }

        return $callback();
    }
}

// запуск внешнего процесса
Helper::newRelicProfileDataStore(
    static fn() => shell_exec($command),
    'shell',
    Helper::getShortCommandName($command)
);
                
// запрос по http на localhost
$optimizedSvg = Helper::newRelicProfileDataStore(
    fn() => file_get_contents($this->httpSvgoUrl, false, $context),
    'runtime',
    'http-svgo'
);

// "долгая" операция сжатия
$gzEncodedSvg = Helper::newRelicProfileDataStore(
    static fn() => gzencode($optimizedSvg, 9),
    'runtime',
    'gzencode'
);

Результат на скриншоте. Мы видим, что шаг по запуску латеха и генерации dvi-файла занимает примерно столько же, сколько отрабатывает dvisvgm. А на оптимизацию получившегося svg-файла времени тратится немного (к тому же она еще и в фоне происходит).

Выводы

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

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

Я не знаю, есть ли альтернатива сервису APM нью-релика. Если вдруг знаете — напишите в комментариях. На волне «импортозамещения» мы аналогов не нашли. Но зато я узнал о бесплатной квоте в 100 гигабайт, что вдохновило меня написать эту заметку.

Алгоритмическая сложность

Одна из тем, которые я обязательно поднимаю на собеседовании, — это сложность алгоритмов. Кандидату на мои вакансии достаточно назвать сложность наилучшей сортировки — O(n·ln n). Еще о структурах данных речь заходит при обсуждении работы индексов БД. Кандидат должен объяснить, за счет чего индексы ускоряют выполнение запросов.

Если кандидат не дает ответа O(n·ln n), это тревожный звоночек. В зависимости от вакансии я могу еще попросить оценить сложность простейшей сортировки, например, пузырьком, чтобы отличить пробел в знаниях от неспособности понимать эту тему.

Почему важно иметь представление об алгоритмической сложности? Что будет, если писать код без этого представления? Недавно нашелся пример: если на рабочем столе создать 1000 файлов, Windows тратит 20 секунд на открытие главного меню. И всё потому, что какой-то криворукий программист написал алгоритм сложности O(n²) там, где можно было обойтись O(n). Подробности читайте на хабре.

О тестовых заданиях на собеседованиях программистов — В кресле препода №4

Я провел много собеседований. Несколько десятков, или даже около сотни. К сожалению, с самого начала подсчитывать не догадался. Точное число было бы интересным.

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

Кстати, видео снимал по методу Ильи Бирмана.

Бэкенд и фронтенд в одном репозитории

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

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

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

Не храните бизнес-логику в базе данных

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

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

Масштабирование производительности. У приложений и базы данных различные возможности масштабирования при росте нагрузки на систему. Обычные приложения на современных фреймворках легко запустить в несколько копий на разных серверах. А вот базу данных «запустить» на нескольких серверах не так просто. Чтобы снизить нагрузку на чтение, применяют репликацию master-slave. Снизить нагрузку на запись сложнее. Но, возможно, к этим методам и не придется прибегать, если просто не создавать лишнюю нагрузку на базу данных и держать бизнес-логику в приложении.

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

Автоматизация разработки. БД как хранилище данных — стандартная практика. Для упрощения разработки в такой парадигме есть развитые инструменты — библиотеки ORM, которые умеют, в частности, автоматически генерировать скрипты миграции структуры БД. Изменение бизнес-логики в коде облегчается средствами среды разработки: автодополнением, автоматическим рефакторингом. Пользовательские функции в БД придется изменять полностью вручную.

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

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

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

Не храните бизнес-логику в базе данных.

Работа над задачами в скраме

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

Бэклоги продукта и спринта

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

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

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

Степень детализации требований в бэклоге разная: от подробно проработанных задач на следующий спринт до задач без описания на год вперед. Деятельность по уточнению и оцениванию задач называется product backlog refinement (PBR). Она может проходить в формате регулярной встречи владельца продукта, команды и заказчиков.

Критерии готовности к разработке (DoR)

Зрелая команда берет в спринт только проработанные задачи. Команда сама вырабатывает критерии готовности к разработке (definition of ready, DoR) с учетом особенностей проекта и предметной области. Пример:

Если на проработке задачи «сэкономили», то на выяснение требований, согласования и переделки потеряется больше времени. Скрам-мастер объясняет постановщикам задач, что критерии готовности — это не капризы разработчиков. Пример:

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

Зачем оценивать задачи?

Для быстрой обратной связи владельцу продукта и заказчику о сложности задач. У нас в CityAds был образцовый иллюстрирующий случай.

Оценка задач в часах

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

Оценка задач в стори-поинтах

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

Объем работ больше, если в задаче надо сделать пять экранов, а не два.

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

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

Стори-поинты нужны, чтобы сравнивать задачи друг с другом, поэтому абсолютное значение стори-поинта не важно. Для начала использования сопоставьте 1 стори-поинт несложной типовой задаче. Затем группируете выполненные задачи по условной шкале: чем правее задача, тем сложнее.

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

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

Важно ограничить возможные значения стори-поинтов. Обычно используют числа Фибоначчи (слегка измененные: 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100) или степени двойки: чем больше соседние числа, тем больше интервал между ними. Иногда числа вообще заменяют на обозначения размеров одежды: S, M, L, XL, XXL.

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

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

Бывают менее однозначные ситуации.

Здесь потребуется дополнительная проработка задачи: уточнение требований у заказчика, разбиение крупной задачи на несколько частей. Когда команда не знает, как делать сложную задачу, она берет в спринт «ресёрч» — задачу на исследование. Как и любая работа в спринте, ресёрч оценивается в стори-поинтах. На выходе ресёрча — готовая к разработке задача (удовлетворяющая DoR).

Как оценивать задачи и планировать спринт?

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

Фокус-фактор — это доля времени, которая уходит на разработку запланированных задач, от общего рабочего времени. Например, фокус-фактор 0,5 означает примерно одинаковую долю условной разработки и поддержки. Хорошим считается значение 0,7.

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

Планировать спринт в стори-поинтах помогает понятие производительности команды (velocity). Это сумма оценок в стори-поинтах выполненных в спринте задач. Если команда не успела в течение спринта полностью выполнить задачу, стори-поинты задачи потеряны.

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

Мы в CityAds в течение года после внедрения скрама пришли к совмещению двух методов оценки. Оценивали бэклог продукта в стори-поинтах, чтобы владелец продукта и заказчики знали «вес задач» и определяли приоритеты. На планировании разбивали задачи на подзадачи, назначали на исполнителей, исполнители давали оценку в часах. Пример:

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

Диаграмма сгорания, впихинг и скрам

На стендапах полезно визуализировать оставшийся объем работ в спринте на диаграмме сгорания («бёрндаун-чарт»). В идеале объем равномерно уменьшается каждый день. На практике, когда команда успевает выполнить все задачи, в конце спринта объем работы уменьшается быстрее, и график получается примерно таким:

Иногда получается, что график на диаграмме сгорания растет:

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

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

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

Введение в скрам

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

Зачем нужен скрам

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

Команда и спринты

Рабочая единица по скраму — скрам-команда. Она состоит из трех частей:

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

В команде разработки у всех одинаковая роль — «разработчик». У каждого разный опыт и уровень экспертизы, и это влияет на конкретный вид выполняемой работы. Но ответственность за результат у команды общая.

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

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

Рабочий процесс по скраму делится на итерации — спринты. Команда разработки создает и в конце спринта поставляет заказчику некоторую завершенную функциональность — инкремент продукта.

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

• планирование,
• ежедневный скрам («стендапы»),
• демонстрация новой функциональности заказчикам и пользователям
• ретроспектива.

Планирование

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

Вот что написано о цели в руководстве:

Цель Спринта — это установленный для Спринта ориентир, который достигается посредством выполнения части Бэклога Продукта. Цель Спринта формулируется во время его Планирования и объясняет Команде Разработки, для чего создается Инкремент.

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

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

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

В следующий раз я расскажу о стендапах и о работе с задачами по скраму.

Исправляем баги с помощью рефакторинга

Василий Половнёв в советах рассказывает, как исправлять баги:

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

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

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

Написано верно. Такому алгоритму и нужно следовать, исправляя баги. Но что делать, если баг воспроизвести нельзя? Я расскажу об одном таком баге, с которым пришлось бороться в CityAds.

Симптом

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

Попытка воспроизведения

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

Изучение кода

К сожалению, в CityAds было много legacy-кода. Логика обработки смс-кода была размазана по двум местам: генерированию кода перед его отправкой и проверке этого кода при вводе. В реализации присутствовали многие признаки говнокода. Код написан в контроллерах без дополнительных уровней абстрацкии, в императивном стиле. Время отправки, сумма к выводу и id внешнего счета хранились в разделяемой памяти — суперглобальном массиве сессии. Формат хранения — ассоциативный массив:

$_SESSION['sms_codes'][$account_id]['code'] = $code;
$_SESSION['sms_codes'][$account_id]['time'] = time();
$_SESSION['sms_codes'][$account_id]['amount'] = $amount;

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

Говнокод плох тем, что он «одноразовый». Его просто написать, но сложно понимать и изменять.

Логирование

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

Я залогировал значения переменных и увидел, что к моменту проверки кода в сессии было пусто, как будто код вообще не генерировался. Тем не менее, другие значения, не связанные с смс-кодами, в сессии присутствовали. Я не смог найти причину очистки. Код на серверах был одинаков. Сравнение конфигурации PHP ничего не дало.

Гипотеза

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

Я решил не искать, кто именно портит данные в сессии, а с нуля переписать обработку смс-кодов и уйти от хранения данных в сессии.

Рефакторинг

К этому времени мы подключили Symfony и писали новый код по принципам SOLID. Я написал сервис, в котором инкапсулировал логику работы с смс-кодами. Сервис принимал тройки значений (code, time, amount) в виде одного объекта (DTO), сохранял их в кеше (у нас был мемкеш) и при необходимости возвращал. Старый код через синглтон обращался к DI-контейнеру и доставал оттуда сервис.

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

Ссылки по теме

• Подробности о переходе от императивного кода к объектному, SOLID, DTO, DI в скринкасте по рефакторингу с помощью PHP Storm
• Еще одна байка из CityAds на хабре: PHP, статические переменные внутри методов класса и история одного бага

Промышленное программирование и область ответственности разработчика

Промышленное прогаммирование

Хочу поделиться опытом промышленной разработки программного обеспечения. Под словом «промышленная» я понимаю разработку приносящего деньги продукта в коллективе от нескольких десятков человек.

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

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

Аджайл-манифест разработки программного обеспечения

Начнем систематизировать знания о разработке с аджайл-манифеста:

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

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

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

Область ответственности разработчика

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

Никто никого не должен отвлекать по пустякам, вообще обычный разработчик должен в рабочее время заниматься только выполнением текущих запланированных задач и реагировать только на два типа сообщений:
1. Авария — что-то серьезное на продакшене или ошибка на уровне архитектуры, в первом случае срочно чиним, во втором останавливаемся и обсуждаем т.к. дальнейшая работа может просто оказаться бессмысленной. Если часто проблемы с продом — это чаще всего косяк тестировщиков, если хреново спланирована архитектура или выбраны не те инстументы — косяк архитекторов.
2. Блокировка — т.е. отсутствие реакции на это сообщение реально блокирует работу другого человека. Если есть большой поток блокирующих сообщений, то это либо отсутствие компетенции у других исполнителей — косяк того кто их нанял, либо хреновое планирование и распределение задач между исполнителями — косяк ПМа.

Если же разработчик вынужден по работе напрямую общаться с кем либо кроме ПМа и других разработчиков (например с заказчиками), то ему лучше сменить место работы!

Вторая:

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

Это два противоположных подхода к вопросу об области ответственности разработчика. Давайте выделим особенности каждого подхода:

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

Руководитель программистов должен учитывать при подборе и огранизации рабочего процесса особенности каждого способа. Первый свойственен водопадной модели, воторй — аджайлу. Если вы нанимаете инициативных разработчиков — готовьте бюджет. Если нанимаете операторов ЭВМ, нанимайте еще менеджеров и тестировщиков.

Программирование ≠ информатика

На хабре перевод статьи некоего Коннелла о том, почему нельзя до конца формализовать и алгоритмизировать разработку софта:

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

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

• Что должна делать эта программа? (требования, юзабилити, безопасность)
• Как должна выглядеть программа внутри, чтобы её легко было починить и модифицировать? (архитектура, дизайн, масштабируемость, переносимость, расширяемость)
• Как долго займёт её написание? (оценка)
• Как мы должны её разрабатывать? (кодирование, тестирование, измерение, конфигурация)
• Как следует эффективно организовать работу команды? (менеджмент, процесс, документация)

Все эти проблемы вращаются вокруг людей.

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

Как улучшить legacy-код

Статья на хабре «Как улучшить legacy-код». Многим пригодится, потому что легаси-код есть в большинстве проектов. Особенно рекомендуется тем, кто сразу хочет переписать такую систему с нуля, едва столкнувшись с ней.

Разрушаем мифы о PhpStorm

Илья Бирман написал о редакторах и средах разработки:

Я много лет использовал редактор кода «Сублайм-текст». Он не дотягивал по функциональности даже до «Эдитплюса», которым я пользовался на Винде больше десяти лет назад, но казался мне самым приятным и продвинутым из того, что есть на Маке. Всякие ИДЕ я не рассматривал — они уродские и тормозные. Однажды я видел, как разработчик переименовывал файл в «ПХПШторме». На экране несколько секунд заполнялся прогрессбар. Нет, спасибо.

Давайте я тоже поддержу межблоговые дискуссии и отвечу Илье. А ответить есть что.

Уже лет 5 я использую PhpStorm как один из основных инструментов. Как такое могло произойти, если среды разработки — уродские и тормознутые? Давайте разбираться.

Переход на PhpStorm

Раньше я программировал в Notepad++. Вершина его функций — поиск и замена по всем файлам в папке. Казалось, этого вполне достаточно. Мне тоже нравилась скорость работы редактора, и я тоже относился к IDE снисходительно. «Я и так знаю названия функций, нахрена мне тормознутая подсветка синтаксических ошибок в коде?»

Я не помню, что заставило меня скачать PhpStorm. Мне могли понадобиться какие-то возможности, которых не было в плагинах к Notepad++. Или я заинтересовался, что же всё-таки находят в нем люди. Помню только, что он подсвечивал желтым слишком много подозрительных мест в моем коде.

Тем не менее, PhpStorm у меня прижился. Как автор опенсорсного продукта — движка S2 — я получил бесплатную лицензию. С тех пор PhpStorm стал одним из основных моих инструментов.

Миф №1: PhpStorm тормозит

PhpStorm как IDE отличается от текстовых редакторов:

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

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

Миф №2: переименование файла занимает в PhpStorm несколько секунд с прогресс-баром

Зависит от того, что нужно программисту. PhpStorm способен искать вхождения старого названия файла по всему проекту и по контексту определять, нужно ли это название изменить. Альтернатива в обычных редакторах — поиск и замена по всем файлам — занимает несколько минут рутинной работы. Экономия времени на два порядка.

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

Миф №3: PhpStorm «устанавливать и настраивать год»

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

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

• путь к git.exe для работы с гитом;
• доступ к БД, чтобы делать запросы из среды разработки;
• доступ на сервер по SSH/FTP для загрузки файлов проекта.

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

Миф №4: PhpStorm «выглядит как говно»

Вкусовщина, конечно. Нормально он выглядит. Внешний вид работать не мешает. Чтобы не приводить зря громадный скриншот, покажу заодно «git blame»:

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

Современный рынок труда

Сегодня за обедом разговаривали с коллегой:
— Я чувствую спрос на себя как на программиста, а как на физика — не чувствую.
— И это в стране, первой запустившей человека в космос.

Закомментированный код

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

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