Czy własność kodu to zapach kodu?

To jest coś, o czym myślałem, odkąd przeczytałem tę odpowiedź w kontrowersyjnym wątku opinii programistycznych :

Twoim zadaniem jest wyeliminowanie się z pracy.

Kiedy piszesz oprogramowanie dla swojego pracodawcy, każde tworzone przez ciebie oprogramowanie musi być napisane w taki sposób, aby każdy programista mógł je pobrać i zrozumieć przy minimalnym wysiłku. Jest dobrze zaprojektowany, jasno i konsekwentnie napisany, sformatowany czysto, udokumentowany tam, gdzie powinien, buduje się codziennie zgodnie z oczekiwaniami, sprawdza w repozytorium i odpowiednio wersjonuje.

Jeśli zostaniesz potrącony przez autobus , zwolniony, zwolniony lub odejść z pracy, Twój pracodawca powinien mieć możliwość natychmiastowego zastąpienia cię, a następny facet może wkroczyć na twoją rolę, odebrać kod i wstać biegnie w ciągu tygodnia. Jeśli on lub ona nie może tego zrobić, to poniosłeś porażkę.

Co ciekawe, przekonałem się, że osiągnięcie tego celu uczyniło mnie bardziej wartościowym dla moich pracodawców. Im bardziej staram się być jednorazowy, tym bardziej cenię się dla nich.

Zostało to trochę omówione w innych kwestiach, takich jak to , ale chciałem to jeszcze raz poruszyć, aby omówić z bardziej punktu widzenia punkt widzenia „ to zapach kodu !! ” - który tak naprawdę nie został omówiony jeszcze głęboko.

Od dziesięciu lat jestem profesjonalnym programistą. Miałem jedno zadanie, w którym kod był wystarczająco dobrze napisany, aby mógł go stosunkowo szybko odebrać każdy przyzwoity nowy programista, ale w większości przypadków w branży wydaje się, że bardzo wysoki poziom własności (zarówno indywidualnej, jak i zespołowej) to norma. Wydaje się, że w większości baz kodu brakuje dokumentacji, procesu i „otwartości”, które pozwoliłyby nowemu deweloperowi na ich wybranie i szybkie rozpoczęcie pracy z nimi. Wydaje się, że zawsze istnieje wiele niepisanych małych sztuczek i hacków, o których wiedziałby tylko ktoś, kto bardzo dobrze zna bazę kodu („jest jej właścicielem”).

Oczywiście oczywistym problemem jest to: co się stanie, jeśli dana osoba odejdzie lub „zostanie potrącona przez autobus”? Lub na poziomie zespołu: co się stanie, jeśli cała drużyna zostanie zatruta pokarmem, gdy pójdzie na lunch zespołowy i wszyscy umrą? Czy byłbyś w stanie zastąpić zespół świeżym zestawem nowych losowych programistów stosunkowo bezboleśnie? - W kilku poprzednich pracach nie wyobrażam sobie, żeby tak się działo. Systemy były tak pełne sztuczek i hacków, że „musisz tylko wiedzieć ”, że każdy zatrudniony przez ciebie nowy zespół zajmie znacznie więcej czasu niż zyskowny cykl biznesowy (np. Nowe stabilne wydania), aby wszystko zaczęło się od nowa. Krótko mówiąc, nie byłbym zaskoczony, gdyby produkt musiał zostać porzucony.

Oczywiście utrata całego zespołu naraz byłaby bardzo rzadka. Ale wydaje mi się, że w tym wszystkim jest coś bardziej subtelnego i złowrogiego - co skłoniło mnie do założenia tego wątku, ponieważ nie widziałem go wcześniej omawianego w tych kategoriach. Zasadniczo: Myślę, że wysoka potrzeba posiadania kodu jest bardzo często wskaźnikiem długu technicznego . Jeśli w systemie brakuje procesu, komunikacji, dobrego projektu, wielu małych sztuczek i hacków, które „musisz tylko wiedzieć” itp. - zwykle oznacza to, że system zaczyna coraz bardziej pogłębiać techniczne zadłużenie.

Ale rzecz w tym, że własność kodu jest często przedstawiana jako swego rodzaju „lojalność” wobec projektu i firmy, jako pozytywna forma „wzięcia odpowiedzialności” za twoją pracę - więc niepopularne jest całkowite potępienie tego. Ale jednocześnie techniczna strona długu równania często oznacza, że ​​baza kodu staje się coraz mniej otwarta i trudniejsza w obsłudze. A zwłaszcza, gdy ludzie idą dalej i nowi programiści muszą zająć ich miejsce, koszty długu technicznego (tj. Utrzymania) zaczynają rosnąć.

W pewnym sensie uważam, że byłoby dobrze dla naszego zawodu, gdyby wysoki poziom potrzeby posiadania kodu był jawnie postrzegany jako zapach pracy (w popularnej wyobraźni programisty). Zamiast postrzegać to jako „wzięcie odpowiedzialności i dumy” z pracy, należy ją raczej postrzegać jako „okopywanie się i tworzenie sztucznego bezpieczeństwa pracy poprzez zadłużenie techniczne”.

I myślę, że test (eksperyment myślowy) powinien zasadniczo polegać na tym, że osoba (a właściwie cały zespół) miałaby zniknąć jutro z powierzchni Ziemi. Czy byłoby to gigantyczne - być może śmiertelne - uszkodzenie projektu, czy też bylibyśmy w stanie sprowadzić nowych ludzi, zachęcić ich do przeczytania dokumentacji i plików pomocy i bawić się kodem przez kilka dni - a potem wrócić biznes za kilka tygodni (i powrót do pełnej produktywności za około miesiąc)?

Myślę, że musimy zrobić różnicę między własnością kodu:

• z punktu widzenia odpowiedzialności
• z punktu widzenia stylu kodu / hacków itp.

Pierwszego należy zachęcać. Jeśli nikt nie jest odpowiedzialny za kod niskiej jakości i błędy, mogą się zdarzyć złe rzeczy . Nie oznacza to, że błąd związany z twoim kodem musi być każdorazowo przypisany: jeśli kod jest poprawnie napisany, każdy może naprawić błąd w dowolnej części kodu. Ale jeśli nie masz żadnych opinii na temat błędów, które robisz, będziesz powtarzał te same błędy .

Własność kodu może bardzo pomóc zarówno menedżerom, jak i programistom, zwłaszcza deweloperom. Gdybym wiedział, że 80% błędów w produkcie było w moim kodzie, gdy byliśmy trzema programistami pracującymi nad projektem, i że 75% tych błędów było związanych z SQL Injection, następnym razem bardziej ostrożnie piszę kod i włóż dodatkowy wysiłek, aby poprawnie napisać zapytania do bazy danych.

Drugi (własność kodu ze stylu kodu / włamań itp.) Jest w większości złą rzeczą. Co wnosi do produktu? Nie podnosi to jakości produktu, ale zmniejsza jednorodność kodu źródłowego i utrudnia jego utrzymanie w ostatnim czasie .

W przypadku wielu dużych projektów ludzie nie zostają do końca życia, pracując nad tym samym fragmentem kodu. I tutaj nawet nie mówię o okropnych rzeczach, takich jak uderzenie dewelopera przez autobus: nie sądzę, aby posiadanie kodu było pierwszym problemem w tym przypadku. Ale zdarza się wiele drobnych myśli: ludzie migrują z rozwoju do zarządzania lub innych zadań, albo wybierają inne projekty, pracują nad innymi rzeczami lub zaczynają używać innego języka (jeśli w projekcie używanych jest kilka języków) itp.

Fragment kodu projektu może być również ponownie wykorzystany w innym projekcie, a programista pracujący nad tym innym projektem chciałby zmodyfikować niektóre części kodu, aby dopasować je do nowych potrzeb, bez proszenia o radę byłego autora kodu.

Czy to zapach kodu? To zależy od tego, co rozumiesz przez zapach kodu. Dla mnie chodzi o ogólną spójność projektu i prawidłowe zarządzanie . W dobrym projekcie

• egzekwowane są wytyczne dotyczące stylu kodu, aby ułatwić późniejsze zrozumienie kodu,
• bardziej doświadczeni programiści nie naruszają zasady KISS, pomagając w ten sposób w zrozumieniu kodu źródłowego później przez mniej doświadczonych kolegów.

Podsumowując, własność kodu musi być śledzona przez kontrolę wersji, ale nie możesz być w stanie powiedzieć, że fragment kodu jest napisany przez ciebie lub kogoś w zespole .

Najpierw musimy zdefiniować, co to jest „własność kodu”.

Gdy fragment (część) kodu jest na wczesnym etapie opracowywania, często konieczne jest wyznaczenie jednej lub dwóch osób jako „właścicieli”, ponieważ:

• Na początku nie ma jasnej specyfikacji ani wymagań, a deweloperzy będą musieli zbierać informacje we własnym zakresie. Między zbiorem a dokumentacją tych ustaleń istnieje przerwa czasowa.
• Unikaj sprzecznych edycji, gdy fragment kodu jest aktywnie modyfikowany.
• „Właściciel (właściciele)” to osoba (osoby), które mogą zgłosić postęp rozwoju funkcji.

Zwykle dla każdego zadania istnieje jeden właściciel. W przypadku programowania w parze możliwe są podwójni właściciele. Nie byłoby to praktyczne bez wąsko wyznaczonej „własności kodu”.

Uwaga:
Proszę zobaczyć @ MainMa w odpowiedzi na inne kwestie w trakcie rozwoju. W takich przypadkach „własność kodu” jest objawem większych problemów, to jest: nieoptymalnego wyboru architektury, niespójności stylu kodowania i ogólnie braku jakości kodu.

Po napisaniu utworu i przyjęciu go do bazy kodu („zrobione”) pojawia się bardziej ogólne pytanie „własność kodu”.

• Kto jest ekspertem, który może odpowiedzieć na wszystkie pytania dotyczące tego fragmentu kodu / tej części funkcjonalności?
• Czy ta wiedza została przechwycona w materialnych artefaktach, takich jak dokument wymagań, testy jednostkowe, testy akceptacyjne, dzienniki zmian, wiki projektu itp.?

Zawsze będzie część wiedzy na temat domeny (milczące zrozumienie wymagań klientów, problemy z kompatybilnością z tajemnymi systemami itp.), Które trudno sformalizować w pisemne specyfikacje. Dlatego w przypadku katastrofy należy się spodziewać pewnej utraty wiedzy na temat domen.

Wraz z utratą wiedzy o domenie stracisz także ekspertów, którzy potrafią wyjaśnić szczegóły systemu. W tym aspekcie utrata eksperta jest rzeczą powszechnie złą. Wiedza powinna zostać zdobyta wcześniej.

Nie oznacza to, że istnienie „ekspertów” jest złe: uważaj ekspertów za „pamięć podręczną” wiedzy pisanej. Eksperci często potrafią odpowiedzieć na pytania szybciej niż przeglądać i przyswajać wiedzę na piśmie.

Czasami jednak „własność kodu” odnosi się do barier ustanowionych przez aktywnych programistów projektu, aby uniemożliwić osobom postronnym modyfikowanie kodu.

• Kto może wprowadzać zmiany w tym fragmencie kodu?
  • Aby naprawić oczywiste błędy?
  • Aby kod spełniał inne wymagania?
  • Aby całkowicie przepisać kod według własnego uznania?

Istnieją dobre i złe bariery:

• Dobre bariery
  • Wiedza w dziedzinie - jak dobrze rozumiesz wymagania i styl architektury / kodowania
  • Umiejętność programowania i projektowania - czy masz umiejętności poprawiania jakości projektu i kodu
• Złe bariery
  • Nie byłeś w oryginalnym zespole programistów, więc nie możesz wprowadzać zmian.
  • Mile widziane są tylko poprawki błędów. Ulepszenia funkcji nie są mile widziane.

W takim przypadku przywilej edycji kodu źródłowego innego projektu nie powinien opierać się na własności kodu, ale powinien być oparty na zasługach.

Wreszcie, @Graham Lee odpowiedź wskazuje na fragmentację wiedzy i architektury, które jest spowodowane przez departamentalizacja.

W tym przypadku „własność kodu” jest jednym z symptomów podziału na departamenty. Drugim objawem jest „brak zainteresowania projektami innych zespołów”. Jako organizacja menedżerowie będą musieli podjąć kroki w celu zachęcenia do transferu wiedzy i współpracy między zespołami i działami.

Co bardziej podstępne, niektóre firmy (w którym pracowałem) organizują strukturę zarządzania wokół zespołów funkcjonalnych: zarządzasz programistami klientów Windows, ona zarządza zespołem instalatorów, on zarządza programistami backendowymi i tak dalej. Nie tylko prowadzi to do silnej własności kodu, którą opisujesz, ale także zapewnia sposób działania firmy. Zmienia architekturę oprogramowania w bitwę polityczną.

Czy to problem? Dzieje się tak, jeśli architektura jest lub nie jest optymalna. Nie można powiedzieć (na przykład), że instalator działałby lepiej lub byłby tańszy w opracowaniu, gdyby był to tylko przypadek użycia klienta, ponieważ odbiera to kontrolę zespołowi i jego menedżerowi. Podziały między modułami funkcjonalnymi stały się faktami na temat sposobu działania działu inżynierii i zmiana tych faktów wymaga wielu zmian.

[BTW, jeśli powyższa dyskusja nie wyjaśnia, moja odpowiedź na twoje pytanie brzmi „tak”. Własność kodu to zapach kodu, ponieważ może zatrzymać mądrych ludzi z dobrymi pomysłami - lub nawet tylko tych, którzy są dostępni, gdy ich potrzebujesz - pracując nad kodem. Oczywiście kontrolowanie zatrzymujących kapryśne zmiany jest dobrą rzeczą, ale jeśli masz inżyniera, który widzi, jak naprawić błąd i ma czas, aby to zrobić, nie powinieneś blokować tego inżyniera tylko dlatego, że ktoś inny napisał błędny kod. ]

Zajmując się twoim pytaniem z nieco innego punktu widzenia, własność kodu NIE jest zapachem kodu. Zamiast tego jest to zapach zarządzania i pozyskiwania zasobów .

Zastanów się, co oznacza zapach kodu. Jest to metafora, która mówi ci, kiedy patrzysz na swój kod, że coś jest nie w porządku z kodem i / lub projektem oprogramowania, ale problem może nie być tak oczywisty, aby móc wskazać dokładny problem może być, ale prawdopodobnie masz dobry pomysł, niezależnie od tego. W domu, jeśli coś brzydko pachnie, podążaj za nosem, dopóki nie znajdziesz źródła problemu, a następnie coś z tym zrobisz. W ten sam sposób, jeśli w kodzie występuje problem, badasz go i zmieniasz, aż stanie się mniejszym problemem lub, jak niektórzy powiedzą, pięknym lub dobrze wykonanym .

Z drugiej strony własność kodu może stanowić poważny problem. Sugeruje to brak nadzoru i ryzyko, że jeśli właściciel kodu odejdzie, wiedza na temat kodu i konkretnych problemów, które rozwiąże, nie będzie już dostępna dla firmy. Nie ma to nic wspólnego z samym kodem. Zasadniczo sprowadza się to do sytuacji zarządzania ryzykiem w ten sam sposób, który prowadzi nas do przechowywania kopii zapasowych naszych danych, i dotyczy w równym stopniu własności zadań lub własności dokumentów w innych obszarach firmy.

Myślę, że dobrze jest opisywać inne problemy biznesowe jako zapachy , ale z pewnością nie sugerować tego tylko dlatego, że jest zapach , który ma konkretny związek z kodem.

Zdefiniowałem Własność Kodową jako osobistą odpowiedzialność za kod, który piszesz, przy założeniu, że inni będą w nim pracować w przyszłości . Jeśli pomyślisz o tym w ten sposób, mniej prawdopodobne jest, że napiszesz hack, ponieważ a) błędy w tym module mogą zostać prześledzone i b) członkowie zespołu prawdopodobnie mieliby trudności z modyfikacją kodu w przyszłości .

Napisałem na blogu kilka miesięcy temu, w którym argumentowałem, że bez prawa własności do kodu, jak go definiuję, baza kodów często padnie ofiarą Tragedii Gmin .

Zgodnie z twoją definicją własności kodu zgadzam się, że źle jest mieć kod, w którym może pracować tylko autor.