Налагодження: розуміння деталей того, чому працювали певні виправлення? [зачинено]

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

Я б сказав, що важливо зрозуміти кожну деталь про те, чому виникають деякі помилки та чому певні зміни усунули ці помилки, а також серед розробників часто трапляється програма працювати, не знаючи детально про те, чому виправлення працювало!

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

У гіршому випадку ви взагалі нічого не зробили, крім переміщення помилки: я пам’ятаю, що з першого курсу обчислювальної техніки на університеті, коли багато студентів вперше вивчали C та покажчики, помилки вказівників часто перестали проявлятися, коли вони змінили речі випадковим чином, оскільки зміни переставлять структури даних в пам'яті достатньо, щоб змусити помилку вказівника над іншим бітом пам'яті. Очевидно , що не допомогло взагалі .

Але сказавши це, комерційні реалії програмування часто такі, що задоволення клієнта, що виправлена ​​помилка, важливіше, ніж задоволення себе. Я б ніколи не рекомендував вам декларувати щось виправлене, якщо ви не мали уявлення про те, що це спричинило, але якщо ви бачите, що якийсь код був проблематичним, і ви переробили його, навіть якщо ви "не на 100% впевнені", як це спричинило конкретний помилка виявляється, іноді просто потрібно перейти до наступної помилки, перш ніж клієнт занадто голосно кричить про ваш повільний прогрес.

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

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

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

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

Як правило, перед тим, як виправити проблему / помилку, вам слід робити оцінку / аналіз основної причини, щоб визначити, чому проблема виникає та чи можна її повторити. Тоді вам слід прочитати код і зрозуміти, чому саме код викликає помилку. Після того, як ви зрозумієте: тоді ви можете почати розглядати, як вирішити проблему та визначити інші сфери, на які вплинуть ваші зміни. Тут можуть реально допомогти одиничні тести!

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

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

Або серед розробників часто трапляється робота програми, не знаючи деталей про те, чому виправлення працювало?

З цим є щонайменше три великі проблеми:

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

2. Ви не можете знати, що помилка насправді виправлена або просто замаскована вашими змінами, якщо ви не розумієте: а) в чому проблема, і б) як ваша зміна вирішує проблему.

3. Неможливо виправити помилку , і найближчим часом він знову вкусить вас.

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

Інша полягає в тому, що ви працюєте над цією помилкою, і випадкова зміна заставила це працювати, це неприпустимо. Якщо ви не знаєте, що старий код робив неправильно, ви, мабуть, не знаєте, що новий код робить неправильно.

Я насправді не можу придумати належну причину перевірити другий випадок - якщо це критична помилка, то важливо її виправити. Якщо це некритична помилка, принаймні ви можете бути впевнені, що не вводите критичну помилку зі своїм "виправленням".

Або серед розробників часто трапляється робота програми, не знаючи деталей про те, чому виправлення працювало?

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