Чи важливі навички налагодження, щоб стати хорошим програмістом?

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

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

Так, це дуже важливо

Щодо цього конкретного кандидата, можливо, він / він не був достатньо знайомий з кодовою базою x для його налагодження.

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

Якщо ви не можете налагоджувати, ви майже не програміст, не кажучи вже про хороший.

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

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

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

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

Головне правило найму - у будь-якому сумніві скажіть ні.

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

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

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

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

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

Наприклад, подумайте про дивну помилку, коли програма Java працює чудово на консолі в інтерактивному режимі, але не вдається, коли ви намагаєтесь використовувати трубу Unix для того ж входу. Якщо ви стикалися з цією проблемою раніше, ви можете переконатися, що вона new Scanner(System.in)викликається лише один раз; помилка полягає в тому, що він споживає буфер при трубопроводі, але, очевидно, не в інтерактивному режимі. Я б очікував, що старший програміст швидше виявить цю помилку. Можливо, тому, що вони відчували це раніше, або тому, що у них були інші проблеми з буферизацією в минулому.

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

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

Як зауваження, є способи покращити налагодження, не маючи спочатку 10-річного досвіду. Я рекомендую книгу Андреса Зеллера Чому програми провалюються: Посібник із систематичної налагодження як спосіб вивчити наукові принципи та краще зрозуміти, як відтворювати, знаходити та виправляти невдачі.

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

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

Найміть те, що вам потрібно, а не якийсь ідеал того, яким повинен бути програміст.

Поряд з іншими якостями, чи повинен програміст мати хороші навички налагодження?

Так.

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

я повинен вважати його за роботу?

Можливо, це залежить.

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

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

Чи повинен програміст мати хороші навички налагодження?

Так. З цього приводу я б попросив вас вважати методологію інтерв'ю (тобто стиль вікторини / тесту) менш ідеальним (добре, хибно), оскільки багато людей знаходять код на папері дивним, незнайомим досвідом.

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

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

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

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

Мені не подобається концепція бути поставленою на місце в інтерв'ю. Якщо кандидат нервує (а хто ні), він / вона може намалювати порожні кружки як програміст, він, можливо, зможе регулярно впоратися з такими проблемами. Тоді, якби це було добре відоме інтерв'ю або проблема тестування компа-науки, кандидат може знати результат по черзі, але не мати можливості продумувати свій шлях через нову проблему. Крім того, якщо кандидат не знайомий з мовою, йому доведеться боротися. Багато помилок важко, тому що хороший програміст знає, що він мав набрати, а його мозок приймає ярлики під час читання коду. Я не можу знайти C-стиль використання = where == повинен був використовуватися інспекцією, тому що я знаю, який був намір, і мій мозок буде приймати ярлик для розбору, читаючи його.

Гарна частина програмування вирішення проблем, а щоб вирішити проблему, ви повинні знати основну проблему, а не лише симптоми чи невідповідності. Налагодження - це мистецтво визначення основної проблеми.

• визначити основну проблему
• краще візуалізувати потік

і багато іншого.

Я додам трохи більше до ситуації, вказуючи на помилку, і подивіться, яку реакцію має людина. Вони занадто драматичні щодо "D'oh! Я ідіот, який був такий німий ..." типу, надто апатичний у таборі "Так, який би чувак", або там активно слухали те, що було не в чомусь із вибаченням чи зауваженням, що вони позначають, що вони зіпсували щось, що мали б вирішити? Просто над чим подумати в майбутніх ситуаціях.

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

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

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

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

У будь-якій роботі є 4 - 5 ключових навичок, і програмування не відрізняється. На професійному рівні ви повинні бути хорошими у всіх ключових фундаментальних навичках. Якщо у вас є 4 з 5, вони все одно будуть стримувати вас.

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

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

У мене такий стиль кодування, який вимагає кримінальної налагодження. Коли я закінчую з 3 рядками коду, запускаю його і тестую, часто виводячи пару змінних. У тих випадках, коли я отримав небажаний результат чи поведінку, я вкладаю багато кодів у свій код - замість налагодження. Я використовую справжній налагоджувач дуже рідко. Дивно, але правда.

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

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

1) Вони можуть викрити вразливість для населення, що призведе до втрати доходу, бізнесу та репутації для розробників та постачальників.

2) Черв'яки шукають уразливі системи, які вони можуть експлуатувати і, таким чином, копіювати себе на ці сервери. напр. У січні 2003 року Slammer Worm скористався вразливістю у MS SQL Server.

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

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