Jak się mają Feature Switce do Refaktoringu? Otóż bardzo dobrze. Jakbym był w przedszkolu, no może we wczesnej podstawówce, mógłbym napisać: Feature Switch + Refactoring = ❤️❤️❤️ Dlaczego tak? Ponieważ użycie switchy podczas refaktoringu, daje niesamowitą swobodę oraz zapewnia ciągłość działania aplikacji podczas całego procesu upiększania kodu. Jak to może Więcej…
Dawno temu w deszczowej Szkocji, przemierzając rowerem krzywy wiadukt kolejowy, doznałem olśnienia. Mym oczom ukazały się wielokolorowe puzzle, zbite w olbrzymią, tęczową breję. Każdy z kolorów symbolizował inną domenę biznesową. Ktoś zmieszał te wszystkie, niepasujące do siebie elementy razem. Dlaczego? W imię wielokrotnego użycia kodu!
Błąd. Dziura. Usterka. Codzienność z życia programisty. Wszystkim deweloperom na świecie te słowa są znajome, no, chyba że nie znają Polskiego, ale ja nie o tym :). Występowanie bugów jest naturalną składową tworzenia oprogramowania. Nie ma w tym nic złego, a problem pojawia się, dopiero gdy jest więcej błędów, a Ty nie jesteś w stanie nad nimi zapanować. Jak to wygląda i co jest jego przyczyną? Opisuję i objaśniam :)
Współdzielenie kodu pomiędzy projektami przyspiesza dodawanie nowych funkcjonalności i zmniejsza ilość występujących błędów. Jak łączyć wspólne fragmenty w dotnecie? Jeżeli projekty używają tej samej wersji frameworka, to jest to bardzo łatwe i intuicyjne. W przeciwnym wypadku sprawy nieco się komplikują. Zapraszam na opis sposobów wielokrotnego użycia kodu w świecie .NET, które możesz zaadaptować do innych technologii.
Pamiętasz sytuacje, gdy czas implementacji nowych funkcjonalności rósł w nieskończoność? Masz może w głowie projekt, gdzie dodanie pola, czy zmiana pojedynczej reguły walidacyjnej trwała wieki? Ja niestety tak. Jednym z powodów takiego stanu rzeczy jest niedbanie o czystość kodu. Sytuację tę przedstawię na przykładzie kuchennej analogii wyjaśniającej powolne tworzenie nowych funkcjonalności.
Od lat chodzą mi po głowie myśli o kodzie idealnym. Różne koncepcje, potwierdzające i obalające. Z jednej strony wiem, że coś takigo nie istnieje, ale z drugiej chcę szukać, drążyć. Gonić króliczka. Podczas deweloperskiej drogi miałem różne opinie na temat super-kodu. Z każdym rokiem, gdy nabieram więcej pokory i więcej rozumiem, moje spojrzenie się zmienia. Dzisiaj przedstawiam różne perspektywy tego tematu.
Kilka tygodni temu wspominałem o potrzebie refaktoringu aplikacji IsTableBusy. Planowałem użycie wzorca projektowego Command i Active Object. Jednak po przemyśleniach, bliżej kodu, doszedłem do wniosku, że w tym wypadku lepsze będzie użycie maszyny stanów. Poniżej przedstawiam uzasadnienie dlaczego tak oraz fragmenty kodu.
Wykonanie dużego refaktoringu, nie jest zadaniem prostym. Wymaga skupienia, doświadczenia i dyscypliny. Robiłem to wielokrotnie, z różnymi rezultatami. Z każdym następnym razem staję się coraz bardziej doświadczony. W trakcie swojej pracy udało mi się wypracować kilka zasad, które czynią tę czynność łatwiejszą i bezpieczniejszą. Część z nich to dobre praktyki przy refaktoringu, a cześć to po prostu zasady tworzenia dobrego kodu, które w tej sytuacji pomagają mi ogarnąć kod. Wszystkie jednak odpowiadają na pytanie: „Jak refaktorować?”. Zapraszam serdecznie!
W wolnym czasie piszę aplikację peryferyjną do IsTableBusy na bazie WeMos D1 mini. Nie jest ona jeszcze zbyt skomplikowana, ponieważ traktuję ten projekt mocno edukacyjnie. Większość czasu przeznaczonego na ten projekt spędzam na czytaniu internetu i dopisywaniu małych kawałków kodu. Dzięki temu idzie on do przodu, niestety praca w takim trybie nie sprzyja czystości kodu. Nadszedł więc czas na porządki.
Czym jest Inspekcja Kodu? Każdy wie lub może się szybko dowiedzieć, czytając na wikipedi. Zastanawiałem się ostatnio, czy czas poświęcony na tę czynność, mógłby być wykorzystany lepiej. Odpowiedź na to pytanie zależy od masy czynników. Takich jak podejście osób uczestniczących w procesie, czy specyfiki projektu. Postanowiłem zatem opisać rzeczy bardziej stałe, czyli jakie można osiągnąć korzyści z dobrego Code Review.
