Как вы догадались, я считаю, что разработчики всех мастей должны обращать внимание на правильное выполнение вещей больше, но обо всем по порядку. Disclaimer Опыт, которым я хочу поделиться, я наблюдал у других и в своих проектах. Когда я говорю обобщенно разработчики, я имею в виду всех, кто выполняет задачи: тестировщики, фронтендеры, бэкендеры, дизайнеры и так далее. Проект - это конфликт Проект - это здоровый конфликт интересов его участников: ...
О компании Компания Clever (далее просто компания или Clever) разрабатывает e-commerce платформу для бизнесов с 2005 года. Целевая аудитория - компании, которые продают лицензии программ. Под капотом интеграция платежных систем, репорты, отчеты по воронкам продаж, и все это в большом монолитном приложении. Если вы покупали Parallels для своего макбука в течение последних пары лет, то вы точно проходили через платежные страницы Clever. Компания продуктовая, работает чуть больше ста человек. Из них больше половины - разработчики, организованные в команды по направлениям (юнитам). Большинство разработчиков - in-house, но за последний год активно шел найм аутстафферов - я как раз один из таких работников. ...
Асинхронный режим - это когда работа одного разработчика не зависит от доступности его коллег и наоборот. Если вы хотите работать автономно, то вы должны стремиться к асинхронной работе. В условиях асинхронности легче и свою нагрузку планировать, и на Бали улететь работать с пляжа, и никто не ждет тебя, говоря на дэйлике, что заблокирован. Так ли легко прийти к такому режиму? Технически нет ничего сложного. В статье я дам несколько практик и советов. Однако одному нельзя построить вокруг себя атмосферу асинхронности в то время, когда остальных хлебом не корми, а дай только созвониться “на пять минут по маленькому вопросу”. Придется учить асинхронности и коллег тоже, хотят они этого или нет. Ниже я поделюсь парой рекомендаций и аргументами, с помощью которых стоит попробовать убедить коллег в их пользе. ...
TLDR: Я считаю, что на проекте за качество ответственны только разработчики, значит они должны думать больше о качестве, чем о бизнес-ценности. Но есть нюанс. Disclaimer: под термином “разработчики” в посте я имею в виду и программистов, и тестировщиков. Code quality Разработчики должны понимать, что деньги для них берутся не из тумбочки, но и проект вряд ли будет приносить деньги, если стабильность оставляет желать лучшего. В интернете масса статей, где пишут, что нужно соблюдать баланс между качеством и скоростью доставки на продакшн, но такой совет звучит как “варить суп до готовности” - непонятно, как искать этот баланс. ...
Картинка взята отсюда Очевидные вещи нужно проговаривать Так говорил мой тимлид, закончивший юрфак, но ушедший в айти. Говорил он так о процессах разработки: свод правил, по которым работает команда. Этакий кодекс программиста отдела N. Этот свод правил должен быть публичным и каждый должен знать, где его прочесть. Но зачем нужно описывать то, что и так всем известно? Давайте обсудим. Правила работы в команде есть всегда, даже если они нигде не описаны и никем не проговорены. Так складывается исторически, что Ваня лучше знает платежи, Петя - как настроить тестовое окружение, а Юля - что делать, если нашел баг. И тот, кто уходит в отпуск, начинает получать сообщения в мессенджеры: “сорри что пишу, но …..”. В такой среде легко допустить ошибку, особенно новичкам. Еще хуже, когда даже не знаешь, кого можно спросить в критичный момент. ...
Недавно я послушал подкаст “Идеальный бизнес-аналитик глазами разработчика” своего очень хорошего друга. Не со всеми тезисами я был согласен, однако подкаст побудил меня начать обсуждение с участниками подкаста. А потом еще и сам побывал в этом подкасте в качестве гостя. Чтобы понять, кто такой “идеальный аналитик”, важно определиться с набором требований. Что я жду от аналитика как разработчик? А как тимлид? А как менеджер проекта? Сколько людей, столько и мнений, и я тоже хочу порассуждать о том, каков он - этот неуловимый идеальный аналитик. ...
Эту же статью я опубликовал на habr.com. Зачем это необходимо Когда в твоей команде работают больше одного человека, так или иначе все сталкиваются с проблемой разных стилей кодирования каждого члена команды. Кто-то пишет скобки для блоков if...else, кто-то нет. Когда проект становится больше, то такой код труднее читать и еще сложнее проводить код-ревью. Чтобы код-ревью и прочие командные митинги не превратились в обсуждение tab vs spaces на повышенных тонах, лучше настроить репозиторий таким образом, чтобы сам проект не допускал написание невалидного и нестандартного для команды кода. ...
В комментариях к одному видео некто задал интересный вопрос: А должны ли программисты изучать бизнес-сферу проекта, где работают? Автор видео не успел ответить, а я же посчитал, что меня забыли спросить и что я должен ответить на этот вопрос. Почему не стоит слепо доверять прописанным требованиям Некоторые разработчики могут подумать, что они приходят в компанию писать код и разрабатывать архитектуру, а не вдаваться в подробности бизнеса компании. Что, мол, бизнес-аналитики должны прорабатывать все нюансы проекта и сценарии взаимодействия (Use Case - UML). И это значит, по мнению этих разработчиков, что можно не о чем не волноваться, читать требования и воплощать их в жизнь так, как прописаны аналитиком. С одной стороны, такое мнение имеет право на жизнь, однако есть пара проблем: ...
Disclaimer: Данная статья — только мнение отдельно взятого разработчика о бизнес-процессах в отдельно взятой компании. Никаких неопровержимых доказательств здесь не приводят. Я работаю в команде разработки раздела сайта в банке. Сайт внешний, содержит FAQ о продуктах банка. Посещаемость клиентами в стране около 587к в месяц. Хотя относительно остальных разделов сайта это небольшая цифра. Например, в разделе “Мой банк” — мобильное интернет-отделение — посещаемость гораздо выше, но точных цифр мне никто не дал. Да я и не просил. Веб-приложение работает с кучей внутренних сервисов, дизайн раздела должен строго соответствовать установленному на всем сайте. В общем, наша команда не автономна, всегда есть зависимости от других подразделений. ...