Здравей,

Понеже имаш няколко твои отговора, ще ги засегна всичките в този отговор.

Напълно възможно и нормално е да има случаи, за които програмата ти работи, и други, за които не работи. Даже е напълно възможно да работи в повечето случаи, но да има ситуации, в които не работи. Facebook работи в повечето случаи, но това не означава, че няма бъгове в някои определени ситуации. Затова има 10 теста, не 2 теста. Логиката "как може за 9 да работи, а за 10 да не работи", можеш да го продължиш на "как може за 8 да работи, но не и за 9", "как може за 7 да работи но не и за 8" и така нататък, и накрая ще те доведе до извода, че няма смисъл изобщо от тестове и направо каквото напишем трябва да го броим за вярно и да не се занимаваме :D

"Разгледах кода и не виждам проблем в логиката" - това е проблемът. Код не се дебъгва с разглеждане - аз се занимавам професионално от повече от 5 години вече (и непрофесионално още няколко), и досега случаите, в които съм оправил нещо само с разглеждане, се броят на пръсти.

"Смених арей-а с вектор и ми даде 100 % , въпреки , че и с арей си го смяташе правилно ...." - не. Не го е "смятало правилно", щом за определени входни данни е имало неправилен изход. Смятало го е правилно за входните данни, които ти си ползвал (които най-вероятно са тези в условието). Промяната, която си направил, звучи свързана с размери на масиви и с индекси и излизане извън размерите на съответните масиви (защото във векторът добавяш елементи и той сам си контролира размера, докато на масива трябва ти да определиш размера - така че сигурно е имало грешка в определянето на размера на масива, или поне в достъпването на елементите му).

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

Имаш обаче и доста хубави и полезни за развитието изказвания, от типа на защо и как да подходиш - нека обърнем и на тях внимание.

Като за начало е нормално случай не всичко да ти работи от първото предаване в judge. Има един лаф в програмирането - "Ако една програма не работи вярно от първия път, в нея има грешка. Но ако работи от първия път, значи в нея има много грешки". Това се дължи предимно на факта, че първия път като пишеш решение на задача (особено ако нямаш много опит - макар че и опитът не е гаранция), обикновено мислиш за това как да си изпишеш кода, че да постигнеш някакво решение на очевидната част от задачата. Обаче често не мислиш за особени случаи, или дори за стандартни случаи, които не са описани изрично в условието.

Пример - намери най-голямото число в поредицата от цели числа, примерно за 1 5 3 12 10 отговорът е 12. Пишеш max = 0; пишеш цикъл да прочети числата и всеки път да променя max ако текущото число е по-голямо от него. Изглежда да работи. Пускаш в judge - половината тестове не минават. Защо? Ами половината тестове в judge съдържат в себе си само отрицателни числа и max = 0; винаги е по-голямо от тях. Сега, тук проблемът е очевиден, не само защото е малка програма, но и защото вече си се сблъсквал с това най-вероятно, но илюстрира добре това, което имам предвид. Обикновено първият ти приоритет е да измислиш "някакво" решение и често или се пропускат детайли от условието, или нещо в самото ти решение предразполага технически програмата ти да не работи добре в определени ситуации. Други интересни ситуации за тази задача са: какво става ако има само 1 число, какво става ако числата са подредени в нарастващ ред (значи на всяка стъпка се променя max), какво става ако са подредени в намаляващ ред (max се променя само веднъж, в началото), какво става ако всички числа са еднакви, какво става ако се редуват положителни и отрицателни и т.н. - забележи как всички тези примери по някакъв начин дефинират някакъв клас от поведения на програмата ти. Във всички тези "класове" от поведения трябва да си уверен, че програмата ти работи вярно.

Следващото важно нещо - има горе долу 3 стъпки в оправянето на всеки един бъг в някакъв софтуер. 1. Възпроизвеждане (repro), 2. изолиране и чак накрая самото 3. поправяне (fix).

1. Възпроизваждането (репродуцирането) означава да пресъздадеш същия проблем, който един клиент/потребител ти е докладвал, на твоята машина или в твоята работна среда - тоест да разбереш при какви входни данни/операции се случва този проблем и да си ги имаш заделени някъде, за да можеш много пъти да го възпроизвеждаш при теб, докато се опитваш да го оправиш. За примера това е да въведеш входни данни съдържащи само отрицателни числа.

2. Изолирането е процесът, в който, след като имаш консистентно възпроизвеждане, търсиш точно коя част от кода предизвиква проблемът. Нещото, което е източник на проблемът. В примера с максималното число, първо търсиш в цялата програма дали четеш вярно числата (да), след това дали извеждаш правилно стойността на max (да), след това дали стойността на max се променя на всяка итерация (и тук е не). Това обаче е симптом на проблема - ти търсиш какво води до този проблем. Ако проверката в if-а е грешна, тогава това ти е изолираният проблем - но тя е вярна и затова продължаваш да търсиш, докато не осъзнаваш, че началната стойност на max е по-голяма от всяко отрицателно число. Тоест изолираният проблем ти е началната стойност на max

3. Поправянето е очевидно - изолирания проблемен код сменяш с такъв, който не е уязвим на тази грешка. Понякога има повече от 1 валиден fix за един проблем, а понякога е достатъчно голям, че да не може да се поправи с промяна в изолираното място на проблема, а трябва да се пренапише логиката на програмата (примерно ако езикът не поддържа отрицателни числа трябва напълно да промениш начина на обработка - да речем да четеш числата като положителни, обаче да си пазиш отделно инфо кои от тях са отрицателни и когато правиш сравненията да вземаш предвид тази информация - това е много хипотетичен случай, но за такъв малък пример е трудно да се измисли по-добър случай, в който fix-ът не може да се направи без да се промени програмата). За нашия пример fix-ът е max да се инициализира или с минималната възможна стойност за отрицателни число в езика, или да се инициализира винаги със стойността на първото от числата - и двата варианта биха работили (е, вторият не би работил ако има случай, в който числата са празни, но това може да се провери с един допълнителен if)

Има и 4-та стъпка, в която тестваш с данните за repro, и ако няма repro значи си оправил проблема. Също тестваш и дали останалата логика на програмата ти продължава да работи вярно (тоест дали fix-ът ти не е счупил нещо друго). За тази цел е хубаво да си си подготвил примерни входни и очаквани изходни данни - почваш с дадените в условието и градиш върху тях. Всеки път като оправиш проблем си добавяш данните от repro-то към примерните входове, за да имаш "тестове" за всички ситуации.

Има разбира се и 0-ва стъпка - повечето софтуери не се публикуват без да се изтестват. Дали това ще е пращане в judge или писането на facebook, всеки софтуерен разработчик би следвало да се досети за потенциални проблеми, а не да разчита на потребителите да му докладват проблеми. С judge не знаеш точно какъв е проблемът, на който трябва да направиш repro, така че тази 0-ва стъпка е важна - общо взето трябва след като си написал програмата да се опиташ нарочно да я счупиш. Да се пробваш да въведеш данни, за които ще изведе грешен отговор (в рамките на ограниченията на задачата разбира се, няма смисъл да въвеждаш думи в задачата за max число, ако е казано, че във входните данни няма да има думи). И е хубаво да се опитваш да тестваш по тези "класове от поведения", за които говорих по-рано. Няма много смисъл да пишеш повече от 1-2 теста за всеки "клас" поведение (е, има защото може да си мислиш, че си намерил един клас поведение, обаче да се окаже, че той си има под-класове поведения - но трябва да го балансираш това срещу общото време, което имаш да решиш задачата).

Ако съдим по коментарите ти от по-рано, ти (както и повечето начинаещи) скачаш директно на стъпка 3 - правиш fix без да си направил repro на проблем и без да си изолирал този проблем. Сменил си масива с вектор, aма не знаеш (или поне не изглежда да знаеш) защо това е помогнало - представи си това да беше оправило един тест но да беше счупило още два. Щеше да си доникъде, защото правиш промени без да разбираш проблема и така може да си навлечеш повече проблеми (е, може и да извадиш късмет, но късметът не е нещо, на което се разчита в програмирането). Или пък отиваш директно на стъпка 2 ("Разгледах кода и не виждам проблем в логиката" е точно стъпка 2 без стъпка едно - няма как да не видиш проблем ако имаш данни, за които не работи, ако трябва стъпка по стъпка и с гледане на стойността на всяка променлива, рано или късно ще видиш проблема).

Така че като за начало се старай винаги да следваш стъпките в реда 1, 2, 3. Ако имаш време мисли и за 0-вата стъпка преди да предадеш в judge, макар че е по-ефикасно от гледна точка на време първо да пратиш в judge и да видиш дали няма да изкараш 100%, за да спестиш време от тестване (на изпита това е добър подход, защото бързаш, в истинския живот не съвсем). Ако не, чак тогава почваш стъпка 0, след това 1 и чак след това 2 и 3 след като имаш проблеми за оправяне (и оправяй проблемите един по един, не се опитвай да оправиш две неща едновременно, това най-много да ти навлече повече проблеми - отделно, че понякога един fix за едно нещо се оказва че оправя и друго нещо, и няма смисъл да мислиш повече от едно нещо точно заради това).

Един ден ще имаш достатъчно опит да усещаш проблемите без репро (след като повечето са ти се случвали по стотина пъти), но дотогава най-добре следвай тези стъпки, ако искаш да си уверен, че кодът ти е правилен, както и за да си уверен, че няма непоправим проблем и няма начин да не намериш грешка, ако измислиш правилните входни данни/начални условия.

Надявам се това да помогне.

Поздрави,

Жоро