Методи налагодження коду (ситуація кошмару)


16

Мені часто задають налагодження програми на своїй роботі. Це BI-додаток, яке ми розгортаємо для підприємств, що включає тестове середовище та виробниче середовище. Мені цікаво, чи є додатки / інструменти / методи, які можуть запропонувати люди, виходячи з цих обмежень:

  1. Відладчик не можна використовувати на клієнтському сайті або локально, оскільки це програмне забезпечення залежить від спеціальних додатків сторонніх виробників, для яких у нас немає тестових середовищ. (EDIT: справедливо, в деяких випадках можна налагоджувати локальну програму. Якщо ми не використовуємо нічого, крім основного коду. Значна частина проблемного коду знаходиться в dll, який інкапсулює комунікацію сторонніх сторін: розетки, технологічні труби, мильні дзвінки, користувацька логіка, яка змінює поведінку основного коду. Зазвичай під час впровадження або вдосконалення для клієнта ми б писали новий код у цю область.)

  2. У наших додатках практично не проводиться реєстрація. Одиничних тестів немає.

  3. Контроль версій має лише 1 версію повного рішення (використовуючи джерело безпечного 2005 року). Тому неможливо отримати попередню версію всього рішення, лише окремі файли. (Якщо хтось не знає шляхів цього).

  4. Неможливо відтворити локально, часто не можна відтворити на тестовому середовищі (Висока ймовірність того, що тест і виробництво не є однаковою версією).

  5. Існує велика ймовірність того, що версія, яку використовує клієнт, відрізняється від версії, захищеної від джерела. Це відбувається тому, що оновлюються окремі файли, в які вбудована спеціальна логіка для конкретного клієнта. Часто відбувається те, що відбувається оновлення бінарного файлу, що вимагає змін у кількох інших двійкових файлах, але коли виконується фіксація, ніхто не має цього запису чи знань. Я бачу дещо поширену помилку: "Функція / метод не знайдено" або "Виклик методу має занадто багато / занадто мало параметрів" у клієнтському середовищі.

  6. Це рішення .net VB

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

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

  9. У коді практично немає коментарів. Немає документації про архітектуру. Немає документації про апі. Єдине, що ми маємо - це сотні до сотні ланцюжків електронної пошти, які дещо пояснюють, що відбувається. Код знають лише ті, хто спочатку його написав, але вони вже не розробники, так що вони не так сильно залучаються.

І перш ніж це сказати ... так, я знаю; Я хочу також розстріляти себе. Це не допомагає, що існує код спагетті, сотні попереджень про компілятор та зламаний поліморфізм, що СТРІЛЬНО слід виправити, але я не можу сказати в цьому.

Найпоширеніші різновиди помилок, з якими я стикаюся, - це помилки з нульовою посиланням, недійсні записи і відсутні функції / невідповідність підписів функцій. Іноді мені пощастить, і переглядач подій записує повідомлення про клас, метод та винятки. Це не найкорисніше, але все-таки щось є. Найгіршими є помилки, які не мають сліду, кроків повторної роботи, окрім скріншоту, і є загальними повідомленнями про помилки, на зразок згаданих вище. Іноді з’ясувати, чому вони сталися, неможливо, лише молитися про те, що оточення не налаштоване належним чином, і що воно піде пізніше.

Я знаю, що це виходить як трохи зграю, і певною мірою це є. Але я відчайдушно бажаю варіантів. Чи є інші методи / інструменти, якими я можу користуватися?


43
У вас є резюме?
Роберт Харві

5
+1 за "Я теж хочу стріляти". Джерело Safe 2005, ой. Ну, принаймні, варто «зосередитись» на чудовому уроці історії - ви, в основному, мандрівник у часі! Ви дізнаєтесь на уроках десятиліття ретельно розроблених знань про ", тому ми цього більше не робимо". Шляхетник, коник.
BrianH

7
З огляду на вимогу №1, єдиний спосіб бути ефективним при налагодженні цього безладу - бути ясновидцем. Серйозно кажучи, немає жодної чарівної кулі, яка збирається зробити це чим завгодно, крім марення. У чомусь це має зняти з вас певний тиск, оскільки налагодження - це обов'язково справа удачі. Або ваше керівництво збирається замовити вам щастя? Очевидно, що це не є стійким, тому вам слід шукати інші можливості.
Чарльз Е. Грант

14
Ось деякі фактичні поради щодо кар’єри: ​​Проведіть занадто довго в будинку, в якому є жахливі практики інженерії програмного забезпечення, і вас, швидше за все, звинуватить керівництво в тому, що він поганий розробник у проблемах, які неминуче виникають. Я був там, і я впевнений, що і в інших. У самому, найкращому випадку це призводить до поганих звичок розвитку.
Gort Robot

2
як я керую цими ситуаціями: якщо мені не платять вище за ринок, я шукаю щось ще зробити.
Кевін Клайн

Відповіді:


22

Поради Роберта Харві, ймовірно, найкращі, але оскільки профорієнтація є поза темою, я дам відповідь:

Ви знаходитесь на дні дуже крутої гори, вкритої мішанками та грязями та дратівливими гірськими козами. Немає легкого шляху вгору. Якщо ви хочете дістатися до вершини, вам доведеться змусити один раз просунути один надзвичайно болісний крок.

Здається, ви точно знаєте, як все має працювати. Якщо ніхто інший вам не допоможе, то (знову ж таки, ігноруючи поради щодо кар’єри), ваш єдиний вибір - почати виправляти ці речі самостійно.

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

Далі загляньте в журнал. Знайдіть або в гіршому випадку напишіть систему реєстрації та почніть використовувати її. Використовуйте той, який можна використовувати і на клієнтських сайтах, тож коли справи йдуть збоку, у вас є що-небудь щось.

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

Цього цукрового покриття немає: тут немає відповіді, яка б не передбачала великої роботи або трактувала це як питання кар'єри.


Повірте, я не хотів би нічого іншого, як додати твердження, охорону та ведення журналів, ймовірно, також переписати рівень даних (я пишу валідатор конфігурації для діагностики типових проблем із конфігурацією). На жаль, це не до мене. Я можу зробити запит, щоб щось було проштовхнуто у безпечний джерело, але типова відповідь - «ваші наміри хороші, але це не те, на чому ми повинні зосередитися». На жаль, я лише молодший із стажем 1/2 років. Я на деякий час піднімусь на цю гору.
Igneous01

9
@ Igneous01 Чесно кажучи, спробуйте знайти іншу гору, щоб піднятися. Умови роботи в інших місцях можуть бути не ідеальними, але, мабуть, принаймні більшість значно кращі за те, що ви переживаєте. Якщо ваші воротарі відхилять ваші вдосконалення з "це не те, на що ми повинні зосередитися", це їх рішення, і вони отримають результати тієї невдалої політики (вони вже втрачають тонни грошей через втрачений час розвитку) . Питання в тому, чи хочете ви дотримуватися їх, поки вони не зробляться?
cmaster - відновити моніку

6
І майте на увазі, що коли погана політика провалюється, всі учасники виглядають погано, навіть ті, хто не погодився.
Gort the Robot

1
Так, почніть вести журнал та відстежувати. Почніть також документувати та додавати коментарі. Потроху, це все складеться. Крім того, ви кажете, що вам пощастило все-таки мати деякі оригінальні кодери в компанії, якщо не команда. Натисніть на управління, щоб отримати доступ до них Якщо це можливо, переконайте їх у тому, що вони краще підготують деякі документи, ніж постійно звертаються з питаннями.
Мауг каже, що повернемо Моніку

4
@ Igneous01: Біжи, не ходи. Це місце хворіє і зробить вас хворими.
Відновіть Моніку - М. Шредер

8

1) Налагоджувач не можна використовувати на сайті клієнта ...

Це абсолютно нормально.

... або локально

Тепер це проблема.

2) У наших додатках практично не робиться журналів.

Ведення журналів є це налагодження виробництва.

Одиничних тестів немає.

О Боже. Хоча все спільне.

3) Управління версіями має лише 1 версію повного рішення

Тоді ви не використовуєте контроль версій.

4) Неможливо відтворити локально, часто не можна відтворити на тестовому середовищі (Висока ймовірність того, що випробування та виробництво не є однаковою версією).

Тож лише розгорнуте, клієнтське середовище показує помилки.

У такому випадку вам потрібен діагностичний журнал, вбудований у код програми, який (a) захоплює та [повністю] записує [фатальні] помилки та (b) може бути "набраний" на вимогу для створення додаткової, безперервної діагностики, корисної для відстеження проблеми.

5) Існує велика ймовірність того, що версія, яку використовує клієнт, відрізняється від версії, захищеної від джерела.

Знову ж таки, ви просто не використовуєте контроль версій на свою користь.

8) Наш додаток надзвичайно настроюється

Це досить типово.

Розбіжності, пов’язані з сайтом, слід керувати за допомогою "Розгалуження" управління версією.

9) У коді практично немає коментарів.

Знову ж таки, це занадто часто, тому що розробники пишуть код «самодокументування», чи не так?
Або, принаймні, код, який вони розуміють в день, коли вони це пишуть.

Немає документації про архітектуру.

О Боже.

Немає документації про апі.

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

І перш ніж це сказати ... так, я знаю; Я хочу також розстріляти себе.

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

Найпоширеніші різновиди помилок, з якими я стикаюся, - це помилки з нульовою посиланням, недійсні записи і відсутні функції / невідповідність підписів функцій.

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

Невідповідність підпису функції повинна спричинити зламану збірку ; вони повинні спричиняти "зламані конструкції" і ніколи не повинні робити це з дверей!


2
"Завжди кодуйте так, ніби людина, яка закінчує зберігати ваш код, - це жорстокий психопат, який знає, де ви живете"
PerryC

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

1
"Жодна документація про архітектуру" зазвичай означає "немає архітектури" ...
gnasher729

The site-specific differences should be managed through Version Control "Branching".- Я не думаю, що це найкращий спосіб продовжити. Використання файлів конфігурації та перемикань функцій, здається, є більш поширеним і простіше пояснити.
шістдесят футів

5

Почніть з ведення журналу. Це матиме найбільший вплив. Внесіть основу журналу в базу коду, як Log4Net або подібне. Почніть вести журнал, що робить код.

Налагодження має бути можливим локально. Якщо ні, працюйте над тим, щоб отримати файли символів (PDB), щоб ви могли налагоджувати в сторонніх dll, щоб отримати повне уявлення про проблеми, які виникають. Такі інструменти, як WINDBG, можуть вказувати, які DLL є проблематичними, якщо система виходить з ладу. Можна налаштувати будь-який сервер, щоб прийняти дамп пам'яті, коли відбувається збій. Це в основному огляд того, що відбувалося, коли проблема виникала. Можна оглянути місцеві звалища, щоб знайти підказки до того, що відбувається. Якщо налагодження неможливе, працюйте над тим, щоб зробити це можливим. Документуйте кроки, необхідні для налагодження. Іноді на складних системах існує досить багато налаштувань, необхідних для повного налагодження.

Відстеження помилок ... Якщо ви не використовуєте його, почніть використовувати його. Це йде рука об руку з належною системою управління версіями. По суті, почніть відстежувати дефекти та переглядати код. Почніть будувати історію системи.

Проведіть аналіз статичного коду. Інвестуйте в такий інструмент, як ReSharper. Це швидко вкаже на всі можливі виключення з нульовими посиланнями та інші погані практики кодування. Це може допомогти отримати код у кращій формі за допомогою декількох клацань і автоматизувати стомлюючі елементи, такі як форматування коду, назви змінних тощо. Виміряйте свій код і дізнайтеся, де є гарячі місця для рефакторингу за допомогою метрики коду.

Тести на рефактор і блок. Я припускаю, що, ймовірно, більшість написаних кодів не дуже перевіряються, тому я б не намагався додавати тести для цього. Будь-який новий код, створіть тестовий проект і починайте писати тести, як одиничні, так і інтеграційні. Якщо тести блоку не вдалося, не вдалося зібрати. Отже, як ви рефактор, повинні бути тести. Одне з тестів полягає в тому, що можна написати тест для виклику будь-якого методу і налагодити цей метод, не завантажуючи всю програму або базу коду. Це корисно для вирішення проблем.

Задокументуйте будь-які племінні знання за потребою. Код повинен бути самодокументованим, тому коментарі настільки рідкі, але в багатьох системах є "незвичайні" способи вчинити, вказуйте їх у кодуючому WIKI або іншому типі неформального сховища. Також слід розглянути можливість створення стандартів та практик кодування. Дотримуйтесь цих стандартів за допомогою набору інструментів, таких як Resharper. Оскільки більша частина коду, ймовірно, не відповідає жодним стандартам та вказівкам, застосовуйте стандарти щодо нового написаного коду.

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


4

По-перше, все вищезазначене ... дітто.

Деякі евристики:

  • Використовуйте керування джерелами на своєму комп'ютері розвитку. Це найкраще, що я зробив. Це не є заміною контролю версій проекту, який у нас є. Це інструмент, який дає дивовижну свободу безстрашно експериментувати, рубати, працювати з проблемами одночасно, але самостійно і т. Д. Я краще використовувати контроль версій, оскільки маю свободу бути сміливим, викручуватися та вчитися.
  • Наскільки ви додаєте коментарі, надайте пріоритет елементам загальнодоступного інтерфейсу, щоб скористатися інтелігенцією. Робіть це, як ви розшифруєте під час ваших пригод налагодження.
  • Будьте наполегливі при незначних змінах. Рано чи пізно за певну частину коду ви дістанетесь до критичної маси, яка дає змогу виконувати великі рефактори, такі як ПІДВИЩЕННЯ зайвого коду в усіх класах.
  • Не змішуйте переформатування коду та фактичні зміни в одній і тій же версії контролю версій.
  • Тверді принципи
    • Ніколи не ігноруйте єдиної відповідальності. Молодці, це шлях до обіцянки, орієнтованої на об'єкт; ІМХО.
    • Завжди ігноруйте відкрите / закрите.
    • Ми не говоримо тут про новий код.
    • Створення інтерфейсів без цілеспрямованого дизайну перешкоджає технічному обслуговуванню.
  • Рефакторинг
  • Деякі файли коду потребують повного переформатування, перейменування змінних тощо, перш ніж навіть намагатися налагоджувати. Не соромтеся використовувати меню рефактора візуальної студії без тестових одиниць.
  • Єдина документація, яку неможливо змінити - це файли коду.
  • Коли ви отримаєте контроль над версіями, дайте задуматися плану VC. І документуйте це! І придумайте конвенцію про іменування гілок, теги, які висвітлюють основні версії програмного забезпечення та основні етапи.
  • Використовуйте хороше обладнання
    • Отримайте монітор, який крутиться. Вертикаль - це спосіб швидкого читання коду.
    • Зовнішній привід для резервного копіювання, клавіатура з потрібним видом клавіш , багатофункціональна миша. Принаймні 1 дійсно хороший USB-накопичувач. У мене навіть є власне крісло Германа Міллера .
    • Отримайте дуже хороше програмне забезпечення для порівняння. Я задоволений «Більше порівняння» .
  • Практикуйте налагодження гумових дуків
  • Іноді найгірше, що може статися, це те, що вони не обстрілюють тебе.

Редагувати

Розробка додатків Brownfield у .NET

Спробуйте цю книгу. Первісна обкладинка для прочитаного тексту, мабуть, найкраща. Ця книга допоможе роздумувати про широку картину, можливості та розробляти як стратегічні, так і тактичні плани нападу.

Стирчить його

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

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

Я, можливо, не базуюсь на цьому, але моїм "кращим часом і найгіршим часом" було моє перше завдання, яке виявилося буквально нездійсненним кодом. У мене був чудовий керівник (всі решта були з управлінської племінної програми), який дав мені можливість переписати деякі ключові програми. Цей досвід був одкровенням.

завершити Редагувати


+1 для Не змішуйте переформатування коду та фактичні зміни в одній і тій же версії контрольних версій. - чудова порада
kiwiron

0

Я б сказав (5) - це те, що вам потрібно виправити спочатку. Якщо ви не знаєте, який код працює у виробництві, у вас немає безпечного способу відтворення та усунення проблем. Це робить будь-які інші зміни, які ви вводите, небезпечними, оскільки це може спричинити проблеми, які ви не можете передбачити і не зможете відтворити.

Можливо, вам доведеться виконати деяку детективну роботу і, можливо, зворотну інженерію, щоб з'ясувати, яка версія (-ів) коду та які бібліотеки розгорнута. (І вам потрібна послідовна система складання та розгортання для приведення всього розгорнутого коду у відповідність з подальшим управлінням джерелом.)

Можливо, вам доведеться створити кілька тестових середовищ, щоб повторити різні розгортання. (Звичайно, найпростіший виправлення - створити нову чисту збірку та послідовно розгортати її скрізь, але здається, що це неможливо?)

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

Наступним вашим пріоритетом має стати консолідація до єдиної бази коду, яку можна розгорнути всюди. Здається, у вас розгорнуті різні версії коду через налаштування? Ви повинні консолідуватись до однієї версії, а потім використовувати перемикачі конфігурації для користувацької логіки.

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

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


0

Ігноруючи проблеми, які виникли у вашій команді, здається, що першим, хто звернеться, є налагодження коду, що відповідає виробництву. В іншому випадку ви можете переслідувати помилку, яка вже була виправлена ​​в коді, який ви маєте у своєму "Контролі джерела". Оскільки це .NET, ви можете легко "декомпілювати" виробничі бінарні файли, щоб порівняти код з тим, що у вас є. Це непросте завдання, але якщо вам це вдасться, це вагомий аргумент для кращого інструменту управління джерелом, який може тегувати випущені версії.


Коли ви маєте на увазі декомпіляцію, ви маєте на увазі використання чогось типу IDA Pro для перегляду машинного коду? Я, мабуть, був би єдиним, хто його використовував тоді, тому що тут ніхто не знає складання (і я знаю самі основи).
Igneous01

Ну, оскільки це .NET, бінарні файли не є машинним кодом, вони знаходяться в CIL ( en.wikipedia.org/wiki/Common_Intermediate_Language ). Це може бути досить легко і точно перетворено назад в код c # або VB, особливо якщо він не був затуманений. Ви можете спробувати, наприклад, з ILSpy ( ilspy.net ), але, ймовірно, ви можете використовувати інші інструменти.
20c
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.