Nie tylko zmiennoprzecinkowe sprawy powodują problemy. Są też błędy wynikające z niepoprawnego wykonywania działań np. liczba double 1.5 zrzutowana jawnie na int wynosi 1 i środowisko nie zgłosi tu błędu, ponieważ jest to jawne rzutowanie i IDE zakłada, że wykonuje się je z pełną świadomością, a i często takie rzutowania polegające na obcięciu części liczby są przydatne i powszechnie stosowane, więc same w sobie nie są błędem programistycznym, ale jeśli wykonane bez
@Lechu1777: mała uwaga: "Więc wybór dużego typu do małej danej jest nieoptymalny," to jeszcze zależy od architektury i celów, nowe (czyli już stare procki) przy wyborze małej danej i tak stosują wyrównanie do słowa (nawet ARM) i dla takiej małej czy dużej i tak jest jedna transakcja do pamięci (sprawy cache pomijam). Generalnie masz rację i tu jeszcze dochodzi czynnik ludzki - programiści ci słabsi mają w dupie albo nie mają
maszyna uległa awarii, wyświetlając komunikat o błędzie i niepodjęciu naświetlania. Operator, przyzwyczajony do humorów urządzenia, wymusił wykonanie procedury.
@ostatni_i_sprawiedliwy jeżeli co chwila sypala błędami, dała informacje że nie naswietlała a w rzeczywistości to zrobiła to czyja wina? Owszem, operator mógł przerwać zabieg, wezwać techników, poczekać kilka tygodni a w tym czasie kolejka czekających na naświetlanie rośnie
@ostatni_i_sprawiedliwy: Nawet nie zachciałeś sprawdzić o czym rozmawiasz a się rozpisujesz.
Jeśli wymusił - to były tam mechanizmy zmuszenia urządzenia do wykonania czegoś POMIMO ALARMÓW. Jeśli takie były - skądś musiały się wziąć.
Nie alarmów tylko błędów, a tych maszyna miała 2 rodzaje, nazwijmy je zwykłym i krytycznym. Błąd zwykły wymagał wciśnięcia jednego przycisku na klawiaturze po czym maszyna resetowała się i była zdolna do dalszej pracy, błąd krytyczny wymagał resetu
@tarrin: Myślisz, że kadrę zarządzającą obchodzą jakieś praktyki czystego kodu? Ma działać i to jak najszybciej i tyle. Zresztą do niedawna praktyką było zlecanie pracy zdalnie Hindusom, więc o jakich testach tu mowa.
Co za #!$%@? logika winny programista za to że trzymali je 100h zamiast 8 to tak jakby obwiniac producenta noża że klient sam się dzgnal XD a nawet jeszcze bardziej absurdalne
@Krafti: bo wiesz, dev powinien przewidzieć że user trzyma nóż za ostrze, właśnie dla takich wysrywów są te wszystkie debilne ostrzeżenia w stylu "nie rób tostów w kąpieli, bo ci prąd przypierdzieli".
@Krafti: to nie do konca trafna analogia. Dzialanie noza jest dosyc oczywiste. Dzialanie oprogramowania nie zawsze jest przewidywalne. Stad tez kilkadziesiat lat rozwoju calych dziedzin zapobiegania nieprzewidzianym sytuacjom
Komentarze (101)
najnowsze
Generalnie masz rację i tu jeszcze dochodzi czynnik ludzki - programiści ci słabsi mają w dupie albo nie mają
czy to aby błąd programisty a nie operatora?
Nie alarmów tylko błędów, a tych maszyna miała 2 rodzaje, nazwijmy je zwykłym i krytycznym. Błąd zwykły wymagał wciśnięcia jednego przycisku na klawiaturze po czym maszyna resetowała się i była zdolna do dalszej pracy, błąd krytyczny wymagał resetu
ta, ciekawe...
Nie no, wcale.
Po to się testy pisze. No, ale jak programiści są z łapanki...
CIO w tym głowa, żeby to wytłumaczyć. Jeżeli uważa, że testy są niepotrzebne to rzeczony CIO jest dupa.
Z doświadczenia ci powiem, że pisanie testów równolegle z kodem produkcyjnym(a jeszcze lepiej, używając TDD) skraca czas wytworzenia oprogramowania.
Hindusom
Mówili o tym na studiach xd