processes

Как вы догадались, я считаю, что разработчики всех мастей должны обращать внимание на правильное выполнение вещей больше, но обо всем по порядку. Disclaimer Опыт, которым я хочу поделиться, я наблюдал у других и в своих проектах. Когда я говорю обобщенно разработчики, я имею в виду всех, кто выполняет задачи: тестировщики, фронтендеры, бэкендеры, дизайнеры и так далее. Проект - это конфликт Проект - это здоровый конфликт интересов его участников: Продакт оунер хочет, чтобы time-to-market был минимален, а конверсия и воронка - прямыми, как труба....

О компании Компания Clever (далее просто компания или Clever) разрабатывает e-commerce платформу для бизнесов с 2005 года. Целевая аудитория - компании, которые продают лицензии программ. Под капотом интеграция платежных систем, репорты, отчеты по воронкам продаж, и все это в большом монолитном приложении. Если вы покупали Parallels для своего макбука в течение последних пары лет, то вы точно проходили через платежные страницы Clever. Компания продуктовая, работает чуть больше ста человек. Из них больше половины - разработчики, организованные в команды по направлениям (юнитам)....

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

TLDR: Я считаю, что на проекте за качество ответственны только разработчики, значит они должны думать больше о качестве, чем о бизнес-ценности. Но есть нюанс. Disclaimer: под термином “разработчики” в посте я имею в виду и программистов, и тестировщиков. Code quality Разработчики должны понимать, что деньги для них берутся не из тумбочки, но и проект вряд ли будет приносить деньги, если стабильность оставляет желать лучшего. В интернете масса статей, где пишут, что нужно соблюдать баланс между качеством и скоростью доставки на продакшн, но такой совет звучит как “варить суп до готовности” - непонятно, как искать этот баланс....

Картинка взята отсюда Очевидные вещи нужно проговаривать Так говорил мой тимлид, закончивший юрфак, но ушедший в айти. Говорил он так о процессах разработки: свод правил, по которым работает команда. Этакий кодекс программиста отдела N. Этот свод правил должен быть публичным и каждый должен знать, где его прочесть. Но зачем нужно описывать то, что и так всем известно? Давайте обсудим. Правила работы в команде есть всегда, даже если они нигде не описаны и никем не проговорены....

Недавно я послушал подкаст “Идеальный бизнес-аналитик глазами разработчика” своего очень хорошего друга. Не со всеми тезисами я был согласен, однако подкаст побудил меня начать обсуждение с участниками подкаста. А потом еще и сам побывал в этом подкасте в качестве гостя. Чтобы понять, кто такой “идеальный аналитик”, важно определиться с набором требований. Что я жду от аналитика как разработчик? А как тимлид? А как менеджер проекта? Сколько людей, столько и мнений, и я тоже хочу порассуждать о том, каков он - этот неуловимый идеальный аналитик....

Эту же статью я опубликовал на habr.com. Зачем это необходимо Когда в твоей команде работают больше одного человека, так или иначе все сталкиваются с проблемой разных стилей кодирования каждого члена команды. Кто-то пишет скобки для блоков if...else, кто-то нет. Когда проект становится больше, то такой код труднее читать и еще сложнее проводить код-ревью. Чтобы код-ревью и прочие командные митинги не превратились в обсуждение tab vs spaces на повышенных тонах, лучше настроить репозиторий таким образом, чтобы сам проект не допускал написание невалидного и нестандартного для команды кода....

В комментариях к одному видео некто задал интересный вопрос: А должны ли программисты изучать бизнес-сферу проекта, где работают? Автор видео не успел ответить, а я же посчитал, что меня забыли спросить и что я должен ответить на этот вопрос. Почему не стоит слепо доверять прописанным требованиям Некоторые разработчики могут подумать, что они приходят в компанию писать код и разрабатывать архитектуру, а не вдаваться в подробности бизнеса компании. Что, мол, бизнес-аналитики должны прорабатывать все нюансы проекта и сценарии взаимодействия (Use Case - UML)....