Kolejna recenzja kolejnej książki…od tego samego autora 😊! Po kupieniu sobie poprzednio zrecenzowanej książki, wziąłem od razu drugą stanowiącą w pewnym sensie kontynuację nauki o "Microsoft Excel" 🧨! Mianowicie, "Makra i VBA w tydzień. Odkryj potęgę programowania!"! Jak interesujesz się jej zakupem, to zapraszam Cię do przeczytania artykułu, bo właśnie temu tytułowi jest on poświęcony w całości 🌟!
RECENZJA KSIĄŻKI "MAKRA I VBA W TYDZIEŃ. ODKRYJ POTĘGĘ PROGRAMOWANIA!"
"[...] w programowaniu nie ma nic z magii." (fragment z blurba książki)
Sprzeciw 😆! Dla mnie, programowanie jest jak najbardziej zajęciem polegającym na wywoływaniu magii 🪄 na ekranie komputera przy pomocy znaków w pliku 🙂. To jest fach, który zawsze będę lubić ❤️🔥.
Kiedy dowiedziałem się, że w Excelu można normalnie pisać kod i tym sposobem jeszcze bardziej podnieść swoją efektywność w kierunku analizy danych 📊, byłem ciekaw co można zrobić czego nie dałoby się osiągnąć samym klikaniem czy rejestrowaniem makra 💡. Usiadłem, przeczytałem, dowiedziałem się 🙂. Czas przejść do tego, co warto wspomnieć na temat książki "Makra i VBA w tydzień. Odkryj potęgę programowania!", czyli o pracy w Excelu "w podziemiu" ✒️!
Profilaktycznie, ta sama formułka 👇:
Recenzując książkę autorstwa Pana Mateusza Borygi i prezentując swoje zdanie na jej temat, nie leżało w mojej intencji żadne złośliwe wytykanie błędów. Jedynym celem publikacji recenzji było przedstawienie swojej opinii oraz sprostowanie pewnych przytoczonych treści, aby ewentualne ponowne wydanie książki było pozbawione wskazanych błędów, jeśli faktycznie takimi są (bo sam mogę się mylić!).
Przechodzę do meritum ▶️.
Informacje ogólne
Drugi raz książkę Pana Borygi oceniam pozytywnie, choć mam do niej więcej zastrzeżeń w porównaniu do poprzedniej (więcej zostawiam w sekcji z uwagami) ℹ️. Na plus wychodzi na pewno duża liczba cennych przykładów wziętych z życia zawodowego. Autor zebrał w całość różne przypadki biorąc pod uwagę te, które przyniosły jakąkolwiek wartość biznesową (po prostu były przydatne w praktyce 😉) 💲. Główna część książki właśnie na tym się skupia.
Gdyby tak wypunktować zagadnienia poruszane w tej książce, oto czego się z niej dowiesz 👇:
- jak wyglądają makra w Excelu od strony kodu źródłowego w języku Visual Basic,
- co można zrobić za pomocą kodu, czego nie da się zrobić przy pomocy rejestratora makr,
- zestaw najważniejszych instrukcji do programowania/modyfikowania wcześniej zarejestrowanych makr,
- jak stworzyć prosty formularz w postaci graficznej aplikacji do wprowadzania wartości do pól tekstowych jako parametry funkcji,
- aż kilkanaście gotowych rozwiązań na konkretne problemy.
Zaznaczam w tym miejscu, że choć rzeczywiście to jest książka o Excelu, to uczysz się od niej nie samego interfejsu, co programowania makr w Visual Basic ℹ️. Na tym koncentruje się 90% treści - to nie jest o samym poznawaniu programu Microsoft Excel ⚠️!
Sam początek książki "Makra i VBA w tydzień. Odkryj potęgę programowania!" przynosi dużo ciekawych informacji ✔️. W pierwszym rozdziale 1️⃣ jest ukazanie co kryje się za rejestrowaniem makra, zestawienie podstawowych instrukcji, proponowane podejście do uczynienia kodu reużywalnym, a na deser 🍨, utworzenie prościutkiej aplikacji graficznej w postaci wyskakującego okna 🎉! Można rzec, sama słodycz 🍬!
Najdłuższy rozdział (ponad połowa książki 😯), czyli drugi 2️⃣, dotyczy przedstawienia wielu konkretnych przykładów w kategorii "najczęściej rutynowe czynności" ⚙️. Podejście składa się z kilku etapów:
- przedstawienie problemu/czynności,
- ukazanie efektu przed i po zastosowaniu makra,
- seria pytań (albo nie 🙃),
- rozwiązanie słowne,
- kod źródłowy.
Bywają wyjątki np. nie każdy przykład posiada jakiekolwiek pytanie zadane w stronę Czytelnika albo jest inna kolejność treści, niż ta na liście u góry, natomiast zdecydowana większość przyjmuje właśnie taką formę ℹ️.
Sposób przedstawienia każdego z przykładów jest super ❤️, trochę gorzej z samym kodem na wielu płaszczyznach (o czym piszę więcej w uwagach do tytułu). Na pewno fajnie zostało zademonstrowane to, że w pewnych sytuacjach koniec końców jednak trzeba zajrzeć do kodu i dostosować go pod swoje potrzeby tam, gdzie nie sięgnie rejestrowanie makra 🙂.
Ostatni chudziutki rozdział (trzeci 3️⃣) dotyczy ukazania kolejnych drobniejszych trików, tylko już w formie krótkich fragmentów, a nawet pojedynczych instrukcji, które nie zostały poruszone wcześniej 🔥.
Jedno muszę przyznać: ta książka pokazała mi jak bardzo potężny jest Excel 💪. Nigdy człowiek nie korzystał z makr, bo nie było to konieczne i to trochę przykre, że dowiaduję się dopiero po latach o czymś takim, jak programowanie makr i tworzenie formularzy w Excelu (de facto takich małych aplikacji graficznych ❤️). W którymś momencie zacząłem myśleć: "Cholera, dlaczego nie pokazano mi tego w szkołach?!" 🙂. Po przeczytaniu tej książki, na pewno czuję się "bogatszy" o nową wiedzę, zatem tytuł spełnia podstawowy wymóg literatury mającej na celu nauczyć 🧠. Super 🌟!
To tak tytułem wstępu, jak brzmi mój ogólny odbiór 🏁.
Wady książki "Makra i VBA w tydzień. Odkryj potęgę programowania!"
Teraz podzielę się swoimi zastrzeżeniami co do treści, które niestety troszkę psują przyjemność z czytania ⛔. Zaczynamy 🚀!
Tabela byłaby o wiele lepsza
Na str. 19 jest wypisanie przez autora książki "Makra i VBA w tydzień. Odkryj potęgę programowania!" podstawowych instrukcji czy pojęć z jakimi można spotkać się w kodzie. Sęk w tym, że w mojej ocenie użyto nieodpowiedniego formatowania i powinno się to zrobić przy użyciu tabeli. W jednej kolumnie dać instrukcję, w drugiej krótkie wyjaśnienie i tyle. Napisanie tego w formie kodu źródłowego jest chaotyczne, bo wiersze robią dużo nieregularności i nie ma miejsca na taki format strony 📄. Raczej to nie kwalifikuje się jako errata, więc piszę o tym tutaj.
Przyczyna użycia instrukcji: nieznana
Poważna rzecz, która mnie zmartwiła to pokazanie jakiejś nazwy, instrukcji, zapisu i po prostu pójście dalej bez uwypuklenia do czego to służy albo dlaczego zostało tak napisane, tak jakby tego nie było. Zdarzyło się tak (niestety) wiele razy i to zarówno dla nazw ("Label", "TextBox", "With", "Dim" itp.), jak również symboli (ampersand, operator "różny od" itp.) 😔. Gdyby ktoś potrzebował dokładnej listy, to zostawiam poniżej 👇:
- & (konkatenacja łańcuchów),
- <> (operator "różny od"),
- Dim,
- For,
- Set (i kiedy tego NIE trzeba wstawiać),
- With,
- Label,
- "#,##" (łańcuch znaków w odpowiednim formacie),
- ForEach,
- TextBox,
- Type:=8 (parametr procedury "Application.InputBox"),
- Exit Sub,
- CreateItem,
- CreateObject,
- CommandButton,
- ActiveSheet.ListObjects.Add,
- ActiveWorkbook.PivotCaches.Create,
- ActiveCell.PivotCell.PivotTable.PivotCache.Refresh,
- rodzaje wartości dla poszczególnych parametrów procedury,
- kiedy wywołania procedur NIE potrzebują wstawiania parametrów wewnątrz nawiasów np. "Sheets(>>Dane<<).Copy".
Żeby nie było - nie jestem leniem i umiem sobie wpisać w wyszukiwarkę słowo kluczowe, które mnie interesuje, jeśli nie mogę się domyślić zastosowania 😊. Nie chodzi mi o żadne referaty. Krótkie jednozdaniowe wtrącenie co dana instrukcja przynosi i o co w niej chodzi, wystarczyłoby w zupełności ✅. Mnie przydałoby się zawrzeć taką informację (szczególnie, że to książka o programowaniu i dla początkujących ‼️), abym nie musiał zgadywać.
Potrzebna wizyta u "refaktoryzatora"
Najważniejsza wada ze wszystkich 👊. Ujmę to krótko: zaprezentowane kody źródłowe w książce "Makra i VBA w tydzień. Odkryj potęgę programowania!" wymagają przeróbki. Nie wszystkie, większość. Jestem programistą, który bardzo lubi porządek w kodzie 🙂 i zauważyłem, że wiele rzeczy można było napisać lepiej, schludniej, czytelniej. Stąd mój komentarz w tej sprawie 😊.
Nie ma sensu wypisywać wszystkiego jak leci, więc wypunktowałem konkretnie co moim zdaniem wymaga poprawki opierając się na konkretnym przykładzie, jeśli to było konieczne. Najpierw małe rzeczy, potem ważniejsze ℹ️.
Na koniec zwracam uwagę, że cały czas pamiętam o tym, że lektura jest skierowana dla osób początkujących i miała na celu wyjaśnienie wszystkiego prostym językiem 👍.
Nazwy makr
Nie wiem jaka jest konwencja w biznesowych etatach dot. obsługi Excela (teraz to ciężko się zatrudnić gdziekolwiek 😐), natomiast w programowaniu przyjmuje się, że nazwy procedur/funkcji/metod (terminologia zależy od języka) powinny być w trybie rozkazującym. Tutaj nie są.
Niewłaściwe nazwy parametrów formalnych
Chodzi o niewystarczające sprecyzowanie czego dotyczy parametr. Widać to chociażby na przykładzie z kodu jednego z makr znajdującego się w plikach do książki, które są dostępne do pobrania na stronie Helion (źródło: https://ftp.helion.pl/przyklady/janipr.zip, dostęp: 23.03.2026) 👇:
NazwaKolumnyStart"Start" dopisane na końcu nie brzmi w mojej ocenie informująco w sposób jednoznaczny co to robi, do czego to jest itd. Zdecydowanie lepiej byłoby to nazwać:
NazwaKolumnyOdKtorejZaczynamyDla mnie tak jest lepiej, bo skrót myślowy został rozwinięty 👍. Jeżeli jako programista, miałbym wybierać czy nazwę uczynić krótszą, czy bardziej precyzyjną, wybieram precyzyjność 🎯, natomiast rozumiem, że to może być kwestia gustu. Jest wiele takich nazw w wielu fragmentach, jednak nie ma potrzeby (ani sensu) wymieniać.
Powtarzanie się tych samych wyrażeń
Kolejna zła praktyka 🚫. Jest wiele takich instrukcji, poleceń czy fragmentów kodu, które niepotrzebnie się powtarzają. Dam przykład tego samego kodu zaprezentowanego w nagłówku powyżej:
NazwaKolumnyStart & "2"Ta sama instrukcje występuje 2 razy i to nie jest poprawne z 2 przyczyn:
- pogarsza czytelność kodu,
- procesor niepotrzebnie przetwarza tę samą instrukcję dwukrotnie.
Podpunkt nr 2 jest jeszcze istotniejszy o tyle, że przy większych makrach może to stać się pośrednią przyczyną znacznego spowolnienia działania 📉!
Pewne instrukcje można było napisać prościej
Istotniejsza sprawa to fakt, iż niektóre fragmenty kodu można było skrócić do jeszcze mniejszych postaci. Za przykład podam kod makra dot. wyboru folderu z listy, z tych samych materiałów do pobrania ze strony Helion (źródło: https://ftp.helion.pl/przyklady/janipr.zip, dostęp: 23.03.2026):
Sub MatkaWyborFolderuZListy()
On Error GoTo Blad
With Application.FileDialog(msoFileDialogFolderPicker)
.Show
WybranyFolder = .SelectedItems(1) & "\"
End With
MsgBox WybranyFolder
Exit Sub
Blad:
MsgBox "Nie wybrano folderu."
End SubOd razu co przykuło moją uwagę, to powtarzanie się wywołania "MsgBox". Jeżeli uzależniamy wyłącznie samą treść komunikatu od tego, czy użytkownikowi uda się wybrać jakiś folder, czy też nie, to można stworzyć zmienną łańcuchową, przypisać domyślną wartość (jako brak wybranego folderu) i wywołać jedno "MsgBox" na samym końcu:
Sub MatkaWyborFolderuZListy()
WybranyFolder = "Nie wybrano folderu."
On Error Resume Next
With Application.FileDialog(msoFileDialogFolderPicker)
.Show
WybranyFolder = .SelectedItems(1) & "\"
End With
MsgBox WybranyFolder
End SubWtedy cały ciąg z instrukcją skoku ("GoTo") i "Exit Sub" nie jest w ogóle potrzebny ✔️! To samo dotyczy przykładu z wyborem pliku z listy (str. 84) 🙂.
Brak zabezpieczenia przed skrajnymi przypadkami
Doszliśmy do ostatniego: nieuwzględnianie przez makra innych ścieżek decyzyjnych, niż optymistyczna. Czyli zawsze jest wartość w parametrze, zawsze jest oczekiwanego typu, dany arkusz zawsze posiada tę i tę komórkę o tej wartości. Przypadek, gdy "wszystko jest cacy" 😁.
Pozwoliłem sobie zmienić parę rzeczy w przykładach i sprawdzić co się stanie jak NIE sprawdzi się scenariusz, w którym instrukcje mogą funkcjonować na samych założeniach. I niestety makra wykładały się jak na wrotkach 🛼. Fragmenty kodów nie obejmują sytuacji niepożądanych, które także mogą mieć miejsce.
Weźmy sobie kod makra, tym razem dot. zmiany wielkości zaznaczenia (to samo źródło: https://ftp.helion.pl/przyklady/janipr.zip, dostęp: 23.03.2026):
Sub MatkaZmianaWielkosciZaznaczenia()
Range("A2:C4").Select
LiczbaWierszy = Selection.Rows.Count
LiczbaKolumn = Selection.Columns.Count
Selection.Resize(LiczbaWierszy - 1, LiczbaKolumn - 1).Select
End SubOd razu zadałem sobie pytanie: a co, jak zakres będzie obejmował tylko jedną komórkę 🙂? Zmieniłem na samo "A2", odpaliłem i obawy były słuszne - błąd ❌!
Odrębna sprawa to to, że makro działa na sztywno ustalonych wartościach i nie ma możliwości wstawienia parametrów, przez co kod nie jest elastyczny 🛑.
Napisałem sobie taką wersję 👇:
Sub MatkaZmianaWielkosciZaznaczenia()
Call ZmianaWielkosciZaznaczenia("A2:C4", -1, -1)
End Sub
Sub ZmianaWielkosciZaznaczenia(Zakres, ZmianaWWierszach, ZmianaWKolumnach)
Range(Zakres).Select
AktualnaLiczbaWierszy = Selection.Rows.Count
AktualnaLiczbaKolumn = Selection.Columns.Count
OstatecznaLiczbaWierszy = WorksheetFunction.Max(AktualnaLiczbaWierszy + ZmianaWWierszach, 1)
OstatecznaLiczbaKolumn = WorksheetFunction.Max(AktualnaLiczbaKolumn + ZmianaWKolumnach, 1)
Selection.Resize(OstatecznaLiczbaWierszy, OstatecznaLiczbaKolumn).Select
End SubSprawdziłem i działa ✔️. To naturalnie nie pokrywa wszystkich przypadków np. w miejsce zakresu może pojawić się liczba albo wstawimy łańcuch w miejsce zmiany wielkości (choć podejrzewam, że wystarczy wtedy dać instrukcje warunkowe sprawdzające typ), natomiast ta postać pozwala na bezpieczne modyfikowanie wielkości zaznaczenia w sytuacji, gdyby miało wejść na zakresy ujemne albo zero 🔒. Ponadto, możemy dać w obie strony i ile chcemy 👑.
Żebym nie został źle zrozumiany! Nie chodzi mi o branie pod uwagę każdego mikroskopijnego przypadku 🔬, tylko raczej o pokazanie, że autor bierze pod uwagę taką okoliczność, demonstruje ją przynajmniej na jednym przykładzie (albo nawet wstawić to jako odrębny temat do któregoś z rozdziałów) i krótko tłumaczy dlaczego należy mieć tego świadomość 🔍. To jest moim zdaniem o tyle ważne, że takie podejście raz po raz może spowodować, że ktoś nauczy się pisać kod w taki sposób i nie będzie wiedział, że czyni to nie do końca właściwie ⚠️! A jedną z cech dobrego programowania jest odporność na wszystkie przypadki 🛡️.
Na końcu dopiszę, że cały czas mam na uwadze, że to są tylko przykłady przedstawione na konkretnych sytuacjach i one miały być z założenia proste (wzięcie wszystkiego pod uwagę mogłoby mocno "pogrubić" książkę 😀), a sam tytuł nie jest dla "orłów z Excela" 🦅. Znając jednak ten zawód, to takie podejście nie przeszłoby na żadnym etacie i góra kazałaby to poprawić, być może według powyższych wytycznych.
A co, gdyby było ustawione inaczej?
Kolejna rzecz, która "uwiera", to ukazanie jakichś ustawień, konfiguracji czy parametrów i nie ma ani słowa o tym, czym wynik różniłby się od drugiego, gdyby zmieniono wartość parametru lub instrukcję 🤨. Podaję konkretne przykłady 👇:
- "Przechowuj makro w: Ten skoroszyt"
- brak informacji kiedy mogłaby się przydać zmiana domyślnego ustawienia (str. 30),
- "On Error GoTo Etykieta"
- brak informacji kiedy instrukcja wyświetlania okna dialogowego zwraca wartość jako błąd i w jaki sposób to działa, że instrukcja "On Error" to "przechwytuje" (str. 83),
- "On Error GoTo 0"
- co daje wstawienie zera i dlaczego napisane w taki sposób? (str. 87),
- "Nothing"
- dlaczego jest przypisanie do "Nothing", czy można było to napisać inaczej oraz co by się stało, gdyby tego nie było? (str. 87),
- "Application.DisplayAlerts"
- jeżeli miałbym niezapisane zmiany, to rozumiem, że wtedy by przepadły? (str. 90).
Mój komentarz: patrz wyżej 😄!
Dodatkowe uwagi
Tutaj wpisałem część podpunktów, które bardziej są uwagą niż oczywistą wadą skutecznie obniżającą radość ze studiowania książki ℹ️.
Bardziej zwięzła forma "autorskiego schematu działania z każdym wyzwaniem w VBA"
Na str. 30 znajduje się lista wypunktowana, która ma dwie rzeczy do wzięcia pod uwagę 2️⃣.
Po pierwsze, można było spróbować scalić ze sobą punkty ("Testowanie" i "Testowanie makra-matki"), jako że w treści różnią się tylko jednym słowem 😉. Po drugie, dorzuciłbym do punktu "Przekształcenie zarejestrowanego makra na wzorzec matka-córki" jeszcze jeden podpunkt na końcu: "Edycja kodu" lub "Refaktoryzacja kodu". Kroki do edycji makra i przerobienia go na uniwersalną wersję nie kończą się przecież na samym przejściu do "Module1" 🙂.
Jak to mam rozumieć?
Zdarzyło się w treści (poza kodem źródłowym), że nie mogłem zrozumieć pewnych określeń czy sformułowań. Albo zostało coś napisane w sposób niezrozumiały, albo nie było wytłumaczenia. Oto one 👇:
- "[...] w Twojej wersji Excela"
- jest jakieś zróżnicowanie zależne od wersji? (str. 19),
- "[...] do adresu tego zakresu [...]"
- co to jest adres i dlaczego trzeba się odwoływać w taki sposób? (str. 92).
Byłoby dobrze umieścić wyjaśnienie, chociaż w formie jednego zdania 📝.
Odpowiedź lepiej umieścić nieco dalej od pytania
Moim zdaniem, stawianie odpowiedzi tuż pod pytaniem wywołuje pokusę i odruch, aby zajrzeć od razu do odpowiedzi, zanim człowiek pomyśli sam 😜. Natomiast wiem, że w przypadku tej książki byłoby trudno wyjaśniać przykład jeden po drugim przenosząc wszystko na sam koniec, aby musieć co chwilę tam przechodzić i wracać 🙂.
Kopiuj, wklej!
I ostatnia najdrobniejsza uwaga 🙂. Zauważyłem, że zdanie z następującym fragmentem 👇:
"[...] Excel nie umożliwia [...]"jest napisane słowo w słowo, zarówno na str. 47, jak i na str. 51 😛.
Czy książka jest warta zakupu?
W końcu najważniejsze pytanie 😁. Tylko, jeśli Ci zależy na poznaniu możliwości Excela od strony programistycznej, czyli automatyzacja pewnych czynności przy użyciu kodu, bo jednak większa część wymaga szperania w kodzie i nie wystarczy rejestrowanie makr 🔴.
Także gdy chcesz dowiedzieć się o makrach w stopniu bardziej zaawansowanym, to bez dwóch zdań będą to dobrze wydane pieniądze, bo ta książka zawiera w sobie wiedzę opatrzoną etykietą "o tym nie powiedzą Ci w szkole". Natomiast to nie jest książka ucząca stricte tego, jak poruszać się po interfejsie Microsoft Excel! Wtedy możesz sięgnąć po książkę "Excel w tydzień! Uwolnij potęgę danych!", którą niedawno recenzowałem na stronie ℹ️.
 |
Książka "Makra i VBA w tydzień. Odkryj potęgę programowania!" składa się z cennej treści jak zacząć programowanie makr oraz zawiera zbiór gotowych patentów na postawione problemy, aczkolwiek kody źródłowe wymagają poprawek.
To wszystko! Teraz decyzja należy do Ciebie czy sobie to kupić, czy nie 😀!