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.
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
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.
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.
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
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.
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 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.
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 :)
Ostatnio tygodnie były tak bardzo wypełnione, że nie udało mi się napisać nawet krótkiego podsumowanie. Więc dziś zbiorczo podsumuję luty… Read More
Zapraszam na krótkie podsumowanie miesiąca. Książki W styczniu przeczytałem "Homo Deus: Historia jutra". Książka łudząco podoba do wcześniejszej książki tego… Read More
Cześć! Zapraszam na podsumowanie roku 2023. Książki Zacznijmy od książek. W tym roku cel 35 książek nie został osiągnięty. Niemniej… Read More
Zapraszam na krótkie podsumowanie miesiąca. Książki W grudniu skończyłem czytać Mein Kampf. Nudna książka. Ciekawsze fragmenty można by było streścić… Read More
Cześć, ostatnio w Internecie pojawiło się dużo artykułów, które nie były przychylne pracy zdalnej. Z drugiej strony większość komentarzy pod… Read More
Zapraszam na krótkie podsumowanie miesiąca. Książki W listopadzie dokończyłem cykl "Z mgły zrodzony" Sandersona. Tylko "Stop prawa" mi nie do… Read More
Pokaż komentarze
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! :)