Ciągłe udoskonalanie się jest jednym z przewodnich motywów ruchu Software Crafstsmanship. Nie każdy może to lubić. Jedni podchodzą do pracy programisty w kategoriach odbicia swoich 8 godzin a nieważne jakim stylu. Inni zaś tego stylu szukają a raczej ciągle go udoskonalają.

 

Podobnie jest w innych dziedzinach gdzie ciągłe udoskonalania warsztatu sprawia, że satysfakcje z wykonywanego zajęcia jest większa. Może to być granie na instrumentach muzycznych, sport czy tak przyziemne rzeczy jak programowanie. Osobiście nie uważam się za super najlepszego w świecie programistę, jednakże z dnia na dzień staram się udoskonalać swój warsztat.

 

Jednym ze sposobów udoskonalania umiejętności w programowaniu jest rozwiązywania zadań algorytmicznych. Tylko, żeby były one efektywne to powinny się zmieniać. Nie ma sensu pisanie codziennie tej samej pętli for, czy rozwiązywanie jednego algorytmu na tysiąc różnych sposobów.

 

Fakt, że większość osób pracujących na co dzień z komputerem, pisze regularnie maile nie sprawi od razu, że każdy stanie się poczytnym autorem książek. Aby to osiągnąć to musi się zmieniać otoczenie, muszą zmieniać się zewnętrzne bodźce, które sprawią, że posiadane umiejetności wejdą na kolejny poziom.

 

Dla mnie jednym ze sposobów podnoszenia swoich umiejętności jest rozwiązywanie zadań algorytmicznych. Poza tym, że utrwalam dzięki temu możliwości języka w jakim programuje, to także mogę praktykować podejście Test Driven Development. TDD nie jest czymś co na co dzień każdy wykorzystuje w swojej pracy programistycznej. Nie zawsze pisanie testów w pierwszej kolejności jest efektywne. Czasami lepiej najpierw zaimplementować metodę, a później napisać do niej odpowiednią ilość testów jakie są konieczne do tego aby uzyskać jak największe pokrycie. Zarówno od strony linii kodu jak i przypadków testowych.

 

Rozwiązywanie, krótkich zadać algorytmicznych, gdzie np. zadeklarowana jest z góry sygnatura metody umożliwia napisania najpierw odpowiedniej ilości przypadków testowych a później ich implementację. Jest to bardzo ciekawa cecha tego typu zadań.

 

W sytuacji, gdy zadanie do rozwiązania ma już zdefiniowane przypadki testowe można też się nauczyć lepiej testować swój kod. Pokrycie kodu w 100% nie oznacza, że został on pokryty w 100%. To, że coś działa na jednym przypadku testowym, nie oznacza, że będzie działać na innych danych.

 

Zachęcam do poświęcenia w tygodniu godziny na napisanie kodu, który będzie rozwiązaniem na proste zadanie algorytmiczne. Nie ma potrzeby wymyślania zadań dla siebie. Takowe dostępne są na wyciągnięcie ręki. Poniżej kilka linków, gdzie można znaleźć zadania programistyczne w różnych językach.

 

www.codewars.com

www.codekata.com

www.codingdojo.org

www.hackerrank.com

 

Rozwiązywanie kata, to nie jest jedyny i najlepszy sposób aby stać się lepszym w tym co się robi. Jest to tylko jedna z dróg do celu.

Agile jest super. Jak programować to tylko w adżajlu. Praca w inny sposób jest passe. W ciągu swojej kariery zawodowej miałem możliwość rozmawiać z wieloma programistami. Szczególnie obecnie większość osób chce pracować w scrumie. Firmy się ogłaszają, że mają scrum. To przyciąga programistów jednak nie wiele osób zastanawia się czym jest to zwinne podejście do programowana.

 

Aby być bardziej atrakcyjnym na rynku pracy, firmy organizują szkolenia ze scruma. Sam w takich uczestniczyłem. Po dwóch dniach szkolenia ludzie zostawali Scrum Masterami lub Product Ownerami. Większość uczestników stanowiły osoby które wcześniej były Project Managerami. Zmieniała się etykieta, niekoniecznie sposób pracy.

 

Manifest Agile został podpisany w 2001. Jego sygnatariusze pracowali w różnych metodologiach zwinnych.  W ciągu 3 dniowego spotkania doszli do konsensusu w 4 kwestiach.

 

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

http://agilemanifesto.org

 

Podczas gdy tematy to prawej stronie są dalej ważne, większą wartość dla osób podpisujących manifest miały te po lewej stronie.

 

Obserwując sytuację obecnie odnoszę wrażenie, że nie wiele osób mówiących, że dostarcza oprogramowanie w sposób zwinny, ma w ogóle świadomość powyższego manifestu.

 

Wiele osób dostarcza produkt po staremu, tylko firmy nazywają się agile, bo zainwestowały w szkolenia.

 

Scrum jest najpopularniejszym podejściem obecnie. Mam okazje rozmawiać z wieloma programistami, którzy pracują w ten sposób. Jako, że osobiście jestem bardzo zainteresowany ciągłym udoskonalaniem, często się pytam jakie zaproponowali ostatnio usprawnienia w procesie. Pytam o to, gdyż bardzo lubię się uczyć na błędach innych. Niestety ale nie wiele osób jest mi w stanie odpowiedzieć sensownie na moje pytanie. Coś jest więc nie tak, gdyż retrospekcja, która jest jednym z filarów prowadzenia projektów w ten sposób, powinna właśnie prowadzić do ciągłego samo udoskonalania.

 

Praca w ten sam sposób, bez wprowadzania udoskonaleń jest w sprzeczności z ideą zwinnego prowadzenia projektów.

 

Nie znając dokładnie zespołów w jakich osoby te pracują ciężko mi oceniać co tam jest nie tak. Jednakże bardzo często odnoszę wrażenie, że stoi to w sprzeczności do pierwszego punku manifestu. Zespół powinien pracować na poziomie ludzkim. Nie powinno mieć to znaczenia jakich używa procesów i narzędzi. Umiejętność przekazywania konstruktywnej krytyki, która prowadzi do udoskonalania procesów jest podstawą by można mówić o tym, że bardziej cenieni są ludzie i interakcje, ponad narzędziami i procesami.

 

Z uwagi na fakt, że większość firm nie jest zbyt dobra w budowaniu zaufania pomiędzy pracownikami na różnych stopniach w hierarchii, scrum ma specyficzną rolę Scrum Mastera. To ta osoba powinna stymulować zespół do otwartej współpracy. Wydanie certyfikatu kosztuje dwa dni i trochę pieniędzy. Tylko czy firma go wydająca robi to po to by zespoły lepiej pracowały czy po to by zrealizować swoje cele biznesowe? To już biznes czy krzewienie idei?

 

Nie jest tak, że wszyscy Scrum Masterzy są źli i w zespołach nie ma dyskusji opartej na zaufaniu. Takie osoby też poznałem, jednakże są one w mniejszości.

 

W zespole, w którym jest zaufanie i dobre relacje między ludzkie rolę tą mógłby pełnić każdy naprzemiennie. Nawet Team Leader lub Manager. Pomimo tego, że każdy w scrumie jest równy to nie przeszkadza to firmom tworzenia hierarchii.

 

Manifest, który został stworzony w 2001 roku nie mówi bezpośrednio nic o jakości oprogramowania. Temat ten pojawia się jednakże poszczególnych podejściach. Jednakże manifest mówi o tym by być w stanie szybko reagować na zmiany. Aby to było możliwe oprogramowanie musi być napisane w taki sposób by zmiany w specyfikacji można było wprowadzić bez konieczności przepisywania wszystkiego.

 

Zmiany w wymaganiach są tym co może decydować o przewadze jednego produktu nad innym.

 

A late change in requirements is a competitive advantage

Mary Poppendieck

 

Czy osoba, która pilnuje tylko tego by terminy były spełnione będzie weryfikować czy kod napisany jest dobrze i w taki sposób by dało się go łatwo rozszerzać? Jest to możliwe, ale nie jest to powszechne. Jest to o tyle trudne w przypadku gdy Scrum Master nie ma wiedzy technicznej, a zespołowi brakuje doświadczenia.

 

Problem, który obserwuje z programistami, którzy chcą tylko podążać za dobrymi praktykami oprogramowania jest taki, że osoby te bardzo często mają tendencje to przekomplikowania. Podczas gdy jakość jest potrzebna aby móc szybko odpowiedzieć na zmieniające się wymagania tendencja do pisania na wyrost niestety jest bardzo duża. Co ciekawe doświadczeni programiści wiedzą co to jest YAGNI, natomiast nie zawsze widać to w kodzie jaki jest tworzony.

 

Często brakuje pragmatycznego podejścia. Zarówno ze strony programistów jak i ludzi wyszkolonych w ciągu dwóch dni. Czy ty w swojej pracy, gdzie wykorzystujesz podejście zwinne do programowania zwracasz uwagę na manifest podpisany w 2001 roku? Czy po prostu podążasz za tym co było na szkoleniu i bardziej skupiasz się na procesie niż na współpracy?

 

Osobiście jestem gorącym zwolennikiem zwinnego podejścia do programowania. Wiem, że są miejsca gdzie działa to bardzo dobrze, jednakze wiem też z doświadczenia i rozmów z innymi, że często nie jest to tak kolorowa jak się o tym mówi publicznie.

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.