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?

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:

1. 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ć .
2. 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:

1. Nie dodawaj nowych problemów.
2. 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”.

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ń.

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:

1. 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.
2. Ponieważ nie masz teraz ostrzeżeń (najprawdopodobniej na niskim poziomie ostrzeżenia), przełącz przełącznik i traktuj wszystkie ostrzeżenia jako błędy.
3. 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 .