Сегодня закончив очередную статью для своего блога, я перед публикацией решил отвлечься, чтобы потом прочитать ее немного посвежевшей головой. Попивая кофе и листая новости, я увидел статью "6 Things Programmers Know Are Bad But Still Do Anyway". Читая абзац о глотании ошибок втихаря, я вспомнил случай, который произошел на моей предыдущей работе. Расскажу лучше сегодня о нем. Ведь сегодня пятница, а значит статья об оптимизации размера PDF-файла подождет.
Абзац "2. Silently Swallowing Errors" примерно звучит так:
Так вот, случай из моей жизни. Я рад, что был только его наблюдателем, а не участником. Проект, над которым работала другая группа наших разработчиков, был основан на мощной проприетарной BI-системе. Из-за промашек, как со стороны нашей компании, так и со стороны заказчика, срок сдачи проекта давно прошел. Заказчик, одно важное государственное ведомство, выставил очередной список замечаний. Но времени на их устранение не уже было. Проектом, на тот момент, руководил заместитель директора - Иван. Это был замечательный человек и уникальный специалист. Его замечательность и уникальность была в том, что все, к чему он прикасался, рушилось. В результате его гениальных идей компания быстро теряла высококвалифицированных сотрудников, проекты и заказчиков. Видя безвыходность ситуации, Иван предложил решение прямо, как в приведенном выше абзаце из статьи - все ошибки скрыто обработать в коде программы. Но вот загвоздка – многие ошибки возникали, где-то глубоко внутри ядра BI-системы. А исходных кодов нет, ядро системы - черный ящик. Но наш гениальный зам директора не сдался и нашел выход из сложившейся ситуации. Один из программистов получил задачу: разработать и установить на компьютерах у заказчика службу, которая будет перехватывать сообщения об ошибках от BI-системы и скрывать их от пользователя...
Абзац "2. Silently Swallowing Errors" примерно звучит так:
Такой подход я неоднократно видел у неопытных разработчиков. Тем не менее, опытные разработчики тоже склонны втихаря глотать ошибки. И в отличие от неопытных разработчиков, они делают это преднамеренно. Когда есть масса задач, которые нужно сделать, а сроки поджимают и нет времени на решение каждой проблемы, которая появляется в баг-трекере, некоторые ошибки проще втихаря проглотить, с надеждой исправить их в будущем. Это позволит сосредоточиться на всех оставшихся более важных задачах.Глотание ошибки - это перехват ошибки без ее дальнейшей обработки и информирования о ней пользователя. Например:
try ... какой-то непонятный баг ... except end;Знакомый код? Думаю, что подобными "костылями" в своей практике грешили многие. Я, конечно, нет. У меня с этим, как в песне Семена Слепакова: "они все такие, а я не такой..."
Так вот, случай из моей жизни. Я рад, что был только его наблюдателем, а не участником. Проект, над которым работала другая группа наших разработчиков, был основан на мощной проприетарной BI-системе. Из-за промашек, как со стороны нашей компании, так и со стороны заказчика, срок сдачи проекта давно прошел. Заказчик, одно важное государственное ведомство, выставил очередной список замечаний. Но времени на их устранение не уже было. Проектом, на тот момент, руководил заместитель директора - Иван. Это был замечательный человек и уникальный специалист. Его замечательность и уникальность была в том, что все, к чему он прикасался, рушилось. В результате его гениальных идей компания быстро теряла высококвалифицированных сотрудников, проекты и заказчиков. Видя безвыходность ситуации, Иван предложил решение прямо, как в приведенном выше абзаце из статьи - все ошибки скрыто обработать в коде программы. Но вот загвоздка – многие ошибки возникали, где-то глубоко внутри ядра BI-системы. А исходных кодов нет, ядро системы - черный ящик. Но наш гениальный зам директора не сдался и нашел выход из сложившейся ситуации. Один из программистов получил задачу: разработать и установить на компьютерах у заказчика службу, которая будет перехватывать сообщения об ошибках от BI-системы и скрывать их от пользователя...
Такая ситуация частая в коммерческой разработке. Не всегда в таких формах как в посте, но сводится всё к тому что необходим **минимально применимый** уровень качества достаточный только чтобы договор был оплачен.
ОтветитьУдалить