Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

niedobreprogramy

W gąszczu burzliwych dyskusji dotyczących ostatnich nie-do-końca-legalnych działań (DDoS) sfrustrowanych internautów warto zwrócić uwagę na trochę z innej beczki, choć powszechny, problem współczesnego oprogramowania komputerowego.

Świeżo upieczony programista oczekuje bowiem, niemalże natychmiast, widocznych rezultatów swojej pracy (czyt. kolorowych, wielofunkcyjnych okienek wykonujących bardzo ważne rzeczy). I tak, jak grzyby po deszczu pojawiają się programy (małe i duże) zawierające błędy i niedopatrzenia. Może to kwestia dobranej do projektu metodologii programowania, może wynika to z chęci jak najszybszego wdrożenia na rynek produktu, a może zupełnie coś innego? Jaka by nie była przyczyna takiego stanu rzeczy, problem "błędów w oprogramowaniu" dotyczy każdego programisty.

Swego czasu podjąłem próbę wytłumaczenia osobie z poza środowiska tęgich głów "dlaczego niektóre programy się tak wieszają?". Choć zdaję sobie sprawę z tego, że w paru miejscach musiałem minąć się z rzeczywistością aby uzyskać pożądany efekt (czyt. zrozumienie), takie łopatologiczne przedstawienie sprawy okazało się owocne.

Łopato-

Wyobraź sobie, że tworzysz program komputerowy, którego sposób działania będzie całkiem oczywisty tj. program dokona działania na dwóch liczbach całkowitych. Najlepiej będzie, jeżeli - w myślach - przyporządkujesz tym liczbom jakieś konkretne nazwy np. "a" oraz "b". Pod nazwą "a" zapamiętaj pierwszą z liczb wprowadzanych przez użytkownika programu, pod nazwą "b" zapamiętaj drugą z liczb. Następnie dodaj te liczby do siebie i wynik zapamiętaj pod nazwą "wynik". Wyświetl wynik dodawania dwóch liczb i zamknij program. Proste, prawda?

Spójrzmy na to całkiem oczywiste zagadnienie z punktu widzenia dobrze udokumentowanej i lubianej przez wszystkich (a może i nie) platformy .NET. Każde z powyższych zdań choć z pozoru nieskomplikowane gramatycznie, w kontekście programowania rodzi kolejne pytania.

-logia

  • Jakiego rodzaju działanie na liczbach będzie miało miejsce i czy wiążą się z tym jakiekolwiek ograniczenia?
  • Jaki będzie zakres wprowadzanych liczb?
  • Jakiego typu zmienna przechowywać będzie wprowadzoną liczbę?
  • Czy wynik działania nie przekroczy zakresu wartości zdefiniowanego dla wybranego typu zmiennych, jak to sprawdzisz?
  • W jaki sposób użytkownik wprowadzi wartości reprezentujące docelowe liczby?
  • Jak zachowa się program w sytuacji, w której użytkownik nic nie wprowadzi lub wprowadzi śmieci?
  • Czy wprowadzona przez użytkownika wartość reprezentująca liczbę będzie typu całkowitego, czy wymagana będzie konwersja typów?
  • Czy zastosowana metoda konwersji typów zadziała w każdym możliwym przypadku?
  • Wiedząc, że metoda konwersji typów nie zadziała w każdym możliwym przypadku, jakie kroki podejmiesz aby uniknąć konieczności implementowania obsługi wyjątków?
  • W jaki sposób wyświetlisz wynik działania programu?
  • Czy konieczna będzie konwersja typów z typu całkowitego do obsługiwanego przez program typu wyjściowego?
  • Co zrobisz z wykorzystanymi przez program zasobami pamięci itp.

I skąd będziesz wiedział jak zachowa się Twój komputer jeżeli ten, oczekując wprowadzenia dwóch liczb, otrzyma od Ciebie liczbę i tekst? Jeżeli dobrze zaprojektujesz swój program, na pewno unikniesz nieprzyjemnych sytuacji. Starając się z marszu coś zaprogramować napytasz sobie tylko biedy.

Choć współczesne systemy i platformy programistyczne starają się oszczędzić Nam tego typu konsekwencji wadliwego działania oprogramowania to od Ciebie, młody adepcie sztuki programowania, zależy, którą drogę wybierzesz. A wyborów nie masz za wiele. Drogą gwałtownych napadów frustracji i horendalnych strat kroczy wielu Twoich kolegów i koleżanek. Pozostaje jeszcze ta druga - droga umiarkowanego wzrostu, bez kolorowych świecących okienek, ale jest to także droga stabilności finansowej i świętego spokoju, tym większego im bogatsza będzie Twoja wiedza i doświadczenie.

Jeśli zatem dopiero odkrywasz arkana bycia deweloperem i tak bardzo zachwycasz się funkcjonalnością zintegrowanych narzędzi programistycznych nie ograniczaj się wyłącznie do autouzupełniania kodu i naciśnij czasem stary, dobry klawisz F1. Może dowiesz się czegoś ciekawego. Czego Tobie i Nam wszystkim (tj. deweloperom) życzę. 

oprogramowanie programowanie

Komentarze

0 nowych
revcorey   6 #1 23.01.2012 13:57

Tajemnicą poliszynela jest to że teraz większość ludzi po studiach słabo sobie radzi z językami typu C/C++ a ostro idzie w Jave/.NET bo i wymagania co do umiejętności są mniejsze.

alucosoftware   7 #2 23.01.2012 14:15

Zgadzam się. Uważam także, że zarówno platforma .NET, Java jak i inne zostały utworzone po to aby przyspieszyć proces przygotowywania, testowania i wdrażania aplikacji. I problem ujęty we wpisie nie leży w tym czy innym języku a w Nas, deweloperach, młodych czy doświadczonych pragnących widowiskowych rezultatów przy niskim poziomie wiedzy z danego zakresu...

  #3 23.01.2012 14:20

Naprawdę ciężko jest porównać do siebie w nowoczesny samochód z komputerem pokładowym (.NET/Java) do czołgu T-74 Twardy (ANSI C/ C++). Oba to pojazdy, ale służą innym zadaniom.

Jestem po studiach, na który pisałem w Vim-ie i kompilowałem programu via gcc a od paru dobrych lat zawodowo zajmuję się językami wysokiego poziomu -.NET, Ruby, JS. Programowania można nauczyć się na dowolnym języku.

Gdybym miał napisać wysokowydajny serwer telekomunikacyjny to w dzisiejszych czasach jest kilka podejść: szybki kod w c++, wieloinstancyjny/wielodomenowy np w .NET-cie lub superskalowalny wieloserverowy w chmurze np.: na Azurze. Kwestia potrzeb i wyboru narzędzia.

Drugorzędną sprawą jest to, że studenci 'wolą' Javę i .NET. Wystarczy sprawdzić ilość ofert pracy, żeby zauważyć olbrzymią dysproporcję pomiędzy ANSI C/C++ a językami kodu pośredniego (.NET, Java)

  #4 23.01.2012 14:20

" a ostro idzie w Jave/.NET bo i wymagania co do umiejętności są mniejsze."

Chyba chodziło Ci o próg startu (wiedza potrzebna do tego żeby zacząć), bo wymagania co do umiejętności są według mnie porównywalne.

Mantarak   3 #5 23.01.2012 14:29

@revcorey
Zgadzam się. Wspólczesny program nauczania w szkołach uczy rozwiązywania testów (no bo oceny nie mogą zależeć od widzimisię nauczyciela). Kalkulatory oduczają liczenia w pamięci. Google oducza zapamiętywania czegokolwiek (no bo po co jak se zaraz znajdę). Logika myślenia to pojęcie nieznane w szkołach. Najlepiej zakuć, zdać i zapomnieć itd. Efekty są takie jak piszesz.

revcorey   6 #6 23.01.2012 14:33

Tak jest dużo ofert java/.net tylko że tu chodzi o czas, łatwiej dołożyć do serwera trochę ramu i procków niż przepisywać z javy ee na c++. Podobnie na PC łatwiej dziergać na wysokopoziomowych językach bo taniej i szybciej, klepaczy .net za 2000 zł masz pełno. Ale im czas odpowiedzi ważniejszy tym więcej języków wysoko poziomowych odpada i jak się zaczynają nieodpowiedni ludzie za to brać to jest źle. Świetnym przykładem niech będzie gadu gadu 10, dobry framework qt4 + c++ i powinno iść żwawo a zatrudnili do pisania tego byle kogo(pewnie przyszli ludzie co wcześniej pisali w .net/java) i wyszło jak wyszło, już mogli to gg napisać w javie/.net to by przynajmniej program lepiej pamięcią zarządzał. Po prostu migracja na jave/.net wynika z oszczędności. Sam używam Eclipse CDT i działa dość szybko i czemu nie może być, ale chodzi o to że po prostu pójście tylko w jave/.net wychowuje miernoty(nieujmująca nic dobrym programistą java/.net)

revcorey   6 #7 23.01.2012 14:42

PS. Przepraszam za błędy składniowe ale siedzę nad takim jednym małym projektem :)

jullo89   3 #8 23.01.2012 14:53

To zależy o kim mówimy: studenci nie programują - piszą projekty żeby zaliczyć przedmiot, nauczyć się czegoś nowego.
Programista tworzy programy do użytkowania. Różnica jest zasadnicza, ponieważ na studiach nikt nie testuje pełnej funkcjonalności, odporności programu na działania użytkownika a tym bardziej wydajności.
Jeżeli chodzi o programowanie niezależnie czy w C/C++, Java, czymkolwiek innym trzeba znać język, algorytmy ale naprawdę dobrze planować, myśleć, testować, myśleć i pisać.

A co do rzeczywistości i znawców C/C++, którzy uważają te języki za najlepsze i najdoskonalsze to też nie jest tak pięknie i uroczo - jeżeli system jest potrzebny na "jutro" to raczej szybciej będzie w Javie lub C# lub Pythonie i taniej będzie kupić nowszy sprzęt niż płacić za nadgodziny programistów.

revcorey   6 #9 23.01.2012 15:03

jullo89 nie wiem jak ty ale ja jak miałem 16 lat to dziergałem sobie i testowałem sam aplikację(w php,c++ czy javie) i robiłem to dla własnej przyjemności, na studiach się uczyłem sam avr w C programować w każdym razie sam się rozwijam i nie widzę problemu aby w wolnej czasie student pisał, co więcej to jest właśnie esencja studiów o której dziś zapomniano.

soanvig   9 #10 23.01.2012 16:03

@revcorey

"Podobnie na PC łatwiej dziergać na wysokopoziomowych językach bo taniej i szybciej,"
Czyli sugerujesz, że wysokopoziomowe języki są gorsze od niskopoziomowych? Pomijając ograniczenia w dokładnym sterowaniu np. pamięcią komputera, to co jest w nich gorszego?

Dimatheus   21 #11 23.01.2012 16:20

Hej,

Skąd ja pamiętam ten screen z błędem? Już wiem - pojawiały się na Amidze, gdy dyskietka bądź sama gra była uszkodzona. Powiało starymi czasami.

Z treścią wpisu też zgadzam się w 100%. Czasami trzeba więcej czasu, by wyłapać wszystkie błędy. Sam tworzę w pracy raporty sprzedażowe i wiem, ile czasu zajmuje samo projektowanie raportu. A po nim i tak przychodzi okres testowy, w którym najczęściej też pojawiają się pomniejsze błędy, których wcześniej na przykład nie sposób było przewidzieć. Cierpliwość i skrupulatność jest więc kluczem do sukcesu. :)

Pozdrawiam,
Dimatheus

alucosoftware   7 #12 23.01.2012 16:39

@Dimatheus

Tak, stare, zacne czasy amigowego świata...

Wekmyr   4 #13 23.01.2012 22:52

@revcorey nie sztuka jest program napisać. Sztuka jest go utrzymać, rozbudowywać. W których po latach inni programiści będą potrafili się odnaleźć i go rozbudować.

Draqun   9 #14 16.02.2012 02:10

Widzę banda wyjadaczy się wypowiada :)

@jullo89
"To zależy o kim mówimy: studenci nie programują - piszą projekty żeby zaliczyć przedmiot, nauczyć się czegoś nowego."

Bzdury. Mój ostatni program na zaliczenie, który oddawałem przeszedł obsługę kilku osób, w tym zwykłych klikaczy. Miałem raz przyjemność oddawać projekt, gdzie nauczyciel usiadł i zaczął klikać dowolne klawisze i patrzał co się dzieje. Czy twierdzisz że program odporny na takie klikani został tylko napisany? Bo trochę czasu spędziłem nad tym aby zabezpieczyć go przed wywaleniem się z powodu głupoty użytkownika. Na pierwszym roku studiów ucząc się pisać programy zawsze słyszałem "Program będzie sprawdzać głupia blondynka, jak jej się wysypie i nie będzie zadowolona to dostaniesz 2". Poza tym zdarza mi się pisać całe programy zupełnie od zera gdy nie jestem zadowolony z algorytmu jaki użyłem pierwotnie i nie robię tego dla kogoś tylko sam dla siebie.

Ostatnio pomimo sesji postanowiłem sięgnąć po JAVĘ. Tak czy siak gdy się skończy sesja będę musiał się go nauczyć, więc czemu nie teraz. Jako zagorzały fan C\C++ (ale chyba bardziej C) byłem w szoku tym co zobaczyłem. Oczywiście do wszystkiego da się przyzwyczaić ale brakuje mi takich rzeczy jak praca na wskaźnikach. Pozwalało mi to na dokładną kontrolę tego co siedzi mi w pamięci czy ilości kopii danej zmiennej. Poza tym musiałem zrezygnować z ulubionego IDE jakim jest CodeBlocks ponieważ nie znalazłem nic jak zmusić go do pracy z JWM.

Poza tym dość popularne jest powiedzenie , że "Okienko to każdy głupi potrafi stworzyć a dobry algorytm już nie". Jest w tym ziarno sporej prawdy ale przez to tematów tworzenia aplikacji okienkowych w każdym razie u mnie na wykładzie było mało a i w sieci nie ma za wiele. Niby mamy specyfikację producentów, jednak z nich się nie nauczysz programować. Tam można się dowiedzieć jak dana funkcja działa, co dostaje i co zwraca ale sama idea programowania zdarzeniowego nie jest przekazywana. Ja GTK uczyłem się z książki z roku 1995, a w zasadzie nie GTK a idei programowania zdarzeniowego, bo jak się okazało książka opowiadała o GTK 1.2 a mamy już 3. Poza tym w sieci prawie nie istnieją pełne kursy programowania z wykorzystaniem bibliotek odpowiedzialnych za GUI (a w każdym razie nie w naszym ojczystym języku (kiedyś próbował coś tworzyć blindol tutaj na blogu ale skończyło się na jednym wpisie)) przez co stworzenie aplikacji z jakimiś fajnymi widgetami jest trudnym i żmudnym zadaniem ponieważ trzeba przetłumaczyć z angielskiego na polski, z polskiego na swoje i jeszcze to zrozumieć. A jak informacje są przestarzałe to trzeba jeszcze szukać w dokumentacji na co dana funkcja została zamieniona i jak z tego korzystać, ponieważ nie wszystko jest takie znów oczywiste. Oczywiście algorytmika jest jedną z najważniejszych nauk w programowaniu ale zaniedbuje się nauki paradygmatów jedynie wspominając o nich.

Tak na boku chciałbym dowiedzieć jak tworzy się bibliotekę do tworzenia GUI za pomocą C\C++ jednak nie istnieje na ten temat w sieci prawie nic, uczący na studiach tego nie wiedzą/nie mają czasu i nie chcą bo pracują na umowę-zlecenie.