10 najczęstszych błędów popełnianych przez programistów internetowych: samouczek dla programistów

Opublikowany: 2022-03-11

Od czasu, gdy w 1990 roku ukuto termin World Wide Web, tworzenie aplikacji internetowych ewoluowało od obsługi statycznych stron HTML do całkowicie dynamicznych, złożonych aplikacji biznesowych.

Dziś dysponujemy tysiącami zasobów cyfrowych i drukowanych, które zawierają instrukcje krok po kroku dotyczące tworzenia wszelkiego rodzaju różnych aplikacji internetowych. Środowiska programistyczne są wystarczająco „inteligentne”, aby wyłapać i naprawić wiele błędów, z którymi regularnie walczyli wcześni programiści. Istnieje nawet wiele różnych platform programistycznych, które z łatwością przekształcają proste statyczne strony HTML w wysoce interaktywne aplikacje.

Wszystkie te wzorce, praktyki i platformy programistyczne mają wspólną płaszczyznę i wszystkie są podatne na podobne problemy związane z tworzeniem stron internetowych, spowodowane samą naturą aplikacji internetowych.

Celem tych wskazówek dotyczących tworzenia stron internetowych jest rzucenie światła na niektóre z typowych błędów popełnianych na różnych etapach procesu tworzenia stron internetowych i pomoc w staniu się lepszym programistą. Poruszyłem kilka ogólnych tematów, które są wspólne dla praktycznie wszystkich twórców stron internetowych, takich jak walidacja, bezpieczeństwo, skalowalność i SEO. Oczywiście nie powinieneś być związany konkretnymi przykładami, które opisałem w tym przewodniku, ponieważ są one wymienione tylko po to, aby dać ci wyobrażenie o potencjalnych problemach, które możesz napotkać.

Powszechny błąd nr 1: Niepełna weryfikacja danych wejściowych

Weryfikacja danych wejściowych użytkownika po stronie klienta i serwera jest po prostu koniecznością ! Wszyscy znamy mądrą radę „nie ufaj wkładowi użytkownika” , ale mimo to błędy wynikające z walidacji zdarzają się zbyt często.

Jedną z najczęstszych konsekwencji tego błędu jest SQL Injection , który rok po roku znajduje się w Top 10 OWASP.

Pamiętaj, że większość front-endowych frameworków programistycznych zapewnia gotowe reguły walidacji, które są niezwykle proste w użyciu. Ponadto większość głównych platform programistycznych zaplecza używa prostych adnotacji, aby zapewnić, że przesłane dane są zgodne z oczekiwanymi regułami. Wdrożenie walidacji może być czasochłonne, ale powinno być częścią standardowej praktyki kodowania i nigdy nie odkładać na bok.

Powszechny błąd nr 2: Uwierzytelnianie bez odpowiedniej autoryzacji

Zanim przejdziemy dalej, upewnijmy się, że jesteśmy wyrównani w tych dwóch warunkach. Jak stwierdzono w 10 najczęstszych lukach w zabezpieczeniach sieci Web:

Uwierzytelnianie: Weryfikacja, czy dana osoba jest (lub przynajmniej wydaje się być) określonym użytkownikiem, ponieważ poprawnie podała swoje dane uwierzytelniające (hasło, odpowiedzi na pytania zabezpieczające, skanowanie odcisków palców itp.).

Autoryzacja: Potwierdzenie, że określony użytkownik ma dostęp do określonego zasobu lub ma uprawnienia do wykonania określonej akcji.

Innymi słowy, uwierzytelnianie to wiedza, kim jest podmiot, podczas gdy autoryzacja to wiedza, co dany podmiot może zrobić.

Pozwolę sobie zademonstrować ten problem na przykładzie:

Weź pod uwagę, że Twoja przeglądarka przechowuje informacje o aktualnie zalogowanym użytkowniku w obiekcie podobnym do następującego:

 { username:'elvis', role:'singer', token:'123456789' }

Podczas zmiany hasła aplikacja wykonuje POST:

 POST /changepassword/:username/:newpassword

W metodzie /changepassword sprawdzasz, czy użytkownik jest zalogowany, a token nie wygasł . Następnie znajdujesz profil użytkownika oparty na parametrze :username i zmieniasz hasło użytkownika.

Więc potwierdziłeś, że twój użytkownik jest poprawnie zalogowany, a następnie wykonałeś jego żądanie, zmieniając w ten sposób jego hasło. Proces wydaje się OK, prawda? Niestety odpowiedź brzmi NIE!

W tym momencie ważne jest, aby sprawdzić, czy użytkownik wykonujący akcję i użytkownik, którego hasło zostało zmienione, są tacy sami. Wszelkie informacje przechowywane w przeglądarce można manipulować, a każdy zaawansowany użytkownik może łatwo zmienić username:'elvis' na username:'Administrator' bez używania niczego poza wbudowanymi narzędziami przeglądarki.

W tym przypadku po prostu zajęliśmy się Authentication , upewniając się, że użytkownik podał dane uwierzytelniające. Możemy nawet dodać walidację, że metoda /changepassword może być wykonana tylko przez Authenticated użytkowników. Jednak to wciąż nie wystarczy, aby chronić użytkowników przed złośliwymi próbami.

Musisz upewnić się, że w metodzie /changepassword zweryfikowałeś rzeczywistego żądającego i treść żądania oraz zaimplementowałeś odpowiednią Authorization żądania, upewniając się, że użytkownik może zmienić tylko swoje dane.

Authentication i Authorization to dwie strony tego samego medalu. Nigdy nie traktuj ich oddzielnie.

Powszechny błąd nr 3: Brak gotowości do skalowania

W dzisiejszym świecie szybkiego rozwoju, akceleratorów startupów i natychmiastowego globalnego zasięgu świetnych pomysłów, wprowadzenie MVP (minimalnie opłacalnego produktu) na rynek tak szybko, jak to możliwe, jest wspólnym celem wielu firm.

Jednak ta ciągła presja czasu powoduje, że nawet dobre zespoły programistów często przeoczają pewne problemy. Skalowanie jest często jedną z tych rzeczy, które zespoły przyjmują za pewnik. Koncepcja MVP jest świetna, ale przesadzaj, a będziesz mieć poważne problemy. Niestety wybór skalowalnej bazy danych i serwera WWW oraz rozdzielenie wszystkich warstw aplikacji na niezależne skalowalne serwery to za mało. Jest wiele szczegółów, o których musisz pomyśleć, jeśli chcesz uniknąć późniejszego przepisywania znaczących części swojej aplikacji – co staje się głównym problemem przy tworzeniu stron internetowych.

Załóżmy na przykład, że decydujesz się przechowywać przesłane zdjęcia profilowe użytkowników bezpośrednio na serwerze sieciowym. Jest to idealne rozwiązanie — pliki są szybko dostępne dla aplikacji, metody obsługi plików są dostępne na każdej platformie programistycznej, a nawet możesz wyświetlać te obrazy jako zawartość statyczną, co oznacza minimalne obciążenie aplikacji.

Ale co się stanie, gdy Twoja aplikacja się rozrośnie i będziesz potrzebować korzystać z dwóch lub więcej serwerów WWW za load balancerem? Nawet jeśli dobrze skalowałeś pamięć masową bazy danych, serwery stanu sesji i serwery WWW, skalowalność aplikacji zawodzi z powodu prostej rzeczy, takiej jak obrazy profilu. Dlatego musisz zaimplementować jakiś rodzaj usługi synchronizacji plików (która będzie miała opóźnienie i spowoduje tymczasowe błędy 404) lub inne obejście, aby zapewnić rozproszenie plików na twoich serwerach internetowych.

To, co trzeba było zrobić, aby przede wszystkim uniknąć problemu, to po prostu użyć współdzielonej lokalizacji przechowywania plików, bazy danych lub dowolnego innego rozwiązania do zdalnego przechowywania. Zaimplementowanie tego wszystkiego kosztowałoby prawdopodobnie kilka dodatkowych godzin pracy, ale byłoby to warte zachodu.

Częsty błąd nr 4: Nieprawidłowe lub brakujące SEO

Podstawową przyczyną nieprawidłowych lub brakujących najlepszych praktyk SEO na stronach internetowych są nieprawdziwe informacje „specjalistów SEO”. Wielu twórców stron internetowych uważa, że ​​wiedzą wystarczająco dużo o SEO i że nie jest to szczególnie skomplikowane, ale to po prostu nieprawda. Mistrzostwo SEO wymaga dużo czasu spędzonego na badaniu najlepszych praktyk i ciągle zmieniających się zasad indeksowania sieci przez Google, Bing i Yahoo. O ile nie stale eksperymentujesz i nie masz dokładnego śledzenia + analizy, nie jesteś specjalistą od SEO i nie powinieneś się nim twierdzić.

Co więcej, SEO jest zbyt często odkładane na później jako część czynności wykonywanych na końcu. Ma to wysoką cenę problemów związanych z tworzeniem stron internetowych. SEO nie dotyczy tylko ustawiania dobrej treści, tagów, słów kluczowych, metadanych, znaczników alternatywnych obrazów, mapy witryny itp. Obejmuje to również eliminację duplikatów treści, posiadanie architektury witryny do indeksowania, wydajne czasy ładowania, inteligentne łączenie wsteczne itp.

Podobnie jak w przypadku skalowalności, powinieneś pomyśleć o SEO od momentu rozpoczęcia budowy aplikacji internetowej lub może się okazać, że ukończenie projektu wdrożenia SEO oznacza przepisanie całego systemu.

Powszechny błąd nr 5: Działania pochłaniające czas lub procesor w procedurach obsługi żądań

Jednym z najlepszych przykładów tego błędu jest wysyłanie wiadomości e-mail na podstawie działania użytkownika. Zbyt często programiści uważają, że rozwiązaniem jest wykonanie połączenia SMTP i wysłanie wiadomości bezpośrednio z programu obsługi żądań użytkownika.

Załóżmy, że stworzyłeś księgarnię online i spodziewasz się, że będziesz codziennie składać kilkaset zamówień. W ramach procesu przyjmowania zamówień wysyłasz wiadomości e-mail z potwierdzeniem za każdym razem, gdy użytkownik opublikuje zamówienie. Na początku będzie to działać bez problemu, ale co się stanie, gdy skalujesz swój system i nagle otrzymasz tysiące żądań wysyłających e-maile potwierdzające? Otrzymujesz limity czasu połączenia SMTP, przekroczony limit lub czas odpowiedzi aplikacji znacznie się skróci, ponieważ teraz obsługuje ona wiadomości e-mail zamiast użytkowników.

Wszelkie działania pochłaniające czas lub procesor powinny być obsługiwane przez proces zewnętrzny, podczas gdy Twoje żądania HTTP są zwalniane tak szybko, jak to możliwe. W takim przypadku powinieneś mieć zewnętrzną usługę wysyłkową, która odbiera zamówienia i wysyła powiadomienia.

Powszechny błąd nr 6: brak optymalizacji wykorzystania przepustowości

Większość prac programistycznych i testowych odbywa się w środowisku sieci lokalnej. Tak więc, gdy pobierasz 5 obrazów tła, z których każdy ma 3 MB lub więcej, możesz nie zidentyfikować problemu z prędkością połączenia 1 Gbit w swoim środowisku programistycznym. Ale kiedy Twoi użytkownicy zaczną ładować stronę główną 15 MB przez połączenia 3G na swoich smartfonach, powinieneś przygotować się na listę skarg i problemów.

Optymalizacja wykorzystania przepustowości może dać ci świetny wzrost wydajności, a aby go uzyskać, prawdopodobnie potrzebujesz tylko kilku sztuczek. Jest kilka rzeczy, które wielu dobrych programistów robi domyślnie, w tym:

  1. Minifikacja wszystkich JavaScript
  2. Minifikacja wszystkich CSS
  3. Kompresja HTTP po stronie serwera
  4. Optymalizacja rozmiaru i rozdzielczości obrazu

Powszechny błąd nr 7: brak rozwoju dla różnych rozmiarów ekranu

Projektowanie responsywne było dużym tematem w ciągu ostatnich kilku lat. Ekspansja smartfonów z różnymi rozdzielczościami ekranu przyniosła wiele nowych sposobów uzyskiwania dostępu do treści online, co wiąże się również z wieloma problemami związanymi z tworzeniem stron internetowych. Liczba odwiedzin stron internetowych pochodzących ze smartfonów i tabletów rośnie każdego dnia, a trend ten przyspiesza.

Aby zapewnić bezproblemową nawigację i dostęp do zawartości witryny, musisz umożliwić użytkownikom dostęp do niej ze wszystkich typów urządzeń.

Istnieje wiele wzorców i praktyk tworzenia responsywnych aplikacji internetowych. Każda platforma programistyczna ma swoje własne wskazówki i triki, ale istnieją pewne frameworki, które są niezależne od platformy. Najpopularniejszym jest prawdopodobnie Twitter Bootstrap. Jest to otwarta i bezpłatna struktura HTML, CSS i JavaScript, która została przyjęta przez każdą większą platformę programistyczną. Po prostu zastosuj się do wzorców i praktyk Bootstrap podczas tworzenia aplikacji, a otrzymasz responsywną aplikację internetową bez żadnych problemów.

Częsty błąd nr 8: Niezgodność różnych przeglądarek

Proces rozwoju jest w większości przypadków pod dużą presją czasu. Każda aplikacja musi zostać wydana tak szybko, jak to możliwe, a nawet dobrzy twórcy stron internetowych często koncentrują się na dostarczaniu funkcjonalności, a nie na projektowaniu. Niezależnie od tego, że większość programistów ma zainstalowane Chrome, Firefox, IE, używają tylko jednego z tych 90% czasu. Powszechną praktyką jest używanie jednej przeglądarki podczas tworzenia aplikacji i gdy aplikacja będzie prawie ukończona, zaczniesz ją testować w innych przeglądarkach. Jest to całkowicie rozsądne – zakładając, że masz dużo czasu na przetestowanie i naprawienie problemów, które pojawiają się na tym etapie.

Istnieje jednak kilka wskazówek dotyczących tworzenia stron internetowych, które mogą zaoszczędzić sporo czasu, gdy aplikacja osiągnie fazę testowania w różnych przeglądarkach:

  1. Nie musisz testować we wszystkich przeglądarkach podczas tworzenia; jest to czasochłonne i nieefektywne. Nie oznacza to jednak, że nie możesz często zmieniać przeglądarek. Używaj innej przeglądarki co kilka dni, a przynajmniej rozpoznasz główne problemy na wczesnym etapie rozwoju.
  2. Uważaj na używanie statystyk, aby usprawiedliwić nieobsługiwanie przeglądarki. Istnieje wiele organizacji, które powoli wdrażają nowe oprogramowanie lub aktualizują. Tysiące pracujących tam użytkowników może nadal potrzebować dostępu do Twojej aplikacji i nie mogą one zainstalować najnowszej bezpłatnej przeglądarki ze względu na wewnętrzne zasady bezpieczeństwa i zasady biznesowe.
  3. Unikaj kodu specyficznego dla przeglądarki. W większości przypadków istnieje eleganckie rozwiązanie, które jest kompatybilne z różnymi przeglądarkami.

Powszechny błąd nr 9: brak planowania przenoszenia

Wniebowzięcie jest matką wszystkich problemów! Jeśli chodzi o przenośność, to powiedzenie jest bardziej prawdziwe niż kiedykolwiek. Ile razy widziałeś problemy w tworzeniu stron internetowych, takie jak zakodowane ścieżki plików, parametry połączenia z bazą danych lub założenia, że ​​dana biblioteka będzie dostępna na serwerze? Założenie, że środowisko produkcyjne będzie pasować do lokalnego komputera programistycznego, jest po prostu błędne.

Idealna konfiguracja aplikacji powinna być bezobsługowa:

  1. Upewnij się, że Twoja aplikacja może być skalowana i uruchamiana w środowisku wielu serwerów o zrównoważonym obciążeniu.
  2. Pozwól na prostą i przejrzystą konfigurację — być może w jednym pliku konfiguracyjnym.
  3. Obsługuj wyjątki, gdy konfiguracja serwera WWW nie jest zgodna z oczekiwaniami.

Powszechny błąd nr 10: RESTful Anti Patterns

Interfejsy API RESTful zajęły swoje miejsce w tworzeniu stron internetowych i zostaną. Niemal każda aplikacja webowa ma zaimplementowany jakiś rodzaj usług REST, czy to do użytku wewnętrznego, czy do integracji z systemem zewnętrznym. Ale nadal widzimy uszkodzone wzorce i usługi RESTful, które nie są zgodne z oczekiwanymi praktykami.

Dwa z najczęstszych błędów popełnianych podczas pisania RESTful API to:

  1. Używanie niewłaściwych czasowników HTTP. Na przykład użycie GET do zapisywania danych. Protokół HTTP GET został zaprojektowany tak, aby był idempotentny i bezpieczny, co oznacza, że ​​bez względu na to, ile razy wywołasz GET dla tego samego zasobu, odpowiedź powinna być zawsze taka sama i nie powinna wystąpić żadna zmiana stanu aplikacji.

  2. Nie wysyłanie poprawnych kodów stanu HTTP. Najlepszym przykładem tego błędu jest wysyłanie komunikatów o błędach z kodem odpowiedzi 200.

     HTTP 200 OK { message:'there was an error' }

HTTP 200 OK należy wysyłać tylko wtedy, gdy żądanie nie wygenerowało błędu. W przypadku błędu należy wysłać 400, 401, 500 lub inny kod statusu odpowiedni dla błędu, który wystąpił.

Szczegółowy przegląd standardowych kodów stanu HTTP można znaleźć tutaj.

Zakończyć

Tworzenie stron internetowych to niezwykle szerokie pojęcie, które zgodnie z prawem może obejmować tworzenie strony internetowej, usługi internetowej lub złożonej aplikacji internetowej.

Głównym wnioskiem tego przewodnika tworzenia stron internetowych jest przypomnienie, że zawsze powinieneś uważać na uwierzytelnianie i autoryzację, planować skalowalność i nigdy nie zakładać pochopnie niczego - lub być gotowym na radzenie sobie z długą listą problemów związanych z tworzeniem stron internetowych!