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)?