Cześć,
jakiś czas temu, pewnego pięknego dnia przeglądałem sobie LinkedIn’a. Nic w tym dziwnego – czasem zdarza mi się go przeglądać, ale tym razem, scrollując aktualności trafiłem na pytanie „Python – hit czy kit?” i wiedziony ciekawością kliknąłem w komentarze, które okazały się skrajne do bólu – od ewangelistów, którzy by pchali go do rozwiązania każdego problemu, po tych co woleli by pisać w Assemblerze byleby nie tykać tego języka. I to właśnie one są motywacją do dzisiejszego wpisu.
Na czym polega praca programisty?
Praca programisty to tak naprawdę ciągłe rozwiązywanie problemów. Non stop. Jeden problem rozwiążesz, przychodzi kolejny, z tym dajesz sobie radę, już czeka kolejny. I tak cały czas. Lubię określać ten zawód słowami „problem solver” ;)
Mowa oczywiście o problemach klientów, np
- Chcę przyśpieszyć proces zamówień w mojej firmie
- Chcę zoptymalizować długość połączeń w mojej firmie
- Chciałbym zastąpić ręczne tworzenie raportów, generowaniem ich automatycznie
- Chce dać moim klientom możliwość ręcznej zmiany parametrów zamówienia, tak by nie musieli dzwonić na infolinię
- Chciałbym automatycznie wysyłać faktury do klientów
I tak można by wymienić w nieskończoność.
Oczywiście osoba zaznajomiona z procesem wytwarzania oprogramowania już teraz wie że te problemy są zbyt duże żeby od tak je rozwiązać. Więc dzielimy je na mniejsze i dopiero te małe rozwiązujemy… Pisząc odpowiedni kod.
Ok, mamy zdefiniowany problem, jak go rozwiązać?
Aby efektywnie rozwiązać problem należy poznać jego dziedzinę. Tzn że jeśli Twoim zadaniem jest optymalizacja procesu zmian w zamówieniach których dokonują klienci Twojego klienta – to dobrą praktyką jest poznanie w jaki sposób problem ten rozwiązywany jest w tym momencie.
Niech Twój klient opowie Ci jak teraz wygląda ten proces, gdzie są przestoje, co chciałby poprawić, jaki ma pomysł na to. I jaki efekt chce uzyskać. Taka wiedza pozwoli Ci dobrać odpowiednie rozwiązanie techniczne a i pozwoli już w tym momencie przystopować nierealne wymagania klienta i zaproponować te realniejsze.
Wybieramy technologię
Skoro rozumiemy już jaką wartość mamy dostarczyć klientowi, możemy wybrać tzw. stack technologiczny – czyli po prostu technologie których użyjemy.
Wybór technologi powinien być uzależniony od takich elementów jak
- ilość osób umiejących pisać albo chociaż czytać kod napisany w tej technologii
- stabilność tej technologii
- plany rozwojowe tejże technologii
- jakość wsparcia technicznego tego oficjalnego (np. dokumentacja) jak i ogólnodostępnego (np. stackoverflow)
jednakże takim najistotniejszym elementem jest to, czy problem który rozwiązujemy jest możliwy do rozwiązania w sposób efektywny w tejże technologii.
I tu dochodzimy do sedna dyskusji na LinkedInie.
Nie każdy język nadaje się do rozwiązania każdego problemu.
Idąc na przykład w Pythona, tracimy wielordzeniowe przetwarzanie danych (thanks to GIL) ale zyskujemy np. asyncio – czyli pętle zdarzeń, która w ramach jednego rdzenia jest w stanie przetwarzać wiele elementów „równolegle”. Ta cecha języka może okazać się kluczowa jeśli mamy w planach dużo używać CPU – np. przeliczać jakieś rzeczy. Więc może ten element tworzonego systemu powinien być w.. Javie? Ma ona prawdziwe wątki, nie boi się pracować na wielu rdzeniach i ma niesamowitą maszynę wirtualną, która potrafi naprawdę genialnie zoptymalizować kod.
Czekaj, stop!
Podoba Ci się to co tworzę? Jeśli tak to zapraszam Cię do zapisania się na newsletter:Jeśli to Cię interesuje to zapraszam również na swoje social media.
Jak i do ewentualnego postawienia mi kawy :)
No dobra, ale co jeśli nie mamy nikogo od Javy? No to może trzeba napisać wstawkę w języku C do Pythona, która pokryje nam ten jeden element, rozprawiając się z GILem? Nie mamy nikogo od C? No to może trzeba ten element wyoutsource’ować – niech ktoś nam go napisze po prostu.
Baza danych. Relacyjna czy nie relacyjna? A może obie? Redis czy Mongo? MariaDB, PostgreSql czy Oracle? Tutaj trzeba zadać sobie pytanie czy będziemy potrzebować chociażby replikacji danych. Albo czy relacje łączące obiekty są znane. Bo może potrzeba nam bazy relacyjnej do danych a nierelacyjnej jako cache.
Jaka technologia ma być użyta to odbierania requestów HTTP. Nginx + PHP? A może lighttpd? A może w ogóle trzeba wyjść z PHP bo ma blokujące I/O i iść w node.js? Tutaj sporo zależy jak dużo rzeczy ten element systemu miałby robić. I jakie rzeczy by to były. Jeśli chcemy i tak większość zadań wynikających z żądań HTTP wysyłać na kolejkę to node.js powinien być tu szybszy.
A skoro mowa o kolejce – to czy wystarczy nam Celery Pythonowe? A może potrzebujemy zminimalizować narzut na komunikację i użyć ZeroMQ. Albo będziemy mieli tak istotne elementy latające po kolejkach że potrzeba nam Rabbita? Tutaj dużo zależy od decyzji podjętych w poprzednich akapitach.
Do czego dążę?
Do tego by pokazać że nie ma czegoś takiego jak dobra i zła technologia. Każdy język ma swój zestaw cech który pozwala rozwiązać określony, zamknięty zestaw problemów. A więc nie starajmy się wbijać gwoździa obcęgami – użyjmy do tego młotka.
Zmierzając do brzegu
Finalnie nie udzieliłem się w tej dyskusji na LinkedInie, nie widziałem po prostu sensu. Ale odpowiadają na pytanie „Python – hit czy kit?” – oczywiście że HIT! Im więcej mamy narzędzi do rozwiązywania problemów, tym lepiej :)
Mateusz Mazurek
Super, że wspominając technologie napisałeś też o przesłankach kiedy jaką możemy próbować wdrożyć, bo praktyczna wiedza jest o wiele cenniejsza i ciężej ją znaleźć 😊
Trudniej też ją przekazać :) dzięki za docenienie!
No fajnie. Ale ja od samego początku interesuje się technologią microsoftu i tylko w niej pisze. Póki co, problemy własne rozwiazuje doskonale. Mam za sobą projekt komercyjny w javie i wydaje mi się ze był w javie bo taki zespół był. Tu musi zaistnieć na prawdę specyficzny problem zeby zastanawiać się jaka technologia. Albo dojrzały zespół który już nie jedną technologie poznał. Mimo wszystko wpis mi się podoba. Na pewno zabłysnę na niejednym daily ;)
Przyznam się że .NETu nie znam zupełnie, napisałem w tej technologii dwa programy w całym życiu, więc moje doświadczenie jest zerowe :D Dzięki za docenienie! :)