У каждого программиста есть свои предпочтения: кто-то любит продумывать архитектуру приложения, кто-то — решать алгоритмические задачи, кому-то просто нравится писать код, а я вот ловлю кайф от процесса исправления ошибок. Конечно, имеются в виду не примитивные баги, а ошибки, на которые большинство разработчиков махает руками и говорят, что это баг компилятора / фича ОС / козни Билла Гейтса. С некоторой натяжкой в эту категория можно также отнести различные performance issues. Чтобы для нахождения причины проблемы нужно было обладать познаниями в различных областях, проявить смекалку, выдержку. Иными словами, быть таким себе доктором Хаусом от программирования.
Как я себе это представляю. Есть некая крупная софтверная компания, которая разрабатывает сложный программный продукт. Разработчики в ней часть времени тратят на добавление нового функционала, а часть — на исправление ошибок в уже существующем. Естественно, время от времени попадаются различные weird issues (и их число относительно велико, а последствия — достаточно серьезны), на исправление которых у них не будет хватать времени / мастерства / желания. Чаще всего программист пытается воспроизвести такую ошибку, у него это не получается — он помечает ее как monitored и откладывает в долгий ящик. Но ведь с другой стороны, можно завести специального человека (либо целый отдел), задача которого будет состоять в диагностике и исправлении подобных ошибок.
Как вы считаете, возможна ли подобная специализация? Сталкивались ли с чем-нибудь подобным?
Д>Как вы считаете, возможна ли подобная специализация? Сталкивались ли с чем-нибудь подобным?
нет, невозможна. качаство продукта либо устраивает — и тогда делать ничего не надо, либо нет — и тогда бороться с багами нужно на ранних стадиях: вкладывать бабло в дизайн, найм лучших людей, обучение, повышение качества кода
Здравствуйте, Джеффри, Вы писали:
Д>Чтобы для нахождения причины проблемы нужно было обладать познаниями в различных областях, проявить смекалку, выдержку.
Достаточно реально поставить цель перед отвечающей командой — исправить этот баг. А не позволить им отказываться от него.
Д>на исправление которых у них не будет хватать времени / мастерства / желания.
Мастерство/желание/время.
Даже если вам повезет, почему вы думаете, что будет что-то интересное? 99% времени будет уходить на самую обычную текучку.
Д>Чаще всего программист пытается воспроизвести такую ошибку, у него это не получается — он помечает ее как monitored и откладывает в долгий ящик.
И заявивший об ошибке (или специальный тестер) — должен показать, как именно ошибку можно повторить.
Д>Но ведь с другой стороны, можно завести специального человека (либо целый отдел), задача которого будет состоять в диагностике и исправлении подобных ошибок.
Понимаю, что вы хотите сказать, но описываете вы самых обычных инженеров-тестеров. Они тоже могут сами все исправлять + предоставлять патч и т.д. Например, SDET.
Д>Как вы считаете, возможна ли подобная специализация? Сталкивались ли с чем-нибудь подобным?
Еще под описание также подходит что-нибудь вроде (Tech.) Support Engineer — одной из последних линий, проблемы не элементарные, и их нужно решать.
Вариантов очень много, вплоть до самого обычного консалтинга, где вообще между фирмами прыгать именно ради этого.
Так что — конечно возможна. Если же просто в какой крупной компании, чтобы именно выделяться "мастерством / желанием", чтобы попасть на такое место — вам надо лет 5-10 проработать на такую крупную компанию, где такое возможно — и показать, что именно вас надо туда поставить.
А так — вот, вообще позиция по глобальному System Performance. То есть копать везде и смотреть, что можно ускорить.
Д>Как вы считаете, возможна ли подобная специализация? Сталкивались ли с чем-нибудь подобным?
Да, сталкивался. Наша область, системы для автоматической торговли, отличается большой сложностью продуктов, различными вариантами использования, большим количеством взаимодействий со сторонними системами (площадки, data providers, стратегии, модели, in-house системы etc). Есть достаточно много ситуаций, когда для воспроизведения проблемы нужно смоделировать часть клиентского сетапа, возможно, добавить что-то в саму клиентскую инсталляцию или как-то модифицировать ее для локализации проблемы. Так сложилось что подобными вещами занимался support (правда, у нас support это немного не то что обычно понимается по-крайней мере на питерском рынке труда), product specialists. Даже если отвлечься от того чем кому нравится заниматься, необходимы некоторые знания в бизнес-области, понимание системы вцелом, опыт, чутье.
Здравствуйте, Джеффри, Вы писали:
Д>У каждого программиста есть свои предпочтения: кто-то любит продумывать архитектуру приложения, кто-то — решать алгоритмические задачи, кому-то просто нравится писать код, а я вот ловлю кайф от процесса исправления ошибок. Конечно, имеются в виду не примитивные баги, а ошибки, на которые большинство разработчиков махает руками и говорят, что это баг компилятора / фича ОС / козни Билла Гейтса. С некоторой натяжкой в эту категория можно также отнести различные performance issues. Чтобы для нахождения причины проблемы нужно было обладать познаниями в различных областях, проявить смекалку, выдержку. Иными словами, быть таким себе доктором Хаусом от программирования.
Д>Как я себе это представляю. Есть некая крупная софтверная компания, которая разрабатывает сложный программный продукт. Разработчики в ней часть времени тратят на добавление нового функционала, а часть — на исправление ошибок в уже существующем. Естественно, время от времени попадаются различные weird issues (и их число относительно велико, а последствия — достаточно серьезны), на исправление которых у них не будет хватать времени / мастерства / желания. Чаще всего программист пытается воспроизвести такую ошибку, у него это не получается — он помечает ее как monitored и откладывает в долгий ящик. Но ведь с другой стороны, можно завести специального человека (либо целый отдел), задача которого будет состоять в диагностике и исправлении подобных ошибок.
Д>Как вы считаете, возможна ли подобная специализация? Сталкивались ли с чем-нибудь подобным?
видел, была целая команда — не вылезала из логов и фиксила ошибки. имела очень звучное название. но из Хаузов от программированя не состояла, наверно потому что слишком комфортная эта работа диагностировать и фиксать баги — все очень предупределено — ведь при достачоных усилиях результат будет опеспечен.
Здравствуйте, Джеффри, Вы писали:
Д>Как вы считаете, возможна ли подобная специализация? Сталкивались ли с чем-нибудь подобным?
Как раз в такой команде и сижу. Ну, правда, баги все больше незамысловатые, их только воспроизвести бывает сложно, но если удалось — то, как правило, разработчики этих фич обычно в курсе в чем дело.
Д>Как вы считаете, возможна ли подобная специализация? Сталкивались ли с чем-нибудь подобным?
Пока сталкивался только 2 раза с тем, что сами разработчики системы не могут найти причину проблем, и компания нанимает сторонних консультантов. Так что думаю, что из затеи ничего не получится, слишком узкий рынок и будет очень сложно находить заказы. Более того, решение проблем такого рода — удача, и вполне вероятно, что заказчик разорвет контракт после первого безрезультативного месяца.
Здравствуйте, Джеффри, Вы писали:
Д>Как вы считаете, возможна ли подобная специализация? Сталкивались ли с чем-нибудь подобным?
Обычно, когда подобных ошибок становится некоторое критическое количество, нанимается консультант-эксперт, который либо все это фиксит сам (в случае проблем с БД такое возможно), либо работает в команде с 1-2 разработчиками: он слушает, они рассказывают об архитектуре и реализации, в ходе чего эксперту становится понятно, где же могут быть те самые проблемы, ну и как правило, решение находится. Но обычно штатно такой человек не нужен, поэтому он нарабатывает свои экспертные знания где-то, а консультирует в свободное от работы время.
Здравствуйте, De-Bill, Вы писали:
Д>>Как вы считаете, возможна ли подобная специализация? Сталкивались ли с чем-нибудь подобным?
DB>Пока сталкивался только 2 раза с тем, что сами разработчики системы не могут найти причину проблем, и компания нанимает сторонних консультантов. Так что думаю, что из затеи ничего не получится
я хочешь-не хочешь нахожу ошибки сам, просто делать это не люблю. если бы можно было только творить, сваливая на других нужный поиск ошибок — мне было бы интереснее. с другой стороны, до какого предела это можно довести?
* thriving in a production environment *
