Czy dobrą praktyką jest unikanie ostrzeżeń i powiadomień?

Zasadniczo pracuję z ostrzeżeniami i powiadomieniami PHP, ponieważ pracuję nad wieloma projektami, w których jest to już produkcja na żywo. Teraz, jeśli włączę ostrzeżenia i powiadomienia na tych stronach z produkcją na żywo, zostaną one przeciążone.

W projektach, nad którymi pracuję w domu, na poziomie lokalnym, zwykle staram się usunąć WSZYSTKIE ostrzeżenia i powiadomienia. Czasami nie ma rozwiązania, aby nie otrzymywać powiadomienia, więc musiałbym się z nim zapoznać, dopóki nie zdecyduję się ich całkowicie wyłączyć.

W końcu nie wiem, czy marnuję czas, próbując pozbyć się wszystkich ostrzeżeń i powiadomień, czy też robię to dla większego dobra.

Stąd moje pytanie: czy dobrą praktyką jest unikanie ostrzeżeń i powiadomień w ogóle, czy to naprawdę nie ma znaczenia?

php warnings

— Audite Marlow
źródło

„Czasami nie ma rozwiązania, aby nie otrzymywać powiadomienia” Minęło trochę czasu, odkąd korzystałem z PHP, ale nie przypominam sobie, aby wpadać na przypadki, w których można uniknąć powiadomienia / ostrzeżenia lub przynajmniej ukryć je lokalnie@ .

— CodesInChaos

Najbardziej przekonujący argument, jaki widziałem, to „te wiadomości istnieją z jakiegoś powodu - uzależnienie się od zignorowania powodzi ostrzeżeń powoduje, że przeoczamy rzeczywiste problemy, których można było uniknąć”. Innymi słowy, jeśli nie ma ostrzeżeń ani powiadomień podczas normalnej pracy, każde ostrzeżenie lub zawiadomienie jest oznaką potencjalnego problemu; jeśli wszystko jest tylko hałasem, problemy zaczniesz zauważać dopiero po SHTF (i prawdopodobnie po tym, jak zrobią to klienci).

— Piskvor,

Używanie @ do tłumienia powiadomień, chociaż jest powszechne, jest ogólnie uważane za złą rzecz. Gorzej niż po prostu wyłączyć wszystkie powiadomienia, ponieważ ukryłeś potencjalny problem. W ciągu 15 lat programowania PHP nie spotkałem się jeszcze z przypadkiem, w którym musiałem ukryć powiadomienie w kodzie, który kontroluję.

— Cerad

Czy po prostu wyłączasz wyświetlanie tych powiadomień, czy robisz error_reporting(0);? Zawsze używam error_reporting(E_ALL);a jedyna różnica między rozwoju i produkcji jest ini_set('display_errors', 'on');kontra ini_set('display_errors', 'off');. Zawsze staram się naprawiać powiadomienia i ostrzeżenia, gdy kod wciąż jest w mojej głowie. Często loguję się w moim systemie produkcyjnym, aby zobaczyć, czy są jakieś dodatkowe ostrzeżenia i powiadomienia, które mogłem przeoczyć.

— MonkeyZeus

Bardzo zgadzam się z tym, co powiedział @Cerad @. Po latach programowania PHP nie używałem tego operatora. Nigdy. Nigdy. Nie tylko ukrywa potencjalne problemy, ale ma także wpływ na wydajność: za kulisami PHP wyłącza raportowanie błędów przed wywołaniem kodu -> wywołuje kod -> przywraca mu pierwotną wartość. Kroki te są drogie, jeśli masz kilkadziesiąt lub kilkaset @kodów.

— Radu Murzea

Odpowiedzi:

jeśli włączę ostrzeżenia i powiadomienia na tych stronach internetowych z produkcją na żywo, zostaną one przeciążone.

Zawsze należy mieć włączone ostrzeżenia na najwyższym poziomie podczas opracowywania, testowania i zapewniania jakości, ale nie podczas produkcji. W rzeczywistości, jeśli jest to aplikacja do karmienia psów, tj. Aplikacja, z której korzystasz sam, to powinieneś również włączyć je w produkcji.

Zasadniczo: włącz je w tych przypadkach, w których osoba, która je widzi, jest w stanie coś z tym zrobić (programista w fazie rozwoju i testów może je naprawić samodzielnie, tester w kontroli jakości może zgłosić błąd, a jeśli programista jest także użytkownik, wtedy może również naprawić to w produkcji), ale nie włączaj ich, gdy osoba, która widzi, nie może nic z tym zrobić (użytkownik w produkcji, który nawet nie umie programować).

Idealnie byłoby również włączyć włączanie traktowania ostrzeżeń jako błędów, ale działa to tylko wtedy, gdy nie ma ich na początku ;-) Ale pamiętaj o tym jako celu! Jeśli jest możliwe włączenie / wyłączenie tego dla poszczególnych plików, włącz je dla wszystkich nowych plików i włącz dla wszystkich plików wolnych od ostrzeżeń i nigdy nie wyłączaj go ponownie po włączeniu.

Co więc zrobić z przeciążeniem?

Tworzysz listę każdego ostrzeżenia i powiadomienia, a następnie przestrzegasz następujących zasad:

Nigdy, nigdy, w żadnym wypadku nie dodawaj nowego ostrzeżenia do listy. Każdy nowy fragment kodu, każda edycja, każda zmiana, każda łatka, każde zatwierdzenie nie może wprowadzać nowych ostrzeżeń, może je tylko naprawić .
Za każdym razem, gdy dotkniesz fragmentu kodu, napraw wszelkie ostrzeżenia w tym fragmencie kodu. (Zasada Boyscout: zawsze opuszczaj kemping w lepszym stanie, niż go znalazłeś). W ten sposób nieistotny kod może pozostać pełen ostrzeżeń, ale ważny kod z czasem stanie się czystszy. „Kawałek kodu” może być funkcją, klasą, plikiem. Możesz także złagodzić tę zasadę, aby powiedzieć, że naprawia co najmniej jedno ostrzeżenie. Chodzi o to: napraw je tak, jak je znajdziesz.

Uwaga: oba wymagają posiadania bazy danych dziennika i mechanizmu filtrowania dzienników. Zauważ też, że „baza danych dziennika” i „mechanizm filtrowania dziennika” może być po prostu plikiem tekstowym i grep.

To jest ważny kawałek. Bez bazy danych nie będziesz wiedział, kiedy dodasz nowe ostrzeżenie, a bez filtrowania nadal będziesz mieć problem z przeciążeniem.

Uwaga 2: działa to nie tylko w przypadku ostrzeżeń, ale także w przypadku sprawdzania stylu, wskaźników złożoności, pokrycia kodu, narzędzi analizy statycznej i tak dalej. Gruntownie:

Nie dodawaj nowych problemów.
Napraw stare problemy, gdy się na nie natkniesz.

Pozwala to na łatwe ustalanie priorytetów: kod, który jest często edytowany, a zatem musi być łatwy do odczytania i obsługi, z czasem będzie lepszy. Kod, który nie jest często zmieniany, nie poprawi się, ale jest w porządku, ponieważ i tak nikt nie musi na niego patrzeć. I przynajmniej nie będzie gorzej.

Oczywiście nic nie stoi na przeszkodzie, aby poświęcić czas specjalnie na to, aby zrobić tylko polowanie i zabić ostrzeżenia. Często zdarza się, że nie jest to ekonomicznie opłacalne i należy o tym pamiętać jako inżynier. „Inżynier to taki, który potrafi zbudować za dolara, co każdy głupiec może zbudować za pomocą dwóch”.

— Jörg W Mittag
źródło

Kolejna kwestia, dlaczego należy wyłączyć ostrzeżenia i błędy, które docierają do użytkownika niefiltrowane: tak pouczające jak ostrzeżenie dla dewelopera, może wyciec wrażliwe informacje (nazwy plików, nazwy innych zaangażowanych serwerów, struktura używanych zapytań sql, ... )

— Hagen von Eitzen

Ostrzeżenia podczas produkcji powinny trafiać do dzienników, a nie do użytkownika! Błędy powinny trafiać do dzienników, a nie do użytkownika. Witryna, która nie wychwytuje błędów, nie rejestruje ich i nie wyświetla strony odpowiedniej dla użytkownika, nie jest jeszcze gotowa do produkcji. PHP sprawia, że bardzo łatwo jest to zrobić źle, ale nadal powinieneś robić to dobrze.

— hobbs

Jeśli ostrzeżenia i powiadomienia pochodzą z Twojego kodu, zdecydowanie to napraw. Z mojego doświadczenia wynika, że w 95% może to być łagodne, ale 5% podkreśla prawdziwy problem, który może prowadzić do niezliczonych godzin pogoni.

Jeśli pochodzą z kodu innej firmy, którego musisz użyć z jednego lub drugiego powodu, zazwyczaj nie masz dużego wyboru.

To jest inne pytanie, czy twoja starsza baza kodów jest naprawdę duża, możesz traktować starszy kod jako firmę zewnętrzną, ale wymagać, aby nowy kod był wolny od ostrzeżeń.

— Alexander Pogrebnyak
źródło

Pracuję w Javie / eclipse, które oczywiście różni się od php, ale zwykle uważam, że ostrzeżenie jest zgłaszane przez 1) coś, co się kompiluje, ale popełniłem oczywisty błąd, lub 2) coś, co jest w porządku, ale będzie źle na drodze

— corsiKa

@corsiKa I został tłumaczenia komentarz do PHP, ale zdałem sobie sprawę, że tylko jedno słowo należało zmienić.

— wizzwizz4

Chyba że te ostrzeżenia pochodzą od StyleCop, dotyczące kolejności twoich usingoświadczeń ...

— Dan Pantry

To ma znaczenie. Ostrzeżenie może nie przerwać twoich testów, a nawet pojawić się na chwilę na wolności - ale może to być objaw zbliżającego się błędu. Obecnie rozwijam się głównie w C # / C ++ i mam określoną strategię, aby pozbyć się ostrzeżeń z naszej bazy kodu. Na szczęście nie jest to nauka o rakietach =).

Jeśli język, w którym pracujesz, może traktować ostrzeżenia jako błędy i ma różne poziomy ostrzeżeń, zrobiłbym następujące czynności:

Obniż poziom ostrzegawczy na tyle, aby nie pojawiały się żadne ostrzeżenia. Jeśli masz najniższy poziom ostrzeżeń i nadal otrzymujesz ostrzeżenia - spróbuj je naprawić. Jeśli nie możesz ich naprawić, to na razie gotowe, ale mam nadzieję, że możesz je naprawić. Świetny.
Ponieważ nie masz teraz ostrzeżeń (najprawdopodobniej na niskim poziomie ostrzeżenia), przełącz przełącznik i traktuj wszystkie ostrzeżenia jako błędy.
Spróbuj podnieść poziom ostrzeżeń i naprawić wszystkie nowe ostrzeżenia. Jeśli nie możesz, zmniejsz poziom ostrzeżenia z powrotem, ale nie wyłączaj ostrzeżeń jako błędów.

Uważam, że to nie tylko działa ostrzeżenia poza moim kodem - to trzyma je z dala .

— PerryC
źródło