Идеальный разработчик глазами работодателя

Вася Шустряков — хороший разработчик. Что о нем говорит его начальство?

На собеседовании соискатель Шустряков продемонстрировал широкий профессиональный кругозор, подтвердив знание не только всех 30 технологий, перечисленных в вакансии, но и оставшихся за кадром в тени загадочных и коварных символов: …, и т.д., и пр., и даже и т.д. и т.п. Нет такой технологии, которую бы Вася не вертел на одном пальце!

Особенно начальник оценил, что Вася эффективно работал и после испытательного срока. Как жаль, что батарейки большинства нанимаемых разработчиков хватает только на три месяца!

Со временем все вокруг заметили, что Вася имеет опыт работы с кроссфункциональными задачами бизнеса, поэтому, не моргнув и глазом, он всегда уверенно оценивал сроки выполнения работ. Чего тратить время на оценку и нервы на сомнения? Ведь после этого все равно и сроки подожмут, и работы новой подкинут, так что Васе придется по полной применить свой навык работать быстро. Именно поэтому выживают только коммуникабельные, вежливые и стрессоустойчивые разработчики!

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

monkey

Вот такой получился портрет идеального разработчика глазами работодателя по итогам анализа 300 вакансий .NET-разработчиков, размещенных на HeadHunter. Разработчики, вы себя узнали? Если нет, то теперь вы понимаете, что вам нужно развивать в себе.

Кроме смеха, конечно, есть и другие интересные результаты и выводы. Если вам интересно, то приходите в субботу 15 ноября на конференцию Go# Moscow и не пропустите после обеда 9-й доклад “Рейтинг навыков .NET-разработчика” Александра Рахманова!

gosharp

Реклама

Отчет об участии в Agile Kitchen Ноябрь 2013

Image

29 ноября прошла очередная конференция Agile Kitchen, организуемая сообществом Agile Russia. Конференция на этот раз прошла в офисе компании Mail.ru Group и отметилась достаточно большим количеством участников.

Среди докладчиков конференции были даже такие звезды как Akhmed Sidky — один из основателей консорциума ICAgile.

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

Далее был мой доклад о борьбе agile команды с нашествием legacy, с его проявлениями в виде багов и технического долга  🙂

Тему борьбы с техническим долгом продолжил следующий доклад Антона Бевзюка и сотоварища.

Достаточно активным получился Open Space, на котором удалось обсудить аж 24 темы.

Image

Наиболее запоминающимися для меня были два доклада. Доклад Алексея Пименова «Управленческая нирвана. Где наш золотой век?» — об эволюции менеджера, его стиля управления и команды. По сути этот доклад основан и в какой-то мере является продолжением/развитием идей из книги Jurgen Apello «Managment 3.0». А также доклад Akhmed Sidky «The Secret Ingridient to Sustainable Agility», большей частью посвященный agile mindset и немного тому, как проводить agile трансформацию организации. С ключевой мыслью — трансформация компании возможна только через изменение ее культуры в первую очередь, а не процессов. Советую всем посмотреть эти доклады, если будет возможность.

Материалы конференции (будут пополняться):

2. Алексей Воронин «Legacy vs Agile Team» презентация видео слайдкаст

6. Алексей Пименов «Управленческая нирвана. Где наш золотой век?» слайдкаст

Впечатления от конференции AgileDays’2013

Сначала хочется сказать большое спасибо организаторам конференции – как обычно конференция РУЛИТ (ну и еще, за то что мы с Сергеем Рогачевым впервые смогли выступить на таком масштабном мероприятии 😉 ).

Конечно не все выступления мне понравились, но на конференцию стоило прийти хотя бы только ради того, чтобы посмотреть на выступление Антона Волкова (AlternativaPlatform).

Впечатление №1 – Расцвет Y-менеджмента.

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

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

Продолжил тему Никита Филлипов с выступлением на тему «Менеджер — плохая идея».

Но к концу дня мне показалось, что и мы и Никита оказались непонятыми. Например, на нашем выступлении люди, которые подняли руки вначале в ответ на вопрос – «А кто из вас менеджеры?», в конце выступления не задали ни одного вопроса. L Хотя вопросов было много, но в основном они были от разработчиков (об этом чуть ниже).

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

Впечатление №2 – Информационный кокон.

Очень много вопросов, которые задавали нам ребята на конференции и на вечеринке, было из серии – «Вроде бы у нас все так как говорили вы на своем докладе – и ретроспективы есть и демо проводим, и вроде даже свобода есть. Но люди не развиваются – им пофигу. Что с этим делать?».

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

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

 Поэтому и не удивляйтесь, что в таких случаях на ретроспективах поднимаются проблемы типа «У нас упал билд сервер», вместо «Мы сорвали поставку продукта клиенту» или «Наш продукт г..в..о».

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

Усвоенные нашей командой уроки.

Рогачев Сергей

Соавторы: Акжигитов Марат, Анимисов Алексей, Воронин Алексей, Косарчук Алексей, Поморцев Кирилл, Рахманов Александр, Рыбин Сергей, Сурменок Павел.

34008_strip_sunday

Заметка представляет собой список уроков, которые одна из команд разработки выучила за время от начала проекта до выпуска продукта версии 1.0.0 в течение 2012 года.

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

Внешние коммуникации

Используйте демонстрации для сбора отзывов, это не отчетное собрание

Ситуация

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

View original post ещё 3 028 слов

Заметка 1. Частые заблуждения о юнит тестировании

Image

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

  • Наше приложение работает с внешним окружением, которые мы не можем контролировать, поэтому мы не можем писать юнит-тесты.
  • Написание юнит-теста занимает много времени, поэтому мы этого не делаем.

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

 Так что же такое юнит-тест? Если следовать Википедии — unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use. Приведу более простое определение. В ООП юнит-тест — это тест логики класса в отрыве от окружения данного класса. С одной стороны это достаточно простое и короткое определение, но как показывает практика далеко не все разработчики его правильно понимают.

Чтобы сделать это определение более понятным рассмотрим небольшую аналогию.  Представим себе печатную плату с различными транзисторами, резисторами (юнитами) на ней. Для того чтобы протестировать любой юнит на этой плате мы можем его вынуть из платы подключить к нему провода и приборы подать на провода соответствующий ток, и измерить на приборах соответствующие показания. То есть для тестирования любого компонента этой платы нам не нужны ни сама печатная плата ни любые другие компоненты, размещенные на ней. А теперь подумаем можете ли вы также вынуть любой класс из вашей программы и протестировать его без остальных классов? Я думаю многие ответят отрицательно на данный вопрос.

Так в чем же проблема, может юнит-тестированию поддаются только примитивные классы, занимающиеся арифметическими вычислениями или разбором строк? Ответ на этот вопрос – конечно нет. Проблема в том, что юнит-тестирование неразрывно связано с несколькими другими понятиями и практиками, которые часто остаются за кадром. Что это за понятия и практика — это низкая связанность (loose coupling), моки (mocks), высокая сфокусированность (high cohesion) и инъекция зависимостей (dependency injection). Разберем как каждое из этих понятий влияет на создание юнит-тестов и классов, которые могут быть протестированы юнит-тестами.

Следование принципу низкой связанности гарантирует, что ваш класс будет независим от реализации других классов и будет потреблять ровно тот внешний функционал, который ему необходим, не больше и не меньше. Что это означает на практике в ооп — все внешние зависимости вашего класса будут оформлены в виде специализированных интерфейсов, то есть в логике вашего класса не должно быть ссылок ни на один другой класс кроме вашего (за определенным исключением, о нем позже). А в интерфейсах, которые потребляет ваш класс должно быть ровно столько методов и параметров, сколько необходимо вашему классу. А теперь об исключении. Естественно ваше приложение не «конь в вакууме» и оно может взаимодействовать с некоторыми внешними ресурсами — файловая система, реестр, win API, любые внешние компоненты и т.п. Так вот, классы непосредственно взаимодействующие с этими ресурсами не получится сделать низкосвязанными, но эти классы можно сделать настолько тонкими, что в них не будет никакой логики кроме вызова соответствующего метода внешнего компонента. Такие классы не поддаются юнит-тестированию, но оно для них и не нужно, так как в них нет никакой логики.

После того как мы отвязали класс от внешнего окружения он готов для юнит-тестирования (естественно, при использовании TDD этот процесс происходит в обратном направлении, но это другая тема). Если вспомнить приведенную выше аналогию с печатной платой и ее компонентами, то для тестирования нашего класса нам нужно подсоединить к нему проводки и подать по ним напряжение, то есть симулировать внешние окружение и проверить, что наш класс корректно работает в этом окружении. Для эмуляции внешнего окружения используется технология моков (mocks), то есть эмуляторов внешнего окружения. Для этого, конечно, можно реализовать в рамках теста классы для всех интерфейсов, потребляемых классом. Но есть более простой способ – воспользоваться так называемыми mock framework (например, для C# — NMock3, RhinoMocks). Данные фреймворки позволяют вам «на лету» и предельно просто генерировать необходимые моки.

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