Не так давно я прочитал вот эту статью и понял, что я действительно благодарен дефектам. Да, никто их не любит. Да, все считают, что без них все равно дело не обойдется. Да, время на исправление дефекта практически невозможно оценить и тяжело контролировать. И при всем этом, я действительно считаю, что дефекты принесли мне много добра.
Начнем с того, что каждый дефект – это своего рода загадка. Иногда в виде «какой дибил мог так написать», но чаще всего гораздо сложнее, особенно если проект разрабатывается неплохой командой. Эти загадки весьма интересно разгадывать. Могу поспорить, что при виде некоторых дефектов у вас возникала мысль: «этого просто не может быть!». Решение подобного рода загадок стимулирует мозг и тренирует его на поиск нестандартных и интересных решений.
Дефекты обычно «подлые» и прячутся в самых укромных уголках. Чем больше вы их находите и исправляете, тем больше вы знаете о системе, ее работе и особенностях. Ведь зачастую вам приходится по пути перелопатить кучу кода. Это очень позитивно влияет на ваши будущие задачи, потому что знания системы позволяют вам решать их эффективнее.
Дефекты помогают лучше узнать инструменты и библиотеки, которые используются на вашем проекте. Ведь в них тоже бывают дефекты, по вине которых у вас что-то перестает работать. Если бы не дефекты, очень маловероятно, что я уделил бы столько внимания внутренней работе популярных библиотек. Дефекты стимулируют умение разбираться в чужом коде, читать его и понимать, а это один из главных навыков хорошего разработчика.
Наконец, мы учимся на своих или чужих ошибках. Разобравшись в причине дефекта, вы получаете урок и в будущем уже не наступите на те же грабли. Чем больше таких уроков вы получите, тем более качественным будет ваш код и тем меньше дефектов вы будете делать в будущем.
И, в качестве бонуса, вам всегда есть о чем рассказать. Ведь многие дефекты существуют в единственном экземпляре и именно вы их «выудили». Это примерно так же как у рыбаков.
Но не все дефекты обладают перечисленными плюсами. Есть банальные, однотипные и глупые дефекты. Их никто не любит исправлять, они скучны и неинтересны. Но и это большой плюс. Грамотного разработчика подобные дефекты толкают к изменениям в командных процессах и подходах к написанию кода, которые позволят избежать лишней скучной работы. Именно из-за этого меняется работа с тестировщиками, пишется больше автоматизированных тестов разработчиками, применяется TDD, code review и статический анализ кода. Мы стремимся не допускать глупых ошибок.
Именно поэтому я благодарен за каждый найденный дефект. Мне не надо его подробное описание, дополнительные артефакты и прочие популярные вещи. Я готов сам порыться в коде и найти причину – ведь это для меня шанс поучиться, который при этом принесет радость заказчику. Задумайтесь, как легко можно кого-то обрадовать и это отлично! Желаю и вам только интересных и поучительных дефектов!
Начнем с того, что каждый дефект – это своего рода загадка. Иногда в виде «какой дибил мог так написать», но чаще всего гораздо сложнее, особенно если проект разрабатывается неплохой командой. Эти загадки весьма интересно разгадывать. Могу поспорить, что при виде некоторых дефектов у вас возникала мысль: «этого просто не может быть!». Решение подобного рода загадок стимулирует мозг и тренирует его на поиск нестандартных и интересных решений.
Дефекты обычно «подлые» и прячутся в самых укромных уголках. Чем больше вы их находите и исправляете, тем больше вы знаете о системе, ее работе и особенностях. Ведь зачастую вам приходится по пути перелопатить кучу кода. Это очень позитивно влияет на ваши будущие задачи, потому что знания системы позволяют вам решать их эффективнее.
Дефекты помогают лучше узнать инструменты и библиотеки, которые используются на вашем проекте. Ведь в них тоже бывают дефекты, по вине которых у вас что-то перестает работать. Если бы не дефекты, очень маловероятно, что я уделил бы столько внимания внутренней работе популярных библиотек. Дефекты стимулируют умение разбираться в чужом коде, читать его и понимать, а это один из главных навыков хорошего разработчика.
Наконец, мы учимся на своих или чужих ошибках. Разобравшись в причине дефекта, вы получаете урок и в будущем уже не наступите на те же грабли. Чем больше таких уроков вы получите, тем более качественным будет ваш код и тем меньше дефектов вы будете делать в будущем.
И, в качестве бонуса, вам всегда есть о чем рассказать. Ведь многие дефекты существуют в единственном экземпляре и именно вы их «выудили». Это примерно так же как у рыбаков.
Но не все дефекты обладают перечисленными плюсами. Есть банальные, однотипные и глупые дефекты. Их никто не любит исправлять, они скучны и неинтересны. Но и это большой плюс. Грамотного разработчика подобные дефекты толкают к изменениям в командных процессах и подходах к написанию кода, которые позволят избежать лишней скучной работы. Именно из-за этого меняется работа с тестировщиками, пишется больше автоматизированных тестов разработчиками, применяется TDD, code review и статический анализ кода. Мы стремимся не допускать глупых ошибок.
Именно поэтому я благодарен за каждый найденный дефект. Мне не надо его подробное описание, дополнительные артефакты и прочие популярные вещи. Я готов сам порыться в коде и найти причину – ведь это для меня шанс поучиться, который при этом принесет радость заказчику. Задумайтесь, как легко можно кого-то обрадовать и это отлично! Желаю и вам только интересных и поучительных дефектов!
