Społeczność    

 CO WIEM O PROGRAMOWANIU
...KOMENTARZ DO PRZYKŁADU ZAMIESZCZONEGO W SIECI PRZEZ JEDNEGO Z POLSKICH MVP (NAGRADZANEGO PRZEZ PRODUCENTA MS EXCEL)


Czy sądzisz, że programowanie to tylko nauka samych elementów języka programowania i im więcej się ich nauczyć tym będziesz lepiej programował?


Może warto zastanowić się czy wszystkie kłopoty, z jakimi borykają się użytkownicy MS Excel wynikają z ograniczeń, które cechują program,
czy może część z nich jest następstwem utrwalonych, nie dość dobrych schematów posługiwania się programem.
Popatrzmy na przykład dydaktyczny, na który natknąłem się w sieci, podany przez jednego z trenerów MVP (z nagrodami przyznanymi przez producenta MS Excel).
Pokuszę się tutaj o moje sugestie dotyczące tego przykładu (przykład na obrazku).



Napisałem w punktach co, moim zdaniem, jest do poprawienia

* Użycie nazwy zmiennej „k” do sterowania numerami wierszy wprowadza w błąd. Schemat to używanie zmiennej o nazwie „w” do sterowania wierszami i o nazwie „k” do sterowania kolumnami.

* Zastanawiam się, czy użycie przykładu, którego funkcjonalność to działanie funkcji SUMA.JEŻELI ma sens. Przecież nikt takiego makra nie zastosuje skoro ma do dyspozycji funkcję SUMA.JEŻELI. Ja staram się używać przykładów dydaktycznych, mających praktyczny wymiar.
Zobacz: przykład (stronę trzeba trochę przewinąć)
Na stronie jest:
- projekt procedury zrealizowany metodą Jacksona, która jest jedną z procedur do zarządzania rejestrem wg Metodyki 4TG,
- tłumaczenie projektu na zapis w Visual Basic (z komentarzami),
- testowanie działania procedury.

* Procedura sumuje wartości wtedy, kiedy zgadza się sprawdzana wartość. To znaczy, że zmienna, w której dopisuje się kawałki wzoru raczej nie powinna nazywać się MojaFOrmula, ale na przykład: WzorSuma, czy SumaTxt, wtedy szybciej można się dowiedzieć o sposobie działania makro. Nazwy zmiennych wpływają na czytelność - szybkość interpretacji kodu programu.

* I pytanie. Przy ilu wierszach w rejestrze, w których klucze będą się zgadzały (załóżmy, że w komórkach do sumowania będą jednocyfrowe liczby), makro przestanie działać ze względu na długość wzoru?
Proponuję przećwiczyć: samemu sprawdzić dostawiając wiersze do rejestru i uruchamiając w/w makro.

* Poważny błąd, to brak jakichkolwiek komentarzy, jeśli ma to być materiał dydaktyczny to obowiązkiem jest wstawienie komentarzy w dwóch postaciach:
- opisu instrukcji,
- opisu realizowanych funkcjonalności.

* Własność Current.Rows.Count daje w wyniku liczbę wierszy i takie rozwiązanie poprawnie działa tylko tylko wtedy, kiedy wiersz bazowy to wiersz pierwszy. Przeważnie używa się rejestrów, które nie zaczynają się w pierwszym wierszu arkusza. Do znalezienia ostatniego wiersza rejestru, lepszym rozwiązaniem, jest:
wEnd = Range(„A” & Rows.Count).End(xlUp).Row
Oczywiście wcześniej trzeba zadbać o to, aby wszystkie wiersze były odkryte i o to, aby poniżej rejestru w komórkach arkusza nie było nic wpisane. To są zasady prowadzenia rejestru.

* Wartość końcowa w pętli FOR została podana za pomocą własności obiektu arkusza (Current.Rows.Count). Zdecydowanie korzystniejsze jest stosowanie do określenia wartości końcowej pętli FOR zmiennej (w mojej wersji rozwiązania to zmienna wOst), która podczas działania pętli FOR będzie utrzymywała cały czas jednakową wartość. Należy tak zrobić, ponieważ podczas analizy programu i wykonywania go krok po kroku (klawisz F8) trzeba znać wartość końcową pętli FOR (w tym celu, podczas wykonywania instrukcji programu krok po kroku, można ustawić kursor myszy na nazwie zmiennej, a wtedy pokaże się wartość tej zmiennej; do oglądania wartości zmiennych służy również okno wywoływane z menu Visual Basic: View | Locals Windows). Zdarza się, że podczas działania pętli FOR wartość uzyskana na podstawie własności obiektu arkusza zmienia się, ale wartość końcowa ustawiona w pętli FOR nie, ponieważ Visual Basic przechowuje wartość końcową zdefiniowaną przy pierwszym użyciu pętli FOR. Jeśli, do określenia wartości końcowej pętli FOR, zostanie wykorzystana wartość własności obiektu (może się ona zmienić podczas wykonywania instrukcji zawartych w pętli), to nie można sprawdzić wartości końcowej w działającej pętli FOR. To z kolei oznacza brak informacji zwrotnej przy wykonywaniu programu krok po kroku. Brak informacji utrudnia analizę tego procesu.

* To, co może sprawić drobny kłopot, to brak wartości początkowej zmiennej MojaFOrmula, która zmienia swoją wartość w pętli. Takie postępowanie sprawia, że mogą pojawić się błędy, w sytuacji, w której moduł realizujący taką funkcjonalność będziemy chcieli użyć w większej konstrukcji; na przykład w zewnętrznej pętli.
Dlatego, wskazane jest wypracowanie nawyku: wprowadzenia wartości początkowej zmiennych, które korzystają w pętli z wartości poprzednich (a tak jest w przypadku zmiennej MojaFOrmula). Wskazane jest mimo, że przy inicjacji procedury wartość zmiennej typu String to jest ciąg o długości zero znaków (o ile nie będzie napisane, że ma być inaczej).
Przy inicjacji procedury wartości liczbowe (o ile nie będzie napisane, że ma być inaczej) mają wartość zero.





Nawyki, które powstają (najczęściej w początkowej fazie uczenia się narzędzi informatycznych) wpływają później na czas: tworzenia, analizy i rozumienia kodu.

W moim rozwiązaniu oprócz arkusza z danymi (ar. Dane) jest jeszcze arkusz z parametrami (ar. Parametry),
w którym w komórce B3 znajduje wzór: =WIERSZ("Dane!1:1")+1 dający w wyniku numer pierwszego wiersza użytkowego w rejestrze. Po to, aby ustalić wiersz, od którego należy sprawdzać (i sumować) elementy rejestru.
Tu należałoby zwrócić uwagę, że pierwszy wiersz w ar. Dane, to wiersz leżący bezpośrednio przed pierwszym wierszem użytkowym rejestru.
We wzorze nie można wskazać pierwszego wiersza użytkowego rejestru, bo gdyby zostałby usunięty,
to: we wzorze zamiast Dane!1:1 pojawi się błąd Dane!#ADR!
(a częściej w rejestrze usuwa się wiersze użytkowe niż nagłówkowe) :)

W/w zapis w arkuszu Parametry używa się ze względu na fakt, że przy zmianie struktury danych (dostawieniu na początku ar. Dane kilku wierszy) zakres we wzorze automatycznie zmieni się i nadal będzie wskazywał wiersz bezpośrednio poprzedzający pierwszy wiersz użytkowy rejestru.
W konsekwencji zmieni się wynik działania wzoru i w rezultacie będzie równy numerowi pierwszego użytkowego wiersza rejestru. Nie byłoby to możliwe, gdy w makro "na sztywno" jest przyporządkowany numer wiersza, numer kolumny, czy adres komórki.


Rysunek nr 2. Arkusz Dane i Arkusz Parametry


Rysunek nr 3. Kod programu z wykorzystaniem wybranych zasad programowania

W zaproponowanym przeze mnie kodzie brakuje umieszczenia w arkuszu z parametrami:
- numerów/symboli kolumn z kluczami i numerów/symboli kolumn z wartościami do sumowania (w przykładzie to kolumny D i C)
- adresu komórki z wartością do sprawdzania (w przykładzie to komórka G1)
Proponuję zrobić to dla ćwiczenia, w podobny sposób, w jaki został ustalony numer wiersza (poprzedzający wiersz użytkowy rejestru). I wykorzystać te komórki w procedurze zamiast odwołań na sztywno do kolumn C i D oraz komórki G1.
Dzięki takiemu prostemu zabiegowi łatwo jest uzyskać elastyczność, co oznacza, że przy zmianie struktury danych w arkuszu Dane (dostawianiu/usuwaniu kolumn, zmianie położenia komórki G1 przesuwając ją w inne, bardziej dogodne miejsce arkusza) automatycznie zmienią się wyniki wzorów w arkuszu Parametry. Tych wzorów, z których korzystać będzie Procedura makro. i wtedy...
wszystko nadal będzie działać.

Jeśli w początkowej fazie nauki uczy się przypadkowych schematów, dających pożądany wynik, bez analizy, czy ten sam wynik można uzyskać w inny (łatwiejszy, elastyczny, bardziej czytelny) sposób, powstają niewłaściwe nawyki, które wpływają na czas tworzenia i analizy kodu. Zastosowanie mało czytelnych elementów utrudni umiejętność komunikacji człowiek – komputer – człowiek i wprowadzi chaotyczność działania. Brak zastosowania elastyczności w rozwiązaniach powoduje, że trudność modyfikacji rozwiązania radykalnie wzrasta.





Pomagamy uporządkować chaos

Problem w Excelu można rozwiązać różnymi sposobami, ale tylko taki sposób będzie ważny, który będzie czytelny i zrozumiały dla innych, łatwy w działaniu, bezpieczny, elastyczny. Dlatego sama automatyzacja pracy w MS Excel przestaje wystarczać.
Co oznacza, że ważna jest kultura pracy użytkowania i budowy w MS Excel rozwiązań oraz świadomość, że inni użytkownicy będą wykorzystywać Twoje rozwiązania.


Jeśli w/w tekst wydaje Ci się ważny, zauważyłeś różnicę w podejściu do rozwiązywania problemów, to poleć proszę mpoje posty wprowadzające do niniejszego artykułu na LinkedIn
czy FaceBook


A jeśli interesują Cię warsztaty z Visual Basic, na których są przykłady praktyczne jako tło do wyjaśnienia działania (tylko potrzebnych elementów Visual Basic), i chcesz więcej dowiedzieć się o zasadach programowania, to zapraszamy
programy warsztatów z Visual Basic


a jeśli nie ma terminu warsztatów, to oznacza, że jeszcze nie ustaliliśmy i, ...
jeśli zainteresowałem, to proszę o wypełnienie pliku PlanSzkolen.xlsx w którym możesz zaproponować kilka dogodnych dla Ciebie terminów.




O mnie w kontekscie kompetencji (dydaktycznych, informatycznych, projektowych, praktycznych)

ukończyłem studia: Przetwarzanie danych i Rachunkowość,
obroniłem pracę doktorską (napisałem język programowania KSI - do automatycznej dekretacji zdarzeń księgowych)
30 lat pracy w Uniwersytecie Łódzkim (Katerda Informatyki, Wydział Zarządzania), prowadziłęm zajęcia ze studentami
Od ponad 15 lat prowadzę własną firmę w której:
- prowadzę warsztaty z zastosowań MS Excel, projektowania i budowy rozwiązań
- projektuję i buduję automatycznie działające rozwiązania

Zaprojektowałem i zbudowałem tysiące rozwiązań w różnych narzędziach. Programowałem w różnych językach programowania.
W latach 90-tych prowadząc kółko informatyczne w XXXI LO w Łodzi doprowadziłem 4 uczniów szkoły do finału olimiady informatycznej (do piersze 40 osób w Polsce).
W ostatnich kilkunastu latach zajmowałem się projektowaniem i budową automatycznie działających rozwiązań (robotów) w firmach.
Łączę informatykę (głównie MS Excel z zarządzaniem, rachunkowością, statystyką, prognozowaniem, ...)
Opracowałem wiele narzędzi w Visual Basic do budowy robotów w MS Excel.
Uczę samodzielności myślenia. Uczę oceniania rozwiązań (drobne przykłady oceny są w niniejszym artykule)
Nie mam tytułu MVP, dlatego nie uczę wszystkiego czego sie da w MS Excel, uczę tylko tych elementów MS Excel, które są potrzebne.

Używam około 1% MS Excel + VB + SQL i za pomocą takiej niewielkiej ilości elemnentów potrafię zbudować wszystko, co można zrobić w MS Excel.
Staram się, aby każde rozwiązanie, które projektuję i buduję miało cechy:
- prostota budowy struktur danych i algorytmów, łatwa implementacja algorytmów (po to aby można było łatwo panować nad rozwiązaniem),
- czytelność (po to aby można było łatwo analizować rozwiązania)
- elastyczność (po to, aby można było łatwo modyfikować rozwiązania)
Opracowałem Metodykę 4TG (inżynieria oprogramowania dla MS Excel) - zasady projektowania i budowy automatycznie działających rozwiązań (robotów) w MS Excel, w tym mnóstwo potrzebnych rozwiązań po to, aby łatwiej projektować i budować rozwiązania.

I tego uczę.