Прекъсване на зависимостите, когато не можете да правите промени в други файлове?

Правя някаква стелт гъвкава разработка по проект. Водещият програмист вижда модулното тестване, рефакторингът и т.н. като загуба на ресурси и няма начин да го убеди в противното. Неговата философия е „Ако не е счупено, не го поправяй“ и аз разбирам неговата гледна точка. Той работи по проекта повече от десетилетие и познава кода отвътре и отвън. Не искам да обсъждам практиките за развитие.

Аз съм нов в проекта и ми беше възложено да добавя нова функция. Работил съм по наследени проекти преди и съм използвал гъвкави практики за разработка с добър резултат, но тези екипи бяха по-възприемчиви към идеята и не се страхуваха да правят промени в кода.

Казаха ми, че мога да използвам каквато методология за разработка искам, но трябва да огранича промените си само до тези, необходими за добавяне на функцията. Използвам tdd за новите класове, които пиша, но продължавам да се натъквам на пречки, причинени от либералното използване на глобални променливи и голямото свързване в класовете, с които трябва да взаимодействам. Обикновено бих започнал да извличам интерфейси за тези класове и да направя тяхната зависимост от глобалните променливи изрично, като ги инжектирам като аргументи на конструктора или публични свойства.

Мога да твърдя, че промените са необходими, но като се има предвид, че главният герой никога не е трябвало да ги прави, се съмнявам, че той би го видял по моя начин. Какви техники мога да използвам, за да прекъсна тези зависимости, без да разрошвам перата на водещия разработчик?

Постигнах известен напредък, използвайки:

  • Извличане на интерфейс (за новите класове, които създавам)
  • Разширете и заменете своенравните класове с тестови мъничета. (за щастие повечето методи са публични виртуални)

Но тези двамата могат да ме докарат само досега.

Забележка

Част от отговорностите на водещия е да преглежда подадения код. Той вероятно би интерпретирал антикорупционния слой в най-добрия случай като прекомерен и в най-лошия като обида.


person codemuncher    schedule 11.05.2010    source източник
comment
Ще направя това коментар, а не отговор, за да държа огъня. Бих предложил да изгладите автобиографията си и да започнете да държите ухото си на земята за нова позиция. Ще напреднете още повече и ще научите повече в по-приятелска среда. Не казвам да напусна или да направя нещо прибързано, но след 6-12 месеца щях да имам нова работа, ако атмосферата не се подобри.   -  person Jeremy Roberts    schedule 11.05.2010


Отговори (2)


Трябва да създадете антикорупционен слой, където основно поддържате слой между вас и кода на „експерта“, като използвате обвиващи класове. Това ще е цената да се занимаваш с подобни глупости.

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

person Michael Hedgpeth    schedule 11.05.2010
comment
Той никога няма да се съгласи да провери модулните тестове. Те ще съществуват само на моята собствена машина, така че съм свободен да използвам всякакви рамки, от които се нуждая за тестване. За съжаление изборът ми е ограничен от езика, на който е написан проектът. - person codemuncher; 11.05.2010
comment
На какъв език е написан проектът? Това със сигурност ще позволи повече полезни отговори? - person Peter Boughton; 11.05.2010
comment
Написано е в обект паскал. - person codemuncher; 11.05.2010

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

С такъв слой можете да застрашите останалата част от системата, както бихте застрашили външни ресурси.

person Maxem    schedule 11.05.2010