[biblioteki][płatności online] Gotowa implementacja Transferuj.pl, Gotowa implementacja rozwiązań płatniczych Transferuj.pl Opcje

[KIPSA]

Dzień dobry,

Gdyby ktokolwiek szukał gotowych klas / bibliotek do implementacji systemu płatności we własnym rozwiązaniu, to z radością informujemy, że system płatności Transferuj.pl wyszedł na przeciw oczekiwaniom i udostępnił całą bibliotekę, z której można wybierać gotowe rozwiązania do implementacji dowolnych form płatności w systemach ecommerce:

https://github.com/tpaycom/transferuj

Dokumentacje techniczne i inne przykłady dla standardowego systemu są dostępne do pobrania tutaj: https://transferuj.pl/dokumentacje
Dla pozostałych niestandardowych systemów dokumentacje są dostępne na indywidualne żądanie, ponieważ są to systemy dla osób, które wiedzą, czego chcą.

Zachęcamy do testowania i feedbacku. W razie uwag prosimy o komentarz na forum lub na github.

Mamy nadzieję, że oszczędzi to Developerom dużo cennego czasu.

[Xelah]

CardAPI

- Nie można niczego zamockować, bo cały request opiera się na jednej prywatnej metodzie, która w dodatku używa, a jakby inaczej, static. To samo z logowaniem. O Dependency Injection programiści w firmie nie słyszeli?
- Jakieś klasy niby są ale wszystko co wchodzi i wychodzi z metod to typy prymitywne.
- SRP. W jednej klasie jest wszystko: request, walidacja, komunikaty błędów.
- Metody typu 'saleValidateAndPrepareParams'. Sama nazwa już powinna dać programiście do myslenia. O jedno 'and' za dużo.
- Magiczne liczby. Co to jest 40 albo 128?
- Code duplication. Cała walidacja, włącznie z komunikatami błędów, jest powielana. Parsowanie parametrów i przygotowanie danych do request-u tak samo.
- Takie rzeczy jak URL czy IP powinny być podawane w parametrze a nie hardcodowane i to w zmiennej. Jak już to stała jest bardziej odpowiednia do tego.

Curl

- static? Po raz kolejny. To się kompletnie nie nadaje do przetestowania

PaymentBasic

- Po raz kolejny hardcodeing. Ścieżki, IP, URL.

[PHP] pobierz, plaintext 
require_once(dirname(__FILE__) . '/util.php');
Util::loadClass('curl');
Util::loadClass('validate');
Util::loadClass('exception');
Util::loadClass('lang');
[PHP] pobierz, plaintext 

You made my day (IMG:style_emoticons/default/biggrin.gif) Tego komentować nie trzeba.

Co to jest?

[PHP] pobierz, plaintext 
(int)Util::findSubstring('/<result>([0-1]*)<\/result>/', $res)
[PHP] pobierz, plaintext 

Oby to było cokolwiek innego niż XML...

Dalej nie idę, bo jest albo to samo co wcześniej, albo gorzej.
Podsumowująć:
- Niespójność code style. Raz tak, raz tak. Jak kompu popadło tak pisał.
- Podstawy takie jak autoloading, DI.
- Wszystko upchane w kilku klasach, które robią wszystko i nic operając sie na static.
- Generalnie kompletny brak SOLID.
- Testy - a raczej ich kompletny brak.

Samej funkcjonalności nie oceniam, bo sam wgląd w bibliotekę dyskwalifikuje ją w przedbiegach. Od strony programistycznej jest to gorzej niż kiepsko. Niestety, ale w kwestii płatności nie mógłbym zaufać takiej bibliotece.

Ten post edytował Xelah 16.09.2015, 08:33:46