Помощ/съвет за отборната работа по КПК 2015


1

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

Въпросът ми е как е правилно да се подходи в началото. Интуицията ми подсказва, че е добре да се тества как работи цялото приложение в момента (acceptance Или functional tests - не съм сигурен), да се види дали има някакви бъгове и в последствие като започне рефакторирането да се проверява да не се е объркало нещо на база пъроначалните тестове. За съжаление, се оказва доста трудно за реализиране и не съм сигурен до колко е смислено.

Другият вариант е да се напишат предварително тестове (unit tests) към конкретни класове и методи и отделни функционалности, които вероятно няма да се променят в последствие.

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

Кой от трите подхода да избера, има ли и други? Благодаря предварително!




Отговори



6
За конкретната задача е най-добре първо да се направи кода максимално разбираем. Т.е. да се рефакторира в посока читаемост. Няма как да работите по код, който не разбирате перфектно. Това включва да се избягва повторения на код, добре именувани методи, всеки метод да върши ясно определена задача и т.н. Това трябва да стане преди да сте се впуснали в създаване на абстракции (изнасяне на класове и вкарване на патерни), защото те правят кода по-трудно четим. От там нататък, от време на време може да правите някой ръчен тест да не сте объркали нещо. Според мен ще е много трудно първо да направите тестовете, защото кода ще се променя на фундаментално ниво всеки път, когато добавите някой дизайн патерн или добра идея. Ще променяте интерфейси и т.н. Едва като се позакрепи фундамента, т.е. имате някаква "архитектура", вече е задължително да си направите тестове поне на правия случай, и да ги рънвате редовно, защото така ще си спестите много време.

от neutrino (3376 точки)


3
Не съм специалист, но ми се струва безсмислено създаване на тестове за код, който ще претърпи многократно пренаписване за кратко време. Защото с всяка промяна ще трябва да се променят и тестовете. Когато работният вариант на кода придобие някаква степен на завършеност и установеност, тогава вече по би имало смисъл писането на тестове.

от Curiosity (452 точки)


1

Колега, в условието е казано "If needed, first redesign the program logic to make the code testable." Така, че можеш да започнеш и без unit tests и в последствие като се изчисти картинката да ги добавиш.

Това което ти препоръчвам е да си намериш книгата "Refactoring: Improving the Design of Existing Code" От нея задължително прегледай първа глава да добиеш практическа представа как протича процеса на рефакторирането и после използвай книгата като наръчник, докато рефакторираш с помощта на главите от 5та до 12та.

Ако можете да се събирате често с отбора, ви съветвам да правите и pair programming.




0

Мерси за отговра колега ще се постарая да намеря време и за книгата, вероятно не съм успял да си задам въпроса правилно. Make the code testable на човек, който преди две-три седмици разбра какво е тест, за съжаление е твърде неконкретно. Той реално и така си е testable, мога да напиша тестове, които да тестват функционалността на даденото приложение в този си му вид (някъде в нета прочетох, че се казват functional tests). Другият вариант е на практика да се пренапише решението наново (за да се напишат дребните unit tests, за които учихме), което обезсмисля изходния код според мен. Предполагах, че има някаква скрита цел с този омазан в началото код, освен може би да започнем да си задаваме въпроса кога трябва да започне писането на юнит тестове :), да установим че в случая е тотално безсмислено и да започнем наново като почти не запазим нищо.


от todorm85 (1347 точки)