Jak oceniać rozszerzenia innych firm?

Chociaż Magento robi wiele „od razu po wyjęciu z pudełka”, odkryliśmy, że istnieją nieuniknione funkcje i udogodnienia dla sklepów klienckich, które wymagają rozszerzenia zewnętrznego.

Biorąc jednak pod uwagę charakter nośnika, ryzykowną propozycją może być wprowadzenie „obcego” kodu do tak złożonego systemu zajmującego się transakcjami handlowymi.

Czego szukasz, oceniając rozszerzenia Magento? Z jakimi „czerwonymi flagami” się spotkałeś (wieprze wydajności, zagrożenia bezpieczeństwa, złe praktyki architektoniczne)?

Oto kilka uwag na temat oceny modułów innych firm:

Podstawy:

• Obecna obsługa wersji Magento - Czy obsługuje najnowszą wersję Magento (w tym bieżącą, dla której ją rozwijamy)?

  Jeśli moduł nie obsługuje najnowszej wersji Magento, prawdopodobnie trudno będzie go uruchomić bez poświęcania na to cennego czasu.

• Wsparcie - czy programiści, którzy utworzyli moduł, obsługują ten produkt?

  Jednym ze znaków zdrowego modułu jest to, że programiści aktywnie go wspierają. Jeśli nie obsługują, oznacza to czerwoną flagę, dlaczego nie będą wspierać produktu, jeśli jest dobry?

  Dodatkowo, gdy moduł jest obsługiwany, zwykle możemy uzyskać ważne informacje od programistów za pomocą prostego e-maila (na przykład, czy ten moduł używa jQuery lub Prototype).

• Recenzje - co mówią inni użytkownicy? Jakie było ich doświadczenie?

  Czytając recenzje, możemy lepiej zrozumieć duży obraz, czy występuje problem z instalacją? Czy programiści reagują w sposób terminowy i pomocny? Czy to działa zgodnie z reklamą?

• Zwrot środków - czy zwrócą ci pieniądze, jeśli nie będą działać zgodnie z przeznaczeniem?

  Wiele razy chcemy wypróbować moduł, abyśmy mogli go przetestować, jeśli działa i spełnia nasze specyfikacje! Ale jeśli nie, chcemy go zwrócić i uzyskać zwrot pieniędzy.

Pośredni:

• Zastępowanie klas - czy moduł zastępuje jakieś podstawowe klasy?

  Ogólnie rzecz biorąc, dobry moduł nie powinien zastępować żadnych podstawowych klas, a raczej powinien używać obserwatorów.

  Jednym z powodów jest to, że może utrudnić aktualizację Magento. Dodatkowo inne moduły mogą zależeć od jednego wyjścia z danej funkcji, a ten moduł zapewnia inny.

  Czasami nie jest to możliwe, jeśli tak jest, powinien istnieć bardzo dobry powód, dla którego zastępuje on klasę podstawową.

• Aktualizacje układu - czy moduł zmienia niektóre ustawienia mojego układu?

  Niektóre moduły zmieniają ustawienia układu na twoją stronę (na przykład: stronę produktu), upewnij się, że nie psuje twojego obecnego układu, a jeśli zrobi to, co byłoby wymagane (przeczytaj: ile czasu zajmie nam to), aby to naprawić .

• Zmiany szablonów - Czy moduł zawiera szablony, które zmieniają mój obecny projekt?

  Czy ten moduł wprowadzi nowe szablony? Jeśli tak, czy złamią mój projekt? Ile czasu zajmie stworzenie projektu tak, jak chcemy?

• Zależności - czy moduł zależy od jakiegokolwiek innego modułu?

  Jeśli moduł zależy od innych, musimy upewnić się, że są one zainstalowane i zainstalowane. Dodatkowo musimy zadać sobie pytanie, czy chcemy wyłączyć moduł, od którego zależy w przyszłości?

Zaawansowane:

• Skrypty aktualizacji SQL - czy moduł aktualizuje DB w jakiś sposób?

  Gdy moduł zaktualizuje bazę danych, musimy upewnić się o kilku rzeczach.

  Czy aktualizuje tabelę podstawową? Jeśli tak, to nie jest dobre, lubimy nasze bazy danych czyste i gotowe do aktualizacji.

  Czy przechowuje informacje w rozsądny sposób? Jeśli sami chcielibyśmy pobrać dane surowe z bazy danych, czy moglibyśmy je zrozumieć?

• Zdarzenia - czy moduł obserwuje lub wysyła jakieś zdarzenia?

  Jeśli moduł wywołuje lub obserwuje zdarzenia, chcemy wiedzieć:

  Jakie wydarzenia obserwuje / wysyła? Czy wpłynie to na inny moduł działający w systemie. Na przykład, jeśli jeden z naszych modułów zmieni nazwę naszych produktów podczas ładowania na wielkie litery, a ten moduł doda słowo „wolny” do nazwy produktu podczas ładowania, jak to będzie działać? Czy słowo „wolny” będzie również wyświetlane wielkimi literami?

• Przegląd kodu - czy moduł stosuje akceptowalne techniki kodowania?

  Ma to więcej wspólnego z technikami kodowania PHP niż Magento.

  Czy kod używa bloków Try / Catch?

  Czy kod nie wprowadza danych użytkownika?

  Specyfika tego naprawdę zależy od naszego poziomu umiejętności / wymagań.

• Potencjalne problemy - jakie potencjalne problemy mogą pojawić się w wyniku instalacji tego modułu?

  Spróbuj wyobrazić sobie pięć głównych problemów, które mogą pojawić się, jeśli zainstalujemy ten moduł, choć może to być zaskakujące, ponieważ naprawdę daje wgląd w cały projekt.

Dolna linia:

Wszystkie te rzeczy są miłe w idealnym świecie, w rzeczywistych scenariuszach musimy zrobić to, co nazywa się „kompromisem” :)

Ponadto te wytyczne mają nam służyć jako pomoc, a nie przeszkadzać, w wyniku czego instalujemy tylko jeden moduł, powiedzmy moduł udostępniania społecznościowego, i jest on przeznaczony dla klienta, który potrzebuje prostej konfiguracji witryny nie ma sensu przeprowadzać wielu badań.

Innymi słowy: Chodzi o to, aby być wydajnym w naszych czasach, jeśli użycie tego (pozycja w) przewodnika pomaga mi zaoszczędzić czas na dłuższą metę, użyj go, jeśli nie upuść go i oszczędzaj zdrowie psychiczne.

Niektóre czerwone flagi „złej praktyki” specyficzne dla Magento to:

• dowolny kod w app/code/local/Mage
• zastąpione szablony (pliki, app/designktóre już istnieją w rdzeniu)
• przepisuje podstawowe klasy, takie jak catalog/product. Ogólnie uważnie przyglądam się każdemu przepisywaniu, aby sprawdzić, czy można tego uniknąć
• poważne naruszenia standardów kodowania Zend / Magento. Chociaż chodzi tylko o formatowanie kodu, dochodzę do wniosku, że deweloperzy, którym nie zależy na standardach, najprawdopodobniej nie będą dbać o inne, ważniejsze rzeczy.
• zmiany w podstawowych tabelach baz danych
• tekst zakodowany na stałe w szablonach (bez użycia mechanizmu tłumaczenia) i gdzie indziej
• logika biznesowa w szablonach (ogólna zasada: każde pojawienie się Mage::getModelw katalogu szablonów jest zwykle złym znakiem)

Niektóre czerwone flagi związane z PHP (jest to bardzo selektywna i niekompletna lista):

• wszelkie powiadomienia i ostrzeżenia z włączonym raportowaniem błędów ( E_STRICT)
• wykorzystanie @operatora
• nie dezynfekuje danych użytkownika przed wyjściem

Niektóre czerwone flagi związane z wydajnością:

• zapytania do bazy danych wewnątrz pętli
• ładowanie całej kolekcji tylko po to, aby użyć jej części

Uważaj również na ogólne zapachy kodu , nie są to konieczne czerwone flagi, ale pomagają oszacować ogólną jakość.

Krok # 1 - Czy Twój klient może sobie pozwolić na obsługę tego rozszerzenia, jeśli programista przejdzie AWOL?

Jeśli nie, nie możesz użyć rozszerzenia.

Jeśli tak, przejdź do oceny rozszerzenia.

Świetni ludzie z Inchoo mają artykuł na temat analizy kodu modułu strony trzeciej. W artykule wspomniano o przepisywaniu klas, zadaniach cron, aktualizacjach układu i obserwatorach zdarzeń.

Znalazłem kod obserwatora zdarzeń, który może potencjalnie zapewnić najwyższą wydajność. Zwróć uwagę na kod strony trzeciej, który wymaga dużej ilości zasobów i jest uruchamiany w przypadku często wywoływanych zdarzeń. Zdarzenia takie, jak Controller46_predispatch lub ładowanie kolekcji.

Korzystam z tego modułu narzędziowego firmy Prattski, aby uzyskać ładny przegląd przepisów i obserwatorów.

Posiadanie jakichkolwiek szablonów i zasobów skórki znajdujących się w default / default (lub pro lub enterprise) zamiast base / default jest dość denerwujące.

Na zaciemniony kod należy uważać - szukaj wywołań eval (), base64_decode () i tym podobnych. Jest to często używane do sprawdzania poprawności licencji, ale może być złośliwe lub przerażające - widziałem co najmniej jeden składnik, który ewaluował dowolny kod z kanału RSS.

Poszukaj wywołań dl () - co najmniej jeden składnik bramki płatności, który widziałem, wymaga zainstalowania rozszerzenia PHP, aby wykonać jego połączenia!

Masz rację.

Niestety nie ma magii: musisz je przetestować, sprawdzić kod, aby sprawdzić, czy jest dobrze opracowany, mieć dobre wsparcie dla modułów komercyjnych dzięki ich forum lub szybko odpowiedzieć na twoje pytania ...

Istnieją pewne recenzje na temat Magento Connect, a popularność rozszerzenia może pomóc dowiedzieć się, czy jest on cenny, czy nie, ale szczerze mówiąc, możesz znaleźć bardzo popularne moduły z dużą ilością błędów. W zeszłym tygodniu miałem dobry przykład z modułem MailChimp, głównie dobrze zrobionym, ale musiałem naprawić kilka błędów i przekazać je programistom. Zawsze istnieje ryzyko, musisz przetestować.

WebShopApp wpadł na pomysł, aby pójść w tym kierunku, mam na myśli platformę, aby uzyskać dobre informacje o modułach. Pomysł polegał na popchnięciu Magento w tym kierunku. Tak więc jakość modułu jest faktycznym pytaniem.

Moja rada: zwróć szczególną uwagę na moduły, które mają skrypty instalujące / aktualizujące, które zmieniają wartości w podstawowych tabelach, ponieważ nie zawsze łatwo jest wycofać tego rodzaju zmiany.

Test nr 1, który mogę wymyślić, polega na znalezieniu exploita zero-day w swoim kodzie (zwykle nie jest to bardzo trudne w przypadku rozszerzeń Magento), zgłasza tylko wynikowe uszkodzenia fałszywego exploita zespołowi bezpieczeństwa (nie wskazując, który z nich część kodu jest podatna na ataki) i rozpocznij stoper - ponieważ dokładnie tak się stanie, gdy Twoja witryna zostanie zhakowana. Gdy ich pracownicy pomocy technicznej proszą o globalny dostęp FTP i mysql, uprzejmie odmówili stwierdzenia, że ​​narusza to standard PCI-DSS i zaoferowali im dostęp tylko do odczytu do Twojego repozytorium kodu źródłowego.

Test nr 2, który wykonuję, polega na wezwaniu sprzedawcy i zaskoczeniu go. Zapytaj ich, jakiego rodzaju testy behawioralne / jednostkowe wykonują, jakiego systemu kontroli źródła używają, na jakich testowanych wersjach PHP testują, na jakich wersjach Magento są testowane, na jakich serwerach testowanych, niezależnie od tego, czy używają przeglądarki -stack do testowania komponentów frontonu itp. Jeśli sprzedawca nie wie, o czym mówisz, milczy lub chce „poprosić eksperta o odesłanie Ci e-maila”, biegnij jak diabli, ponieważ najprawdopodobniej używa numerowanych pliki zip do „kontroli wersji” i naprawiaj błędy tylko 3 miesiące po tym, jak klienci zgłoszą je.

Mówiąc o PCI-DSS, wszystkie modyfikacje systemu są również wymagane, aby mieć strategię przywracania. Dzięki modułom, które dodają niezerowalne kolumny do podstawowych tabel, staje się to prawie niemożliwe przy jednoczesnym utrzymaniu strategii przywracania, która przejdzie audyt. Działa jak diabli z dowolnych modułów, które powodują problemy (czytaj: Błędy SQL) po wyłączeniu.

PCI-DSS v3

6.4.5.4 Procedury wycofania.

Sprawdź, czy dla każdej próbkowanej zmiany są przygotowane procedury wycofania.

W przypadku każdej zmiany należy udokumentować procedury wycofywania na wypadek, gdyby zmiana zakończyła się niepowodzeniem lub negatywnie wpłynęło na bezpieczeństwo aplikacji lub systemu, aby umożliwić przywrócenie systemu do poprzedniego stanu

To, oprócz innych odpowiedzi. IMO powinna być ściana wstydu za niektóre niebezpieczne bzdury, które pojawiły się na tej platformie.