Методы отладки кода (Кошмарная ситуация)

Мне часто приходится отлаживать приложение на моей работе. Это BI-приложение, которое мы развертываем на предприятиях, включая тестовую среду и производственную среду. Мне интересно, есть ли какие-нибудь приложения / инструменты / методы, которые люди могут предложить, основываясь на этих ограничениях:

1. Отладчик нельзя использовать на клиентском сайте или локально, поскольку программное обеспечение зависит от пользовательских сторонних приложений, для которых у нас нет тестовых сред. (РЕДАКТИРОВАТЬ: чтобы быть справедливым, в некоторых случаях возможно локальное устранение неполадок. Если мы используем только основной код. Большая часть проблемного кода находится в DLL, которая инкапсулирует сторонние специфические коммуникации: сокеты, каналы процесса, вызовы soap, настраиваемая логика, которая изменяет поведение основного кода. Как правило, во время реализации или расширения для клиента мы будем писать новый код в этой области.)

2. В наших приложениях практически не ведется логирование. Там нет модульных тестов.

3. Контроль версий имеет только 1 версию полного решения (с использованием Source Safe 2005). Поэтому невозможно получить предыдущую версию всего решения, только отдельные файлы. (Если кто-то не знает способов обойти это).

4. Невозможно воспроизвести локально, часто невозможно воспроизвести в тестовой среде (высокая вероятность того, что тестирование и производство не совпадают).

5. Существует высокая вероятность того, что версия, используемая клиентом, отличается от версии, безопасной для исходного кода. Это связано с тем, что обновляются отдельные файлы, в которые встроена пользовательская логика для этого конкретного клиента. Часто случается, что обновление выполняется в двоичном файле, который требует изменений в нескольких других двоичных файлах, но когда фиксация сделана, ни у кого нет записей или знаний об этом. Я вижу довольно распространенную ошибку: «Функция / метод не найден» или «В вызове метода задано слишком много / слишком мало параметров» в клиентской среде.

6. Это решение .net VB

7. Невозможно установить любое программное обеспечение на клиентских сайтах, но можно локально

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

9. В коде практически нет комментариев. Нет документации об архитектуре. Нет документации о API. Единственное, что у нас есть, это сотни и сотни цепочек электронной почты, которые в некоторой степени объясняют, что происходит. Единственный человек, который знает код, - это те, кто изначально написал его, но, по их словам, они больше не разработчики, поэтому они не так уж сильно вмешиваются.

И прежде чем вы скажете это ... да, я знаю; Я тоже хочу застрелиться. Это не помогает, что есть спагетти-код, сотни предупреждений компилятора и сломанный полиморфизм, которые ДЕЙСТВИТЕЛЬНО должны быть исправлены, но я не имею права голоса в этом.

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

Я знаю, что это звучит как пустяк, и в некоторой степени это так. Но я отчаянно нуждаюсь в вариантах. Есть ли другие методы / инструменты, которые я могу использовать?

Совет Роберта Харви, вероятно, лучший, но поскольку советы по карьере не по теме, я дам ответ, который можно дать:

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

Кажется, вы точно знаете, как все должно работать. Если никто больше не поможет вам (опять же, игнорируя советы по профессии), ваш единственный выбор - начать исправлять эти вещи самостоятельно.

Во-первых, для всего святого, получите это в реальной системе контроля версий. Почти все, кроме Source Safe, который известен как вонючая куча мусора. gitявляется бесплатным и может быть настроен довольно легко. Вы не можете исправить проблемы, связанные с отсутствием контроля версий в прошлом, но, по крайней мере, не допустить продолжения проблемы в будущем.

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

И начните писать тесты, по крайней мере, для новых изменений, которые вы делаете.

Там нет сахарного покрытия: здесь нет ответа, который не требовал бы много работы или не рассматривал это как вопрос карьеры.

1) Отладчик нельзя использовать на сайте клиента ...

Это совершенно нормально.

... или локально

Теперь это проблема.

2) В наших приложениях практически не ведется логирование.

Ведение журнала является производственной отладкой.

Там нет модульных тестов.

О, Боже. Все для общего, хотя.

3) Контроль версий имеет только 1 версию полного решения

Тогда вы не используете контроль версий.

4) Невозможно воспроизвести локально, часто не удается воспроизвести в тестовой среде (высокая вероятность того, что тестирование и производство не совпадают).

Таким образом, только развернутая клиентская среда показывает ошибки.

В этом случае вам потребуется встроенная в код приложения диагностическая регистрация, которая (a) перехватывает и [полностью] записывает [фатальные] ошибки и (b) может «вызываться» по требованию для получения дополнительной непрерывной диагностики, полезной для отслеживание проблем (ы).

5) Существует высокая вероятность того, что версия, используемая клиентом, отличается от версии, безопасной для исходного кода.

Опять же, вы просто не используете контроль версий в ваших интересах.

8) Наше приложение чрезвычайно настраиваемое

Это довольно типично.

Различия, специфичные для сайта, должны управляться с помощью контроля версий «Ветвление».

9) В коде практически нет комментариев.

Опять же, это слишком часто, потому что разработчики пишут «самодокументируемый» код, не так ли?
Или, по крайней мере, код, который они понимают в тот день, когда пишут.

Нет документации об архитектуре.

О, Боже.

Нет документации о API.

О дорогой, о дорогой.

И прежде чем вы скажете это ... да, я знаю; Я тоже хочу застрелиться.

Нет; Вы хотите застрелить людей, которые написали все эти вещи, создали недокументированный, неуправляемый беспорядок, а затем перешли на новые пастбища, оставив за ними недобросовестный беспорядок.

Наиболее распространенные ошибки, с которыми я сталкиваюсь, - это ошибки нулевых ссылок, неправильные приведения и отсутствующие несоответствия функций / сигнатур функций.

Нулевые ссылки и недопустимые приведения являются ошибками во время выполнения; в некоторой степени вы должны ожидать их, и тот факт, что вы их получаете, часто указывает на отсутствие защитного программирования (или избыток оптимизма) со стороны первоначальных авторов.

Несоответствие сигнатуры функции должно привести к поломке сборки ; они должны вызывать «сломанные сборки» и никогда не должны выходить из дома!

Начните с регистрации. Это будет иметь наибольшее влияние. Внедрите каркас логирования в базу кода, например Log4Net или аналогичную. Начните регистрировать, что делает код.

Отладка должна быть возможна локально. Если нет, работайте над получением файлов символов (PDB), чтобы можно было выполнить отладку в сторонних библиотеках, чтобы получить полное представление о возникающих проблемах. Такие инструменты, как WINDBG, могут указать, какие библиотеки являются проблемными в случае сбоя системы. Можно настроить любой сервер на получение дампа памяти в случае сбоя. Это в основном снимок того, что происходило, когда возникла проблема. Можно проверить свалки в местном масштабе, чтобы найти подсказки к тому, что происходило. Если отладка невозможна, работайте над тем, чтобы сделать это возможным. Документируйте шаги, необходимые для отладки. Иногда на сложных системах достаточно много настроек, необходимых для полной отладки.

Отслеживание ошибок ... Если вы не используете один, начните использовать один. Это идет рука об руку с правильной системой контроля версий. По сути, начните отслеживать дефекты и исправления вашего кода. Начните строить историю системы.

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

Рефакторинг и юнит-тесты. Я собираюсь предположить, что, вероятно, большая часть написанного кода не очень тестируема, поэтому я не стал бы пытаться добавлять тесты для него. Любой новый код, создать тестовый проект и начать писать тесты, как модульные, так и интеграционные. Если модульные тесты не пройдены, завершите сборку. Итак, как вы рефакторинг, должны быть тесты. Одна вещь с тестами состоит в том, что можно написать тест для вызова любого метода и отладки в этом методе без загрузки всего приложения или базы кода. Это полезно для устранения неполадок.

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

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

Во-первых, все вышеперечисленное ... тоже самое.

Немного эвристики:

• Используйте контроль исходного кода на своем компьютере разработчика. Это лучшее, что я сделал. Это не замена контролю версий проекта, который у нас есть. Это инструмент, который дает удивительную свободу для бесстрашного экспериментирования, взлома, одновременной работы над проблемами, а также независимо друг от друга и т. Д. Я лучше использую контроль версий, потому что у меня есть свобода быть смелым, испортить и учиться.
  • В чем разница между Git и Mecurial?
  • Git - это Mcgyver, Mecurial - это Джеймс Бонд
• Если вы добавляете комментарии, расставляйте приоритеты в элементах общедоступного интерфейса, чтобы использовать преимущества intellisense. Делайте это так, как вы расшифровываете во время отладочных приключений.
• Будьте настойчивы с незначительными рефакторингами. Рано или поздно, для данного куска кода, вы получите критическую массу, которая позволяет проводить большие рефакторинги, такие как СУШКА избыточного кода между классами.
• Не смешивайте переформатирование кода и фактические изменения в одних и тех же фиксациях контроля версий.
• ТВЕРДЫЕ принципы
  • Никогда не игнорируйте единственную ответственность. Хорошо, это путь к обещанию объектно-ориентированного; ПО МОЕМУ МНЕНИЮ.
  • Всегда игнорируйте Open / Closed.
  • Мы не говорим здесь новый код.
  • Создание интерфейсов без целенаправленного проектирования затрудняет обслуживание.
• Рефакторинг
  • В этом есть методология . Купить книгу.
  • Рефакторинг: улучшение дизайна существующего кода
• Некоторые файлы кода требуют полного переформатирования, переименования переменных и т. Д., Даже до попытки отладки. Не стесняйтесь использовать меню рефакторинга visual studio без юнит-тестов.
• Единственная документация, которая не может быть неуместна, находится в файлах кода.
• Когда вы получите контроль версий, продумайте план VC. И документируйте это! И придумайте соглашение об именах для веток, тегов, которые будут выделять основные версии программного обеспечения и основные этапы.
• Используйте хорошее оборудование
  • Получить монитор, который поворачивается. Вертикальный - это способ быстрого чтения кода.
  • Внешний накопитель для резервного копирования, клавиатура с нужными клавишами , многофункциональная мышь. По крайней мере, 1 действительно хороший USB-накопитель. У меня даже есть свой стул Германа Миллера .
  • Получите очень хорошее программное обеспечение для сравнения. Я доволен Beyond Compare .
• Практика резиновой Ducky отладки
• Иногда худшее, что может случиться, это то, что они не уволят тебя.

редактировать

Разработка приложений Brownfield в .NET

Попробуйте эту книгу. Первоначальная обложка для прочтения, вероятно, лучше. Эта книга поможет вам подумать об общей картине, возможностях и разработке как стратегических, так и тактических планов атаки.

Торчать

Оставайтесь, скажем, 1,5 года, если можете; достаточно долго, чтобы знать, если вы делаете экспериментальный прогресс. Вы узнаете, получаете ли вы 2 года опыта или 6 месяцев опыта 4 раза.

Будучи «младшим с опытом работы 1/2 года», я обеспокоен тем, что потенциальный работодатель посчитает, что это рано выручит, потому что вы не могли его взломать. Одно дело сказать, что вы выучили z, y, x, взяли несколько имен и надрали себе задницу - но не позволили внести свой вклад в ваши возможности; и другой просто рискует потерять работу, код, управление и т. д. в качестве объяснения.

Я могу быть не в своей тарелке, но моим "лучшим и худшим временем" была моя первая работа, которая оказалась буквально не поддерживаемым кодом. У меня был отличный руководитель (все остальные были из программы по разведению управленческих кадров), который дал мне возможность переписать некоторые ключевые программы. Этот опыт был откровением.

конец Править

Я бы сказал (5) это то, что вам нужно исправить в первую очередь. Если вы не знаете, какой код выполняется в рабочей среде, у вас нет безопасного способа воспроизведения и исправления проблем. Это делает любое другое внесенное вами изменение опасным, поскольку оно может вызвать проблемы, которые вы не можете предвидеть и не можете воспроизвести.

Вам может потребоваться выполнить детективную работу и, возможно, провести реверс-инжиниринг, чтобы выяснить, какая версия кода и какие библиотеки развернуты. (И вам нужна согласованная система сборки и развертывания, чтобы привести весь развернутый код в соответствие с управлением исходным кодом в будущем.)

Возможно, вам придется создать несколько тестовых сред для репликации различных развертываний. (Конечно, самое простое решение - создать новую чистую сборку и развернуть ее везде, но похоже, что это невозможно?)

Только тогда, когда вы знаете точные развернутые версии и имеете соответствующие тестовые среды, вы должны начать пытаться исправить / улучшить код.

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

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

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

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