Професионална програма
Loading...
Ivaylo.Goranov avatar Ivaylo.Goranov 68 Точки

[Teamwork] - КПК - Свобода на действие при рефакториране?

Здравейте,

Бих искал да попитам каква свобода на действие имаме при рефакториране на предоставения ни код от екипния проект по КПК. Кодът е твърде нечетлив и се чудя дали не би било по-целесъобразно да сменим парчета от кода с написан от нас код, но със същата функционалност. Т.е. при условие, че програмата работи и изхода и поведението й е същото като на оригиналния ни предоставен сорс код, можем ли да променим логиката на изпълнение по наша преценка?
В коментарите към заданието на проекта (Notes) е написано, че можем да променяме външното поведение на приложението, но относно вътрешното не можах да тълкувам по същия начин, затова и задавам въпроса.

Благодаря предварително за отговора.

П.С. Който е писал този код, определено му липсва курс по ООП и КПК. Използва една камара неясни променливи и магически числа, методи вършещи по няколко неща, един клас, в който е цялата логика... Накратко - това е антикод. 

0
C# OOP Advanced
Filkolev avatar Filkolev 4485 Точки
Best Answer

Като цяло правилото при екипните проекти по КПК е да се рефакторира кодът, без да се преписва начисто, от нулата. Оттам нататък свободата е пълна, стига нещо в самото задание да не е забранено, а такива забрани рядко има.

Има един принцип, според който лош код не се рефакторира, а се преписва, така че части от кода спокойно може да ги смените с ваш код. След няколко стъпки от процеса кодът като цяло може да стане неузнаваем, сравнен с оригиналния; единствено трябва да е ясно (примерно от документацията, която ще водите относно внесените промени), че сте работили с този код и сте го подобрили него. Т.е. не е седнал някой от екипа с опит с Windows Forms или писане на игрички да напише покер и после да го представите като подобрена версия на заданието.

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

4