Tym razem trochę o metodologiach programowania. A konkretnie jednej z nich czyli Kopiuj-Wklej, Copy-Paste Development, StackOverlow Development. Wiele nazw, ten sam temat.

 

Każdemu programiście zdarzyło się na jakimś etapie skopiować kawałek kodu z jednego miejsca do innego. Źródłem mógł być wcześniej napisany samodzielnie kod, bądź też pochodzący z jakiegoś źródła z Internetu. Ci, którzy zaczynali się uczyć programowania z książek pewnie przepisywali kod i sprawdzali co się stanie.

 

Kiedy zaczynałem programować w .NET pamiętam, że miałem taką książkę z przykładami kodu. Bardzo dużo różnych fragmentów gotowych do wykorzystania. W tamtym czasie była to bardzo pomocna pozycja. Dawno to było, pewnie ok roku 2005. Jednakże pamiętam, jak dzięki recepturom zawartym w książce udawało mi się dość szybko rozwiązywać problemy, z którymi się mierzyłem. Dzisiejsza rzeczywistość jest znacznie inna i te same rzeczy można odszukać na StackOverflow.

 

Jednakże to co pomagało w czasie uczenia się języka w późniejszym czasie wielokrotnie powodowało irytację. Pracując na dużych projektach i widząc bardzo dużą duplikację kodu miałem nawet ochotę wyciągać ludziom klawisze C i V na klawiaturze.

 

Jak większość rzeczy są dobre i złe strony każdego podejścia. Po prostu trzeba wiedzieć jak korzystać odpowiedzialnie z dostępnych narzędzi.

 

Minusy programowania przez kopiuj-wklej

Niezrozumiały kod

Bardzo często czas jest ważniejszy od jakości. Ktoś ma problem do rozwiązania. Nie wie jak go ogarnąć. Pyta o pomoc wujka Googla. Ten mu odpowiada linkiem do StackOverlow. Tam gotowy kawałek kodu. Szybkie kopiuj-wklej do własnego projektu. Bach działa. Lecimy dalej. Niestety ale to jest rzeczywistość. Problem jest w tym, że kod, który jest kopiowany nie zawsze jest zrozumiały dla osoby, która go kopiowała. Aplikacja działa, programista nie zastanawia się dlaczego tak jest. Najważniejszy jest wynik a nie zrozumienie problemu. Taka praktyka może rodzić więcej problemów.

 

Możliwe błędy

Kod, który był opublikowany na StackOverflow czy innej stronie, mógł być napisany pod konkretny problem. Nie koniecznie on był dokładnie taki sam jak osoby, która go później kopiowała. Kod taki mógł być też uproszczony. Mogło w nim nie być żadnej walidacji zmiennych. Po prostu miał pokazywać jak coś można osiągnąć w przypadku idealnych parametrów. Wiadomo, że walidacja wymaga pisania dodatkowego kodu, który najczęściej jest zbędny w przypadku strony Q&A. Bezmyślnie skopiowany kod, może więc prowadzić do błędów w czasie działania programu.

 

Nieoptymalny kod

Kod opublikowany na stronie Q&A może być napisany nieoptymalnie. Ma pokazywać rozwiązanie danego problemu. Jednakże niekoniecznie może być napisany pod kątem problemu z jakim się mierzy programista, który go kopiuje. Przykładem może być łączenie łańcuchów znaków w pętli. Od razu nasuwa się tutaj użycie klasy StringBuilder. Jak ktoś zada pytanie jak połączyć w pętli łańcuchy znaków to dostanie pewnie odpowiedź w podobnym stylu

 

var builder = new StringBuilder();

for(int i = 0; i <= 10; i++)

{

builder.Append("a");

}

 

Teoretycznie w takim podejściu nie ma nic złego. Teoretycznie, bo kod może być niedopasowany do konkretnego problemu. StringBuilder jest ciekawą klasą, która ma zainicjalizowaną początkowy bufor. W momencie kiedy zostanie dodanych więcej znaków niż jest dostępnych w buforze to bufor jest podwajany. Ta operacja może być bardzo kosztowna w przypadku wielu iteracji. Bardziej optymalnym rozwiązaniem może być inicjalizacja obiektu z większym buforem. Tyle tylko, że jak się kopiuje bezmyślnie kod to nie zwraca się uwagi na takie detale. Innym problemem jest wybieranie odpowiedzi, która ma najwięcej głosów nie czytając komentarzy czy innych odpowiedzi. Te inne odpowiedzi mogą być o wiele bardziej efektywne, ale często wygrywa pierwsza. Tak na marginesie to inne metody łączenia ciągów znaków mogą być bardziej efektywne.

 

Więcej kodu niż potrzeba

O ile na StackOverflow są najczęściej, krótkie fragmenty kodu to już kopiowanie z CodeProject może prowadzić do kopiowania całej masy niepotrzebnego kodu. Przykład. Potrzebne jest zaszyfrowanie jakiegoś teksu. Pytanie do Google i dostajemy odpowiedź z CodeProject, gdzie ktoś zaimplementował sobie kilka różnych metod szyfrowania. Nic, że one nie są potrzebne dla konkretnego zastosowania, ale skoro z CodeProject idzie ściągnąć sobie cały projekt i jeszcze dołączyć go do solucji, więc po co się męczyć i wydzielać to co jest rzeczywiście potrzebne. Na skróty jest najłatwiej. Liczy się przecież często tylko czas, a nie jakość.

 

Brak spójności

Klepanie ficzerów na czas poprzez kopiowanie czyjegoś kodu prowadzi często do tego, że jedna metoda lub klasa może być napisana w różnych stylach. Efekt komiczny. Ot wszystko zależy od osób, które odpowiadały na StackOverflow. Jak się pisze na czas to niekoniecznie patrzy się na refaktoryzację i dostosowanie kodu do własnej konwencji nazewniczej. Więcej o nazwach pod tym linkiem.

 

Wiele potencjalnych miejsc wystąpienia błędu

Inną kategorią jest kopiowanie kodu w ramach projektu. Ot ktoś napisał metodę, która coś tam robi, ktoś inny potrzebuje takiej samej funkcjonalności. Szybkie kopiuj-wklej i problem rozwiązany. Problem się może pojawić w przypadku, gdy kopiowany kod był pełen błędów. Tutaj pisałem więcej o tym do czego może prowadzić takie podejście.

 

Nieaktualny kod

Kopiowanie bez zastanowienia może prowadzić także do kopiowania kodu, który nie będzie dalej rozwijany, gdyż powstał już jego zamiennik. Przykład. Programista potrzebuje wykonać transformację xslt. Trafia na odpowiedź sugerującą użycie klasy XslTransform. No i używa tego bo to pierwsza odpowiedź. Problem w tym, że w międzyczasie pojawiła się transformacja za pomocą XslCompiledTranform. XslTransform została oznaczona jako przestarzała i nie będzie dalej rozwijana.

 

Dobre strony programowania przez kopiuj-wklej

Wystarczy tego demonizowania. Podejście kopiowania i wklejania kodu jeżeli wykorzystane odpowiedzialnie może przynieść także wiele korzyści i znacznie skrócić czas tworzenia oprogramowania jednocześnie podnosząc jego jakość.

 

Snippety

Zmieniasz często projekty? Są one podobne do siebie w swojej naturze? Jak tak to pewnie albo piszesz wielokrotnie ten sam kod, bądź też kopiujesz go pomiędzy projektami. Pamiętasz jak pisałem o książce z recepturami, którą wykorzystywałem podczas uczenia się programowania. Pewnie właśnie tego tutaj potrzebujesz. Repozytorium fragmentów kodu, które wykorzystujesz w wielu projektach. Może być to zewnętrzne repozytorium, lub też w ramach swojego ulubionego środowiska programistycznego możesz sobie przygotować fragmenty kodu, które będziesz wielokrotnie wykorzystywał.

 

Gotowe biblioteki

Możesz pójść dalej w tym podejściu i stworzyć sobie gotowe biblioteki. Korzystasz z platformy .NET? Jak tak to pewnie też korzystasz z NuGetów. Wykorzystywanie NuGetów to nic innego jak kopiowanie tego samego kodu pomiędzy projektami. Z taką różnicą, że kod ten już jest skompilowany. Możesz Tworzyć swoje biblioteki, które będą Ci pomagać w pracy na wielu projektach. Jak coś jest dobrze napisane, obtestowane, najlepiej automatycznie, to po co tą samą funkcjonalność za każdym razem pisać na nowo.

 

Szablony projektów w IDE

W VisualStudio tworząc nowy projekt, możesz sobie wybrać szablon z którego on powstanie. Można pisać ten kod każdorazowo samodzielnie. Pytanie tylko po co to robić. Szablony projektów sprawdzają się idealnie jak tworzysz rozwiązania, które są do siebie podobne. Fajne jest to, że można tworzyć także swoje szablony. Ponownie jest to tworzenie duplikacji kodu, jednakże w tym przypadku jest to bardzo pomocne i oszczędzające czas. Nikt chyba nie lubi wykonywać wielokrotnie tej samej pracy.

 

Modele

Piszesz aplikacje w oparciu o API, którego jesteś pierwszym klientem? Tworzysz web service, który ma swój model, następnie serializowany do JSON i zwracany w odpowiedzi do klienta. Jak klient po swojej stronie też potrzebuje taki sam model POCO, to nie ma sensu pisać go na nowo, tylko skopiować. Można naturalnie stworzyć osobną bibliotekę, zawierającą modele. Jednakże nie w każdej sytuacji jest to możliwe do zrealizowania.

 

Nauka

Kopiowanie czyjegoś kodu, jeżeli robione odpowiedzialnie, może być też dobrą nauką. Analizując kod, a nie tylko go kopiując, możesz się nauczyć wielu ciekawych rzeczy. Rozwijać swoje umiejętności. Takie podejście może nauczyć Ciebie rozwiązywania problemów w inny sposób niż robiłeś to dotychczas. Możesz łatwiej zrozumieć mechanizmy i techniki, które wcześniej były jedną wielką niewiadomą.

 

Zaoszczędzony czas

Na pewno tworzenie oprogramowania z wykorzystaniem istniejącego już kodu w bardzo dużym stopniu może zaoszczędzić czas na zrealizowanie projektu. Musi być to robione jednakże odpowiedzialnie. Tak by zarówno eliminować niepotrzebne, powtarzalne czynności, jednocześnie dbając o jakość.

 

A jakie ty widzisz zalety bądź wady podejścia do programowania przez kopiuj-wklej? A może nie kopiujesz w ogóle, nie używasz gotowych komponentów? Podziel się swoją opinią na ten temat.

Komentarze

Bądź pierwszą osobą, która skomentuje ten post.

Napisz komentarz