Kod korekty na przyszłość

Tam, gdzie pracuję, programiści zawsze mówią mi, że „dodałem to na wszelki wypadek” lub „Myślę, że to dobry pomysł, ponieważ prawdopodobnie będą chcieli tego kiedyś”. Myślę, że to wspaniale, że są proaktywni, starając się przewidywać przyszłe zmiany, ale nie mogę przestać myśleć, że jest to niepotrzebne i ryzykuje pisanie kodu, który może nigdy nie być potrzebny, a zatem nieproduktywny (uważam również, że niektórzy programiści chcą po prostu wypróbować coś nowy ze względu na to). Czy argumenty na potwierdzenie w przyszłości są nieważne, jeśli po prostu piszesz dobry, czysty zorganizowany kod?

Po pierwsze, pewne rzeczy wymagają wyjaśnienia:

• Korekta przyszłości nie polega na dodawaniu elementów.
• Korekta przyszłości zapewnia łatwe dodawanie kodu / funkcji bez przerywania istniejącej funkcjonalności.

Oznacza to, że pisanie kodu „na przyszłość”, zapewnia, że ​​kod jest napisany luźno, wystarczająco abstrakcyjnie, ale także kod, który nie całkowicie ukrywa poziomy abstrakcji, więc zawsze istnieje możliwość przejścia na niższe poziomy abstrakcji Jeśli to konieczne.

Pisanie kodu w przyszłości jest sztuką samą w sobie i jest ściśle powiązane z praktykami SOLID dotyczącymi wersjonowania komponentów, oddzielania problemów, nakładania warstw i abstrakcyjności funkcjonalności. Sprawdzanie przyszłości nie ma nic wspólnego z dodawaniem funkcji z wyprzedzeniem, ale z upewnieniem się, że możesz dodawać funkcje w przyszłości w sposób niezniszczalny , poprzez dobry projekt istniejącego kodu / bibliotek.

Mój 2c

Nie pisz kodu, który nie będzie używany przez długi czas. Będzie bezużyteczny, ponieważ najprawdopodobniej nie będzie odpowiadał potrzebom w tym czasie (których z definicji jeszcze nie znasz).

Spraw, aby kod był odporny na nieoczekiwane sytuacje problemowe, umożliwiając płynne odzyskiwanie lub szybkie uruchamianie awaryjne, ale nie pisz kodu dla możliwych przyszłych zastosowań.

Dobrym sposobem na zapewnienie tego jest wykorzystanie projektowania i rozwoju opartego na testach. Przypadki testowe pochodzą ze specyfikacji i przypadków użycia. Cały kod musi przejść test. Niepotrzebny kod nie powinien być zapisywany. W ten sposób łatwo jest ustalić, czy jest to potrzebne, czy nie.

Ważne jest, aby zdawać sobie sprawę z tego, że tworzenie kodu na przyszłość i pisanie kodu na wypadek, gdyby był potrzebny w przyszłości, to dwie bardzo różne rzeczy. Ten pierwszy jest kluczowy dla dobrej aplikacji, mniejszy zwykle nie jest dobrą praktyką kodowania.

• Dla mnie korekta kodu w przyszłości polega na pisaniu go w taki sposób, aby mógł wchodzić w interakcje z rozwijającymi się technologiami. Obejmuje to modularyzację kodu, dzięki czemu każda część aplikacji może współdziałać niezależnie od języka i technologii aplikacji jako całości. Dobrym przykładem może być użycie XML lub JSON do przesyłania danych między różnymi częściami aplikacji. Bez względu na rozwój technologii, jest bardzo prawdopodobne, że zawsze będzie w stanie czytać XML i JSON.

• Podobnie do powyższego, ujawnienie części aplikacji za pomocą SOAP lub REST API osiąga podobną rzecz. Niezależnie od ewolucji technologii niekoniecznie będziesz musiał ponownie pisać każdą część aplikacji, ponieważ nowe technologie nadal będą mogły komunikować się ze starymi.

• Jeśli chodzi o pisanie kodu, to w razie potrzeby uważam, że jest to bardzo niebezpieczne, ponieważ kod może mieć niewiele testów lub nie mieć go wcale.

Tak więc, z całą pewnością, przygotuj kod na przyszłość (NASA nadal wysyła statki kosmiczne za pomocą Fortranu), ale nie pisz kodu „na wszelki wypadek”.

Pomyśl, ile razy włączyłeś kawałek kodu w środowisku produkcyjnym i pomyślałem: „Dzięki Bogu, że napisałem to 2 lata temu!”.

Kod powinien być łatwo modyfikowalny / rozszerzalny. Nie dodawaj kodu, który nie jest natychmiast potrzebny, ponieważ daje to bardzo fałszywe poczucie bezpieczeństwa i marnuje zasoby programistyczne / testowe w świecie zmieniających się wymagań.

Wiele innych odpowiedzi dotyczy większych problemów projektowych lub jest raczej abstrakcyjnych. Jeśli myślisz w kategoriach tego, co wydarzy się w przyszłości, możesz zdefiniować kilka jasnych technik, które pomogą przygotować kod na przyszłość .

Przede wszystkim myśl, że w przyszłości ktoś spróbuje dodać funkcję do kodu lub spróbuje ponownie użyć kodu w innym miejscu. Mogą także próbować naprawić funkcję w kodzie. Oczywiście posiadanie dobrego, czystego kodu jest wymaganym punktem wyjścia, ale są też pewne specyficzne techniki, które można wykonać.

Programowanie defensywne : Sprawdzaj dane wejściowe poza tym, czego aktualnie potrzebuje Twoja aplikacja. Ilekroć wywołujesz interfejsy API, upewnij się, że ich dane wejściowe są czymś, czego można się spodziewać. W przyszłości ludzie będą mieszać nowe wersje kodu, więc zakres błędów i zwrotów API zmieni się z obecnego.

Elliminate Undefined Behavior : Wiele kodu ma zachowanie, które ewoluuje znikąd. Pewne kombinacje danych wejściowych prowadzą do pewnych wyników, których nikt tak naprawdę nie zamierzał, ale tak się dzieje. Teraz nieuchronnie ktoś będzie polegał na tym zachowaniu, ale nikt nie będzie o nim wiedział, ponieważ nie jest zdefiniowany. Każdy, kto spróbuje zmienić zachowanie w przyszłości, niechcący coś zepsuje. Skorzystaj teraz z kontroli bezpieczeństwa i spróbuj usunąć / zablokować wszystkie niezdefiniowane zastosowania kodu.

Zautomatyzowany pakiet testowy : Jestem pewien, że możesz znaleźć tomy napisane o potrzebie testów jednostkowych. Jednak w odniesieniu do sprawdzania poprawności w przyszłości jest to krytyczny punkt pozwalający komuś na zmianę kodu. Refaktoryzacja jest niezbędna do utrzymania czystego kodu, ale jeśli brakuje dobrego zestawu testów, nie można bezpiecznie refaktoryzować.

Izolacja i segregacja : Hermetyzacja i odpowiednia modularyzacja to dobra zasada projektowania, ale musisz wyjść poza to. Często okazuje się, że musisz użyć biblioteki, interfejsu API lub produktu, co może mieć wątpliwą przyszłość. Może z powodu problemów z jakością, problemów z licencjonowaniem lub dalszego rozwoju przez autorów. W takich przypadkach należy poświęcić więcej czasu na umieszczenie warstwy między tobą a tym kodem. Zmniejsz API do tego, czego potrzebujesz, aby sprzęgło było bardzo niskie, aby umożliwić łatwiejszą wymianę w przyszłości.

Dobry, czysty, dobrze zorganizowany kod jest przyszłościowy w tym sensie, że ułatwia prawidłowe wprowadzanie zmian i dodatków.

„Dowód na przyszłość” w najlepszym wypadku oznacza „luźno sprzężoną konstrukcję”. W 80% przypadków ludzie mają na myśli „elastyczny”, kiedy mówią „na przyszłość”. Czasami mówią, że to brzmi nieźle. Ale przynajmniej dostarczają coś na czas, co działa.

„Dowód na przyszłość” w najgorszym wypadku jest bez znaczenia. W 20% przypadków jest to pretekst do marnowania czasu na badanie alternatywnych technologii zamiast po prostu dostarczania czegoś. Nic nie dostarczają (lub to, co dostarczają, jest zbyt skomplikowane, aby poradzić sobie z danym problemem).

Istnieją dwa przypadki brzegowe.

1. Niezawodny przewidywanie. Właściwie można dokładnie przewidzieć przyszłość. W takim przypadku zastosuj tę zaawansowaną prognozę, aby w przyszłości sprawdzić kod. Lepiej, zastosuj niezawodną prognozę, aby przewidzieć trendy rynkowe i wycofać się wcześniej i przestać kodować.

2. Jednym z nich jest „napędzanie” przyszłości. Oznacza to, że w przyszłości ma być przygotowana nowa technologia, która będzie wymagać przepisania rzeczy dostarczanej właśnie teraz. To dziwne, że najpierw nie stosuje się tej fajnej przyszłości.

   Musimy dostarczyć projekt „A”, wiedząc, że projekt „B” doprowadzi do natychmiastowego przepisania „A”. Tylko w tym przypadku możemy być w stanie udowodnić w przyszłości „A”.

YAGNI = Nie będziesz go potrzebował .

Twoje instynkty są prawidłowe: ich kod jest zbędny, nakłada koszty utrzymania i testowania oraz marnuje czas na rzeczy, które nie mają konkretnej wartości biznesowej.

Zobacz także: Pozłacanie .

Ignorując tytuł pytania i pozostawiając główny punkt na temat „wkładania rzeczy, ponieważ ktoś może chcieć tego dnia” ...

Odpowiedź brzmi nie. Nigdy. Nie pisz kodu, którego dzisiaj nie potrzebujesz. Dlatego:

1. Program jest teraz bardziej skomplikowany niż powinien.
2. Możesz nigdy nie potrzebować tej funkcji, więc zmarnowałeś swój czas.
3. Nie wiesz, jakie będą wymagania dla tej funkcji, jeśli ktoś kiedykolwiek poprosi o nią w przyszłości. Musisz więc to rozgryźć i zmodyfikować.

Myślę, że najważniejszy jest pierwszy punkt. Jeśli kiedykolwiek pracowałeś z systemem, który jest wypełniony ogólnym kodem dla różnych klientów, lub pełen funkcji rozszerzających się o rzeczy, których nie potrzebujesz, to wiesz, ile dodatkowego czasu i wysiłku wymaga utrzymanie lub rozszerzenie funkcjonalności z powodu że. Unikaj więc za wszelką cenę.