На днях я прочитал вот эту статью и понял, что я действительно благодарен дефектам. Да, никто их не любит. Да, все считают, что без них все равно дело не обойдется. Да, время на исправление дефекта практически невозможно оценить и тяжело контролировать. И при всем этом, я действительно считаю, что дефекты принесли мне много добра.
Начнем с того, что каждый дефект – это своего рода загадка. Иногда в виде “какой дибил мог так написать”, но чаще всего гораздо сложнее, особенно если проект разрабатывается неплохой командой. Эти загадки весьма интересно разгадывать. Могу поспорить, что при виде некоторых дефектов у вас возникала мысль: “этого просто не может быть!”. Решение подобного рода загадок стимулирует мозг и тренирует его на поиск нестандартных и интересных решений.
Дефекты обычно “подлые” и прячутся в самых укромных уголках. Чем больше вы их находите и исправляете, тем больше вы знаете о системе, ее работе и особенностях. Ведь зачастую вам приходится по пути перелопатить кучу кода. Это очень позитивно влияет на ваши будущие задачи, потому что знания системы позволяют вам решать их эффективнее.
Дефекты помогают лучше узнать инструменты и библиотеки, которые используются на вашем проекте. Ведь в них тоже бывают дефекты, по вине которых у вас что-то перестает работать. Если бы не дефекты, очень маловероятно, что я уделил бы столько внимания внутренней работе популярных библиотек. Дефекты стимулируют умение разбираться в чужом коде, читать его и понимать, а это один из главных навыком хорошего разработчика.
Наконец, мы учимся на своих или чужих ошибках. Разобравшись в причине дефекта, вы получаете урок и в будущем уже не наступите на те же грабли. Чем больше таких уроков вы получите, тем более качественным будет ваш код и тем меньше дефектов вы будете делать в будущем.
И, в качестве бонуса, вам всегда есть о чем рассказать. Ведь многие дефекты существуют в единственном экземпляре и именно вы их “выудили”. Это примерно так же как у рыбаков. 🙂
Но не все дефекты обладают перечисленными плюсами. Есть банальные, однотипные и глупые дефекты. Их никто не любит исправлять, они скучны и неинтересны. Но и это большой плюс. Грамотного разработчика подобные дефекты толкают к изменениям в командных процессах и подходах к написанию кода, которые позволят избежать лишней скучной работы. Именно из-за этого меняется работа с тестировщиками, пишется больше автоматизированных тестов разработчиками, применяется TDD, code review и статический анализ кода. Мы стремимся не допускать глупых ошибок.
Именно поэтому я благодарен за каждый найденный дефект. Мне не надо его подробное описание, дополнительные артефакты и прочие популярные вещи. Я готов сам порыться в коде и найти причину – ведь это для меня шанс поучиться, который при этом принесет радость заказчику. 🙂 Задумайтесь, как легко можно кого-то обрадовать и это отлично! Желаю и вам только интересных и поучительных дефектов!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
18) Работа без сбоев требует опыта работы со сбоями
Выявление опасности и успешное управление системой с целью сохранить производительность в приемлемых рамках требуют тесного контакта с ошибками. Добиться высокой производительности удается в тех системах, где специалисты могут почувствовать грань, когда работа системы становится менее стабильной, менее предсказуемой или не может быть уверенно диагностирована. В системах, которые по определению опасны, это значит — вычислять и контролировать опасности так, чтобы общая производительность системы оставалась в согласованных рамках. Улучшения безопасности зависят от наличия у специалистов масштабируемого подхода к угрозам и от их способности прогнозировать влияние корректирующих действий на положение системы относительно границы между максимальной производительностью и неуправляемым разгоном.
(c) Доктор Ричард Кук, “How Complex Systems Fail”
Увы учиться на своих ошибках многие не умеют. Хотя бы потому, что для начала их надо признать.