Czy istnieje paradygmat programowania, który promuje uczynienie zależności niezwykle oczywistymi dla innych programistów?

26

Pracuję w hurtowni danych, która pozyskuje wiele systemów za pośrednictwem wielu strumieni i warstw z zależnościami przypominającymi labirynt łączącymi różne artefakty. Prawie każdego dnia spotykam się z takimi sytuacjami: uruchamiam coś, to nie działa, przeglądam mnóstwo kodu, ale godziny później zdaję sobie sprawę, że udało mi się konceptualizować mapę procesu niewielkiej części tego, co teraz wiem później tego dnia jest wymagane, więc pytam kogoś, a oni mówią mi, że ten drugi strumień musi być najpierw uruchomiony i że jeśli sprawdzę tutaj (wskazując na pozornie dowolną część ogromnego stosu innych zakodowanych zależności), to bym miał widzieć to. To niezwykle frustrujące.

Gdybym był w stanie zasugerować zespołowi, że być może dobrym pomysłem byłoby uczynienie więcej, aby uczynić zależności między obiektami bardziej widocznymi i oczywistymi, zamiast osadzać je głęboko w rekurencyjnych poziomach kodu, a nawet w danych, które musi być obecny, ponieważ wypełnia go inny strumień, być może odwołując się do dobrze znanego, wypróbowanego i przetestowanego paradygmatu oprogramowania - wtedy mogę uprościć swoją pracę, a wszyscy inni są o wiele prostsi.

Trudno mi wyjaśnić mojemu zespołowi korzyści z tego. Zwykle akceptują rzeczy takimi, jakimi są, i nie „myślą za dużo”, widząc korzyści płynące z możliwości konceptualizacji całego systemu w nowy sposób - tak naprawdę nie widzą tego, jeśli można modelować ogromny system sprawniej, dzięki temu jest mniej prawdopodobne, że napotkasz niewydolność pamięci, zatrzymywanie strumienia unikatowych ograniczeń i duplikatów kluczy, bzdurnych danych, ponieważ znacznie łatwiej jest zaprojektować je zgodnie z pierwotną wizją, a później nie napotkasz tych wszystkich problemów, które doświadczamy teraz, co, jak wiem, jest niezwykłe z wcześniejszych prac, ale wydaje się, że są one uważane za nieuniknione.

Czy ktoś wie o paradygmacie oprogramowania, który podkreśla zależności, a także promuje wspólny model koncepcyjny systemu w celu zapewnienia długoterminowego przestrzegania ideału? W tej chwili mamy ogromny bałagan, a rozwiązaniem każdego sprintu wydaje się być „po prostu dodaj tę rzecz tutaj i tu i tutaj”, a ja jestem jedynym, który martwi się, że sprawy naprawdę zaczynają się rozpadać.

Christs_Chin
źródło
2
Czy możesz wyjaśnić, jakie to są „podobne do labiryntów zależności łączące różne artefakty”? Czy budują zależności, które można rozwiązać za pomocą narzędzia do budowania, takiego jak Maven? Czy są to zależności wejściowe, gdzie jeden z tych artefaktów zależy od pewnych danych wejściowych, które nie są oczywiste ani jasne? Czy są to kluczowe zależności między tabelami bazy danych?
FrustratedWithFormsDesigner
System to PLSQL, uniksowy bash, OWB itp., Więc istnieje wiele rodzajów zależności. Czasami dane są wymagane w określonym formacie, w określonym miejscu, w określonym czasie, przez określony moduł, ale nie jest to wcale oczywiste z kodu i można je rozpoznać tylko na dwa sposoby: przechodząc przez górę kodu, być może dni, aby dowiedzieć się, że niektóre dane zawierały dwukropek w części systemu, o której istnieniu nawet nie wiedziałeś, że jest przywoływany, ponieważ został on pochowany w 10 warstwach rekurencyjnie nazywanego kodu, lub pytając kogoś, wszystkie za każdym razem. Nie promuje niezależności.
Christs_Chin
4
Dosłownie wszyscy
Miles Rout
3
Mała styczna: Ponieważ Haskell jest leniwy, podczas pisania kodu nie określasz kolejności operacji. Podajesz tylko zależności. Funkcja C zależy od wyników funkcji A i B. Więc A i B muszą być uruchomione przed C, ale może działać równie dobrze, jeśli A jest uruchamiane jako pierwsze lub jeśli B jest uruchamiane jako pierwsze. Pomyślałem, że to interesujące.
GlenPeterson
1
Jest książka o nazwie Wzory projektowe (książka jest do bani, ale większość tego, co mówi, jest dobra, z wyjątkiem trochę singletonu). Zawiera kilka sekcji dotyczących zarządzania zależnościami.
ctrl-alt-delor

Odpowiedzi:

19

Wykrywalność

Jego brak nęka wiele organizacji. Gdzie jest to narzędzie, które Fred ponownie zbudował? Oczywiście w repozytorium Git. Gdzie?

Wzorem oprogramowania, który przychodzi na myśl, jest Model-View-ViewModel. Dla niewtajemniczonych ten wzór jest całkowitą tajemnicą. Wyjaśniłem to mojej żonie jako „pięć widżetów unoszących się nad stołem i rozmawiających ze sobą za pośrednictwem jakiejś tajemniczej siły”. Zrozumieć wzór i rozumiesz oprogramowanie.

Wiele systemów nie udokumentowało swojej architektury, ponieważ zakładają, że jest to oczywiste lub naturalnie wyłania się z kodu. Nie jest i nie jest. O ile nie używasz dobrze zdefiniowanej architektury, nowi ludzie się zgubią. Jeśli nie jest to udokumentowane (lub dobrze znane), nowe osoby zgubią się. A weterani też się zgubią, gdy będą od kilku miesięcy nieobecni w kodzie.

Obowiązkiem zespołu jest opracowanie rozsądnej architektury organizacyjnej i udokumentowanie jej. Dotyczy to np

  • Organizacja folderów
  • Referencje projektu
  • Dokumentacja klasowa (co to jest, co robi, dlaczego istnieje, jak jest używana)
  • Projekt, moduł, montaż, dowolna dokumentacja.

Na zespole spoczywa obowiązek zorganizowania i odkrycia rzeczy, aby zespół nie wymyślał koła na nowo.

Nawiasem mówiąc, koncepcja, że ​​„kod powinien być samodokumentujący” jest tylko częściowo poprawna. Chociaż prawdą jest, że kod powinien być wystarczająco przejrzysty, abyś nie musiał wyjaśniać każdego wiersza kodu komentarzem, relacje między artefaktami, takimi jak klasy, projekty, zespoły, interfejsy i tym podobne są nieoczywiste i nadal muszą być udokumentowane.

Robert Harvey
źródło
3
Jasne, ale ludzie, którzy zbyt mocno opierają się na wzorach projektowych, stanowią część problemu. To oni piszą kod bez dokumentacji, zakładając, że wszyscy zrozumieją, co do cholery zrobili, po prostu patrząc na kod. Ponadto wzorce projektowania oprogramowania nie są architekturą (w przeważającej części).
Robert Harvey
1
Gdzie jest to narzędzie, które Fred ponownie zbudował? Oczywiście w repozytorium Git. Gdzie? - Dokładnie! Wzorzec MVC jest zbyt specyficzny dla rozwoju frontonu (myślę), a wzorce są użyteczne tylko wtedy, gdy wszyscy w zespole je znają, więc to po prostu przenosi problem z zależności, które nie są oczywiste, na oczywiste, JEŚLI każdy wie, jak znaleźć im. Ale problem zakłada, że ​​tak nie jest. Jako taki mam nadzieję, że istnieje coś, co promuje naprawdę oczywisty sposób wyjaśniania zależności, który nie wymaga użycia innych wyuczonych ram koncepcyjnych.
Christs_Chin
7
Nazywa się to „dokumentacją”. Poza tym potrzebujesz rozsądnych ram zależności, które wszyscy wspierają. Niestety nie ma szablonu, który można po prostu wrzucić do projektu; struktura organizacyjna oprogramowania jest czymś, co sam tworzy zespół przy pomocy rozsądnej architektury.
Robert Harvey
5
@RobertHarvey: Niedawno usłyszałem: „Piszemy kod, który nie potrzebuje dokumentacji”. Źle. Piszesz kod bez dokumentacji.
gnasher729
3
Kilka dobrych rzeczy tutaj. Uwaga: istnieje różnica między pisaniem kodu, który nie wymaga komentarzy, a pisaniem dokumentacji pomocniczej.
Robbie Dee,
10

Najlepszym sposobem podejścia do tego rodzaju problemów jest stopniowe. Nie denerwuj się i proponuj szerokie, szerokie zmiany architektoniczne. Te nigdy nie zostaną zatwierdzone, a kod nigdy się nie poprawi. Zakłada się, że możesz nawet określić prawidłowe szerokie, szeroko zakrojone zmiany architektoniczne, które należy wprowadzić, co jest mało prawdopodobne.

Co to jest prawdopodobne, że można ustalić mniejszą zmianę, która pomogłaby Ci specyficzny problem po prostu rozwiązać. Może odwracanie pewne zależności, dodając jakąś dokumentację, tworząc interfejs, pisząc skrypt, który ostrzega o brakującym uzależnienia itp Więc proponuję , że zamiast mniejszą zmianę. Co więcej, w zależności od kultury firmy mogą tolerować, a nawet oczekiwać, że wprowadzisz takie ulepszenia w ramach swojego pierwotnego zadania.

Kiedy uczynisz te mniejsze zmiany regularnymi częściami swojej pracy, a na twoim przykładzie zachęcisz innych do zrobienia tego, z czasem naprawdę się sumują. Znacznie bardziej efektywne niż narzekanie na pojedyncze większe zmiany, których nie wolno wprowadzać.

Karl Bielefeldt
źródło
2
Zgadzam się z ideą stopniowych zmian. Problem polega na tym, że bez pewnych zasad organizacyjnych możesz po prostu powodować większy chaos. Rozważ efekt przeniesienia tylko jednego projektu, klasy lub innego artefaktu (w którym zależą inne moduły) w bardziej rozsądne miejsce.
Robert Harvey
1
Świetna sprawa. Moje troski często stają się mniej uciążliwe przez kilka sumiennych dusz, które mają dość dodawania narzędzia / widżetu tu i tam, aby stworzyć porządek z chaosu. Chociaż nie jestem fanem ryz i dokumentacji, dobrze napisana ściągawka lub wypunktowana lista gotch / funkcji może bardzo pomóc.
Robbie Dee,
+1 za proponowanie drobnych zmian, które prawdopodobnie zostaną zatwierdzone. Doświadczyłem tego i pomogło mi stać się kimś o większym wpływie, a potem moje propozycje zyskały większy wpływ.
RawBean
2

Architektura.

Nie ma jednej, konkretnej, uniwersalnej zasady lub praktyki, która rozwiązałaby problemy związane z wykrywalnością i utrzymywalnością, które dotyczyłyby wszystkich aspektów całego oprogramowania. Ale szerokim pojęciem rzeczy, które sprawiają, że projekt jest rozsądny, jest architektura.

Twoja architektura zawiera cały zestaw decyzji dotyczących każdego punktu potencjalnego (lub historycznego) zamieszania - w tym określenie, w jaki sposób decyzje architektoniczne są podejmowane i dokumentowane. Wszystko, co dotyczy procesu programowania, struktury folderów, jakości kodu, wzorców projektowych itp., To wszystko, co może się pojawić w Twojej architekturze, ale żadna z nich nie jest architekturą.

Idealnie, zasady te są ujednolicone przez osobliwość umysłu.

Mały zespół z pewnością może wspólnie tworzyć architekturę. Ale przy różnych opiniach może to szybko doprowadzić do bardzo schizofrenicznej architektury, która nie służy utrzymaniu twojego zdrowia psychicznego. Najprostszym sposobem, aby zapewnić, że twoja architektura, a także wiele TLA i wzorce w nich zawarte, służą sukcesowi zespołu ze szczególnym umysłem, to uczynienie jednego umysłu odpowiedzialnym za nie.

To niekoniecznie wymaga „architekta” do pontyfikatu . I chociaż niektóre zespoły mogą chcieć, aby doświadczona osoba po prostu podejmowała takie decyzje, najważniejsze jest to, że ktoś musi posiadać architekturę, zwłaszcza gdy zespół rośnie. Ktoś trzyma rękę na pulsie zespołu, moderuje dyskusje architektoniczne, dokumentuje decyzje, monitoruje decyzje i kontynuuje prace nad przestrzeganiem architektury i jej etosu.

Nie jestem wielkim fanem żadnej osoby podejmującej wszystkie decyzje; ale, identyfikacji „architekt” lub „właściciel technicznej produktu”, który jest odpowiedzialny za moderowanie dyskusji architektonicznych i dokumentowania decyzji zwalcza większe zło: Dyfuzja odpowiedzialności, która prowadzi do żadnego dostrzegalnego architektury.

svidgen
źródło
Masz absolutną rację, identyfikując podział odpowiedzialności jako odpowiedzialny za brak dostrzegalnej architektury. Dopiero niedawno podjęto decyzje o naprawieniu tego problemu. Zawsze myślę, że dobrym rozwiązaniem byłoby stworzenie całego systemu rozproszonego za pomocą innego systemu oprogramowania, który działa jak swego rodzaju uprząż, w którym decydujesz, co wchodzi do systemu, ale decyduje, gdzie, zgodnie ze sposobem, w jaki program go programuje.
Miałbyś
Myślę, że twoim celem w tej odpowiedzi jest najlepszy sposób na walkę / zapobieganie temu, o czym mówi OP. Dotyczy to nawet dziedziczenia bałaganu, jaki ma PO.
GWR
1

Witamy w inżynierii oprogramowania (w obu aspektach);) To dobre pytanie, ale tak naprawdę nie ma łatwych odpowiedzi, jak jestem pewien. Jest to naprawdę przypadek ewoluowania w kierunku lepszych praktyk w czasie, szkolenia ludzi do większej umiejętności (z definicji większość ludzi w branży ma przeciętne kompetencje) ...

Inżynieria oprogramowania jako dyscyplina cierpi z powodu budowania go w pierwszej kolejności i projektowania mentalności „na bieżąco”, częściowo z konieczności, a częściowo z konieczności. Jest to po prostu natura bestii. I z czasem hacki są budowane na hakach, ponieważ wyżej wspomniani koderzy szybko wdrażają funkcjonalne rozwiązania, które często zaspokajają krótkoterminowe potrzeby często kosztem wprowadzenia długu technicznego.

Paradygmat, którego potrzebujesz, to w zasadzie zdobywanie lepszych ludzi, szkolenie ludzi, których dobrze znasz, i podkreślanie znaczenia poświęcania czasu na planowanie i architekturę. Nie można łatwo być tak „zwinnym” podczas pracy z układem monolitycznym. Wprowadzenie nawet niewielkich zmian może wymagać znacznego planowania. Wprowadzenie doskonałego procesu dokumentacji na wysokim poziomie pomoże również kluczowym osobom szybciej opanować kod.

Pomysły, na których możesz się skupić, to (z czasem, stopniowo) izolowanie i refaktoryzacja kluczowych części systemu w sposób, który czyni je bardziej modułowymi i oddzielonymi, czytelnymi i łatwymi do utrzymania. Sztuczka polega na tym, że jest to zgodne z istniejącymi wymaganiami biznesowymi, dzięki czemu redukcję długu technicznego można osiągnąć jednocześnie z widoczną wartością biznesową. Tak więc rozwiązaniem jest po części doskonalenie praktyk i umiejętności, a po części próba przejścia w kierunku długoterminowego myślenia architektonicznego, jak już mogę powiedzieć.

Zauważ, że odpowiedziałem na to pytanie z perspektywy metodologii tworzenia oprogramowania, a nie z perspektywy techniki kodowania, ponieważ tak naprawdę jest to problem znacznie większy niż szczegóły kodowania, a nawet styl architektoniczny. To naprawdę pytanie, jak planujesz zmiany.

Brad Thomas
źródło
6
Słyszę, co mówisz, ale twoja odpowiedź jest ostatecznie niezadowalająca i, szczerze mówiąc, trochę obraźliwa. To większy problem niż po prostu zatrudnianie lepszych ludzi; nawet w małym sklepie, w którym pracuję, zmagamy się z tym i myślę, że to coś więcej niż problem ludzi; Myślę, że ma pewne specyficzne techniczne problemy.
Robert Harvey
1
Zgadzam się, że istnieją aspekty techniczne, ale myślę, że są one stosunkowo niewielkie w porównaniu z naciskiem na silniejszą metodologię planowania zmian. Nie uważam, żeby chodziło o wzorce projektowe, a także o kulturową zmianę w kierunku większego planowania i analiz, wcześniejszego planowania i analizy oraz lepszego planowania i analizy.
Brad Thomas
W porządku, opublikuję własną odpowiedź jako porównanie. Nie sądzę, że to ma coś wspólnego z wzorców oprogramowania.
Robert Harvey
Brad, dzięki za odpowiedź. Twoja odpowiedź jest doceniana, ponieważ wiem, że nie jestem sam, wiedząc o tym problemie. Tak po prostu wygląda w moim zespole. Zgadzam się również z Robertem Harveyem, ponieważ problem ten jest powszechny i ​​nie chcę rezygnować z przekonania, że ​​istnieje rozwiązanie, zarówno w nowym oprogramowaniu, jak i nowej praktyce pracy.
Christs_Chin
2
Dokładnie z mojego doświadczenia: członkowie zespołu muszą zrozumieć, co robią. Widzę ludzi mieszających MVVM i MVC, innych używających kontrolek WPF w sposób, który był normalny w Windows Forms (a raczej: VB6), ludzi programujących w C # bez podstawowej wiedzy o orientacji obiektowej ... Naucz ich. Naucz ich ponownie. Być sfrustrowanym. Naucz ich jeszcze raz ... Często myślę o poddaniu się. I ucząc ich ponownie ...
Bernhard Hiller
1

Podoba mi się pomysł @ RobertHarvey na konwencje i myślę, że one pomagają. Podoba mi się również pomysł @ KarlBielefeldt, aby „dokumentować w ruchu” i wiem, że jest to niezbędne, ponieważ jest to jedyny sposób na utrzymanie aktualności dokumentacji. Ale myślę, że nadrzędnym pomysłem jest to, że dokumentowanie, jak znaleźć wszystkie fragmenty kodu, zbudować je i wdrożyć, jest ważne!

Niedawno wysłałem e-mailem do znaczącego projektu open source, który miał pewną konfigurację XML, która generowała kod, który był całkowicie nieudokumentowany. Zapytałem opiekuna: „Gdzie udokumentowano proces generowania kodu XML? Gdzie udokumentowano konfigurację testowej bazy danych?” i powiedział: „To nie jest”. Zasadniczo jest to projekt jednoosobowy, a teraz wiem, dlaczego.

Słuchaj, jeśli jesteś tą osobą i czytasz to, naprawdę doceniam to, co robisz. Praktycznie czczę owoce waszej pracy! Ale jeśli spędziłeś godzinę na dokumentowaniu tego, jak twoja naprawdę twórcza praca jest złożona, może spędzę kilka dni na kodowaniu nowych funkcji, które mogą ci pomóc. W obliczu ceglanego muru „brak dokumentacji nie stanowi problemu”, nawet nie spróbuję.

W firmie brak dokumentacji to ogromna strata czasu i energii. Takie projekty często trafiają do konsultantów, którzy kosztują jeszcze więcej, tylko po to, aby mogli dowiedzieć się podstawowych rzeczy, takich jak „gdzie są wszystkie elementy i jak się do siebie pasują”.

Podsumowując

Potrzebna jest nie tyle technologia czy metodologia, co zmiana kultury; wspólne przekonanie, że dokumentowanie budowy rzeczy i dlaczego jest ważne. Powinien być częścią recenzji kodu, wymaganiem przejścia do produkcji, powiązanym z podwyżkami. Kiedy wszyscy w to wierzą i działają zgodnie z tym, wszystko się zmieni. W przeciwnym razie będzie to jak mój nieudany wkład open source.

GlenPeterson
źródło
2
Podejrzewam, że część problemu kulturowego tkwi w zwinnym przekonaniu, że „jeśli nie jest to część User Story (tzn. Nie ma bezpośredniego wpływu na wartość dla interesariuszy), to nie jest ważne”. Bzdury. Powiązana rozmowa tutaj: Jak sprawnie zaplanować i przydzielić podstawowe zadania infrastrukturalne na początku projektu?
Robert Harvey
@RobertHarvey Tak. Wszyscy w moim zespole są niesamowicie bystrzy i bardzo łatwo się z nimi dogadać. Mistrzowie scrum i menedżerowie projektów mają dobre intencje i kierują się nimi, a praktyki są najbardziej zwinne, w ramach których pracowałem. Ale brakuje dokumentacji, prawdopodobnie z tego samego powodu, który sugerujesz. Ponadto, gdy tworzona jest dokumentacja, wprowadza się kolejną warstwę losowości w zakresie efektywności komunikacyjnej w zdolności osoby do identyfikowania odpowiednich pojęć, a także do ich wyjaśniania, nie mówiąc już o ich podejściu do podjęcia takiego zadania. Zwykle jest to po prostu „Zapytaj kogoś”
Christs_Chin
@GlenPeterson Tak, zgadzam się, że byłoby to pomocne. Ale należy sprecyzować nie tylko, że należy go zbudować, ale także jak i co kwalifikuje się jako dokumentacja. Na przykład jako niedawny przykład ktoś podał listę nowych numerów, które nasz system zidentyfikuje. to jest to! Nie było wzmianki o tym, jak te liczby wchodzą do systemu, gdzie, dlaczego, przez kogo, jak często lub cokolwiek użytecznego, tylko oni robią. W żadnym momencie nie zastanawiałem się, jakie liczby nasz system uzna za istotne. Ale często zastanawiałem się, dokąd wchodzą, dokąd idą i co dzieje się po drodze. To wciąż tajemnica.
Christs_Chin
1
@Christs_Chin Tyle komunikacji opiera się na kontekście. Bez tego kontekstu większość komunikacji jest prawie bez znaczenia. Czuję twój ból. Ale myślę, że trudno jest pisać (po angielsku), aby inni mogli cię zrozumieć. Czasami wczesne specyfikacje systemu mają kontekst, który należy zrozumieć, nawet jeśli są strasznie nieaktualne, kontekst zwykle pomaga.
GlenPeterson
1

Aby odpowiedzieć na postawione pytanie (zamiast udzielać porad dotyczących konkretnej sytuacji):

Paradygmat programowania znany jako czystym programowaniem funkcjonalnym wymaga, aby wszystko, co wpływa na wynik funkcji, musi być określone w parametrach wejściowych. Nie ma ukrytych zależności, zmiennych globalnych ani innych tajemniczych sił działających niewidocznie w całej bazie kodu. Nie ma „musisz zrobić to najpierw” sprzężenie czasowe.

JacquesB
źródło
0

Każda hurtownia danych jest inna, ale możesz zrobić wiele, aby ułatwić sobie życie.

Na początek każdy wiersz w bazie danych miał kolumnę DATE_ADDED i DATA_UPDATED , abyśmy mogli zobaczyć, kiedy został dodany do bazy danych i kiedy został zmieniony. Mieliśmy również kolumnę SOURCE_CODE , abyśmy mogli śledzić, gdzie każdy kawałek danych wchodzi do systemu.

Następnie mieliśmy wspólne narzędzia, które działały we wszystkich naszych hurtowniach danych, takie jak sortowania, dopasowania tabel, krajalnice i dicery itp.

Indywidualny kod był ograniczony do absolutnego minimum i nawet wtedy musiał potwierdzać różne style kodowania i raportowania.

Zakładam, że znasz już ETL pakiety . Istnieje wiele funkcji, które otrzymujesz za darmo w tych dniach, które nie były obecne, kiedy byłem w grze jakieś dziesięć lat temu.

Możesz także spojrzeć na rzutniki danych w celu zaprezentowania bardziej przyjaznej, odkażonej wersji hurtowni danych. Oczywiście nie jest to srebrna kula, ale może pomóc w rozwiązaniu niektórych problemów zamiast konieczności odbudowywania / poprawiania hurtowni danych.

Robbie Dee
źródło
dzięki za odpowiedź. Tak, używamy wszystkich tych pól, ale tak naprawdę pomagają tylko w identyfikacji pojedynczego wiersza, a nie w zależnościach między strumieniami, warstwami i systemami. Masz rację co do pakietów ETL - byliśmy w trakcie aktualizacji do znanego narzędzia ETL z tego, które wychodziło z obsługi, ale zamiast tego wróciło do PLSQL. Kodowanie jest w porządku, ale dla łatwości konserwacji i zrozumienia całego systemu z poziomu kodu jest to absolutnie straszne.
Christs_Chin
1
Idealne jest to, że możesz śledzić dane od końca do końca za pomocą tabel pomostowych lub płaskich plików, ale jeśli tego nie masz, masz chodzący kod.
Robbie Dee,
0

Nie wiem, jak istotne jest to w twoim przypadku, istnieją pewne strategie, które sprawiają, że zależności są bardziej widoczne i ogólne utrzymanie kodu

  • Unikaj zmiennych globalnych, zamiast tego użyj parametrów. Dotyczy to również połączeń międzyjęzykowych.
  • Unikaj zmieniania / mutowania wartości zmiennych tak bardzo, jak to możliwe. Stwórz nową zmienną i użyj, jeśli chcesz zmienić wartość, jeśli to możliwe.
  • Zrób kod modułowy. Jeśli nie można opisać, co właściwie robi (a nie jak) część w prostym zdaniu, podziel ją na moduły spełniające ten warunek.
  • Nazwij swoje części kodu poprawnie. Gdy potrafisz opisać w prosty sposób, co robi część kodu, terminy te stają się nazwą tej części. W ten sposób kod staje się samodokumentujący poprzez nazwy modułów / klas / funkcji / procedur / metod itp.
  • Przetestuj swój kod. Sprawdź, czy jednostki w twoim kodzie uzasadniają ich nazwy, omówione w poprzednim punkcie.
  • Rejestruj zdarzenia w kodzie. Przynajmniej utrzymuj dwa poziomy dziennika. Pierwszy jest zawsze włączony (nawet w produkcji) i rejestruje tylko zdarzenia krytyczne. Za pomocą drugiego możesz rejestrować w zasadzie wszystko, ale można je włączyć lub wyłączyć.
  • Znajdź i użyj odpowiednich narzędzi do przeglądania, utrzymywania i rozwijania swojej bazy kodu. Nawet prosta opcja „Wyszukaj wszystko” w Visual Studio Code znacznie ułatwiła mi życie w niektórych przypadkach.
Gulszan
źródło