Kiedy programowanie przechodzi w hackowanie…

Dobra, na samym początku wyjaśnienie o co nie chodzi z hackowaniem. Nie, nie chodzi o włamywanie się do serwerów, łamanie zabezpieczeń itp. Nic nie legalnego (a czasami nawet legalnego). Chodzi i o hackowanie całkowicie legalne a jedynie czasem nie legalne (łamanie licencji) w trakcie programowania.

Uwielbiam programować.  Lubię to uczucie kiedy tworzę nową rzecz. Kiedy moje środowisko pracy jak i środowisko danego języka (platformy) daje mi możliwość płynięcia. Nie muszę myśleć o niczym innym niż tylko o tym co chcę napisać i dostarczyć. Takie coś jest po prostu niesamowite. Znacie to uczucie? Siadacie, i po prostu TWORZYCIE coś niepowtarzalnego (w pozytywnym tego słowa znaczeniu;))?

Jednak prawda jest taka, że bardzo ciężko jest mieć taki flow w szczególności, że nasze środowiska tego nie umożliwiają a wręcz działają na naszą nie korzyść.

Weźmy taki SharePoint i jedną prostą rzecz – aktualizację elementu na liście. Płyniesz, piszesz kod, robisz Update i coś się zadziało. Okazuje się, że ktoś podpiął pod listę ItemReceiver który wykonuje jakąś operację po tym jak element zostanie dodany…. Jednak ta operacja całkowicie Tobie blokuje możliwość posunięcia się dalej. Jednak głos w głowie Ci mówi, że element jest aktualizowany przez MS wewnętrznie i jakoś tego problemu nie ma, czemu? Po 2 dniach wiesz… MS wywołuje ukrytą metodę UpdateInternal(notifiyReceivers: false) (czy jakoś tak). Czyli się da… tylko, że to nie jest dostępne. To co trzeba zrobić? Z hackować kod.

Inny przykład podałem z OData w poniedziałek. Czy też MVC i sposób poprawny przechwytywania błędów i dawania custom pages, tak by przeglądarka dostała odpowiedni błąd, do tego wyświetliła odpowiednią stronę, nie zmieniając przy tym urla. Da się? Da się. Czy jest to proste? Nie, trzeba się namęczyć i hackować.

Jeszcze inny przykład z ostatnich dwóch tygodni, CRM i aktualizacja elementu. Próba zrobienia aktualizacji wywalała błąd, że encja jest już załączona:

• IsAttached -> false
• Attach(entity) -> throws is attached
• UpdateObject(entity) -> throws not attached

I bądź tutaj mądry. Nie da się. Zamiast więc tworzyć i pisać rozwiązania walczymy z framework z biblioteką czy czymkolwiek innym.

Takie programowanie jest smutne. Od takiego stronie jak się da. Kiedyś jednak czerpałem z tego radość – ooo dlaczego tak jest? I boom dwa dni z życia wzięte. I tak znalazłem! Oni to robią z parametrem true a jak by tak podać false za pomocą refleksji to będzie to śmigać!

Tylko teraz, dlaczego? Po co? W jakim celu to robić? MVC nas ogranicza? Musi walczyć i męczyć się z framework zamiast pisać kod? Zmienić na Nancy. Próbować czegoś innego, może w ogóle Web API + JavaScript. Powinniśmy czerpać przyjemność z pisania. A hackowania (a dokładniej frameworków/języków które tego wymagają) zaś unikać jak się da. To że dzisiaj jest to UpdateInternal nie znaczy, że jutro nie będzie to Update z zupełnie innymi parametrami.

Nasz zestaw narzędzi i bibliotek powinien wspierać nas w procesie tworzenia oprogramowania a nie go blokować. Następnym razem jak będziecie pisać aplikacje i natraficie na miejsce w którym zamiast tworzenia trzeba hackować, rozpoznawać, dekompilować – zapiszcie sobie tą bibliotekę. Przy kolejnym projekcie spróbujcie skorzystać z innej.

Dobierajcie narzędzia do problemu a nie próbujcie wcisnąć każdy problem w ten sam zestaw.

Życzę wam, by biblioteki wam sprzyjały i byście nie musieli marnować dni na bezproduktywne znajdywanie brakującego ogniwa.

Gutek, po kompletnie zmarnowanych kilku dniach hakowania biblioteki by działała zgodnie z specyfikacją a nie widzimisię programisty.