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

В этой статье я решил поделиться нашим проектом, который мы с Тимофеем Евграшиным делаем в свободное время как говорится «для души». Это платформа бесплатных онлайн конференций IT Brunch, которую мы запустили полтора года назад. Ближайшая пройдет 18 мая и будет посвящена .NET платформе. Если вам интересно узнать больше об IT Brunch или даже принять участие, добро пожаловать под кат.

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

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

Опыт вождения по дорогам Киева натолкнул меня на пару интересных мыслей. Все мы знаем, что на дорогах «куча идиотов». Ровно так же дело обстоит и в разработке – куда ни глянь, страшно на код взглянуть. Почему так происходит?

По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем? Если вы тоже задавались этими вопросами, добро пожаловать под кат.

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

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

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

Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.

В то время как сторонники современных гибких методологий разработки выдумывают все новые и новые практики, их оппоненты также не стоят на месте. На фоне разнообразных XDD (FDD — Feature Driven Development, TDD — Test Driven Development, BDD — Behavior Driven Development, ATDD — Acceptance Test Driven Development) они сформулировали свою методологию — JSDD (Job Safety Driven Development). Кому интересны детали, добро пожаловать под кат.

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

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