W złożonych bazach kodu najtrudniejszą rzeczą, o której myślę, jest złożona interakcja efektów ubocznych. Mogę mówić tylko osobiście, biorąc pod uwagę sposób działania mojego mózgu. Efekty uboczne i uporczywe stany oraz mutowanie danych wejściowych i tak dalej zmuszają mnie do myślenia o tym, „kiedy” i „gdzie” zdarzają się przyczyny prawidłowości, a nie tylko „co” dzieje się w każdej funkcji.
Nie mogę się skupić na „czym”. Po dokładnym przetestowaniu funkcji, która powoduje skutki uboczne, nie mogę stwierdzić, że spowoduje to zwiększenie niezawodności w całym kodzie przy jej użyciu, ponieważ osoby dzwoniące mogą nadal nadużywać, wywołując ją w niewłaściwym czasie, z niewłaściwego wątku, w niewłaściwym zamówienie. Tymczasem funkcja, która nie powoduje żadnych skutków ubocznych i po prostu zwraca nowy wynik na podstawie danych wejściowych (bez dotykania danych wejściowych), jest prawie niemożliwa do niewłaściwego użycia w ten sposób.
Ale myślę, że jestem typem pragmatycznym, a przynajmniej staram się być, i nie sądzę, że musimy koniecznie wyeliminować wszystkie skutki uboczne do jak najmniejszego minimum, aby uzasadnić poprawność naszego kodu (przynajmniej Bardzo trudno byłoby mi to zrobić w takich językach jak C). Bardzo trudno jest mi uzasadnić poprawność, gdy mamy kombinację złożonych przepływów kontrolnych i skutków ubocznych.
Skomplikowane przepływy kontroli do mnie to te, które mają charakter podobny do grafu, często rekurencyjne lub rekurencyjne (kolejki zdarzeń, np. Które nie wywołują bezpośrednio zdarzeń rekurencyjnych, ale mają charakter „rekurencyjny”), być może robią rzeczy w trakcie przemierzania rzeczywistej połączonej struktury grafu lub przetwarzania niejednorodnej kolejki zdarzeń, która zawiera eklektyczną mieszaninę zdarzeń do przetworzenia, prowadząc nas do wszelkiego rodzaju różnych części bazy kodu i wywołując różne skutki uboczne. Jeśli spróbujesz narysować wszystkie miejsca, w których ostatecznie znajdziesz się w kodzie, będzie to przypominało złożony wykres i potencjalnie z węzłami na wykresie, których nigdy się nie spodziewałbyś, byłyby tam w danym momencie, biorąc pod uwagę, że wszystkie one są wszystkie powodując skutki uboczne,
Języki funkcjonalne mogą mieć niezwykle złożone i rekurencyjne przepływy kontroli, ale wynik jest tak łatwy do zrozumienia pod względem poprawności, ponieważ nie występują przy tym różnego rodzaju eklektyczne skutki uboczne. Dopiero gdy złożone przepływy kontrolne napotykają eklektyczne skutki uboczne, uznaję to za bóle głowy, aby spróbować zrozumieć całość tego, co się dzieje i czy zawsze zrobi to dobrze.
Kiedy więc mam takie przypadki, często bardzo trudno mi, jeśli nie niemożliwie, czuć się bardzo pewnie co do poprawności takiego kodu, nie mówiąc już o bardzo pewności, że mogę wprowadzić zmiany w takim kodzie bez potknięcia się o coś nieoczekiwanego. Dla mnie rozwiązaniem jest albo uproszczenie przepływu kontroli, albo zminimalizowanie / ujednolicenie efektów ubocznych (przez ujednolicenie, mam na myśli, jak powodowanie tylko jednego rodzaju efektu ubocznego do wielu rzeczy podczas określonej fazy w systemie, a nie dwóch lub trzech lub jednego tuzin). Potrzebuję jednej z tych dwóch rzeczy, aby mój prosty mózg mógł mieć pewność co do poprawności istniejącego kodu i poprawności wprowadzanych przeze mnie zmian. Łatwo jest mieć pewność co do poprawności kodu wprowadzającego efekty uboczne, jeśli efekty uboczne są jednolite i proste wraz z przepływem kontrolnym, tak jak:
for each pixel in an image:
make it red
Łatwo jest uzasadnić poprawność takiego kodu, ale głównie dlatego, że skutki uboczne są tak jednolite, a kontrola jest tak prosta. Ale powiedzmy, że mieliśmy taki kod:
for each vertex to remove in a mesh:
start removing vertex from connected edges():
start removing connected edges from connected faces():
rebuild connected faces excluding edges to remove():
if face has less than 3 edges:
remove face
remove edge
remove vertex
Jest to absurdalnie uproszczony pseudokod, który zazwyczaj wymaga znacznie większej liczby funkcji i zagnieżdżonych pętli oraz znacznie więcej rzeczy, które musiałyby trwać (aktualizacja wielu map tekstur, masy kości, stanów selekcji itp.), Ale nawet pseudokod tak utrudnia powód poprawności z powodu interakcji złożonego, podobnego do grafu przepływu kontroli i trwających efektów ubocznych. Tak więc jedną strategią upraszczającą jest odroczenie przetwarzania i skupienie się na jednym rodzaju efektów ubocznych na raz:
for each vertex to remove:
mark connected edges
for each marked edge:
mark connected faces
for each marked face:
remove marked edges from face
if num_edges < 3:
remove face
for each marked edge:
remove edge
for each vertex to remove:
remove vertex
... coś w tym celu jako jedna iteracja uproszczenia. Oznacza to, że wielokrotnie przepuszczamy dane, co z pewnością wiąże się z kosztami obliczeniowymi, ale często okazuje się, że łatwiej jest wielowątkowić taki wynikowy kod, teraz, gdy efekty uboczne i przepływy kontrolne nabrały tej jednolitej i prostszej natury. Ponadto każdą pętlę można uczynić bardziej przyjazną dla pamięci podręcznej niż przechodzenie przez podłączony wykres i wywoływanie efektów ubocznych w miarę upływu czasu (np. Użyj równoległego zestawu bitów, aby zaznaczyć, co należy przejść, abyśmy mogli następnie wykonać odroczone przejścia w posortowanej kolejności sekwencyjnej używając masek bitowych i FFS). Ale co najważniejsze, uważam drugą wersję za o wiele łatwiejszą do uzasadnienia pod względem poprawności, a także zmiany bez powodowania błędów. Po to aby'
W końcu potrzebujemy efektów ubocznych, w przeciwnym razie mielibyśmy po prostu funkcje, które wysyłają dane bez celu. Często musimy nagrać coś do pliku, wyświetlić coś na ekranie, przesłać dane przez gniazdo, coś w tym rodzaju, a wszystkie te rzeczy są efektami ubocznymi. Ale możemy zdecydowanie zmniejszyć liczbę zbędnych efektów ubocznych, które się utrzymują, a także zmniejszyć liczbę efektów ubocznych, które występują, gdy przepływy kontrolne są bardzo skomplikowane, i myślę, że znacznie łatwiej byłoby uniknąć błędów, gdybyśmy tak zrobili.