Ola Kunysz

Miałam ostatnio okazję być na wrocławskim JUGu, na którym Paweł Zajączkowski opowiadał o projektowaniu Web API. Poza tym, że zostałam wzięta za rekruterkę ( wow wow, community takie otwarte ), to otworzyły mi się oczy na kilka nowych tematów. Na codzień pracuję z Web API i staram się projektować je w sposób przyjazny jego użytkownikom (najczęściej developerom na froncie). Okazuje się, że to nazywa się APIX - API Experience. To taki piękny punkt, w którym biznesowy świat UX wkracza w czeluści kodu backendowego. Bo jako programiści nawzajem też jesteśmy swoimi klientami i też powinniśmy dbać o komunikację między naszymi serwisami, albo komponentami. Doświadczony developer wie, że częściej czyta się kod, niż się go pisze. No może greenfieldowe projekty mają na początku odwrotne statystyki, ale z biegiem czasu zrównują się z innymi. Cały kod, który jest w projekcie, api, komendy devopsowe, wszystko jest danym nam dziedzictwem, zwanym legacy  / ˈlɛɡəsi / . Żeby efektywnie dbać o to dz...

Pierwszy raz ze specjalizacją w programowaniu logiki biznesowej spotkałam się w książce Soft Skills  John'a Z. Sonmez'a. Zapaliła mi się żaróweczka i otworzył przede mną nowy świat, bo oto okazało się, że oprócz standardowego podziału na frontend i backend, jest taka działka jak pisanie głównej treści aplikacji. Stało się dla mnie jasne, dlaczego zawsze bardziej jarały mnie prezentacje o DDD i dyskusje o zbieraniu wymagań, niż gadanie o bebechach JVMa i decydowanie o wyborze frameworków. Piękny moment olśnienia, życzę każdemu! Dlaczego odnoszę to do książki Async Remote ? Poza tym, że Robert Pankowecki i Andrzej Krzywda są ewangelizatorami DDD, Event Souring'u, CQRS'a i innych buzzwordów "dla biznesu", poruszają w książce bardzo ciekawe i trudne zagadnienie, jakim jest zbieranie wymagań i tworzenie prototypu funkcjonalności biznesowej. Dzielą się tym, w jaki sposób tworzą działający szkielet aplikacji, zanim wybiorą bazę, system autoryzacji, a nawet framewor...

Zacznę od wątpliwości. Wątpliwości, które wzbudził we mnie rozdział o podziale zadań. Taski jednopunktowe to całkiem sensowna propozycja. Po moich ostatnich doświadczeniach z ugrzęźnięciem na nieznanym terytorium doceniam pomysł. Ale możliwość wzięcia pierwszego taska z listy to już trochę abstrakcja. Większość zespołów nie jest jednorodna. Ja przynajmniej nigdy w takim nie pracowałam. Nawet jeśli jesteśmy fullstackami to zawsze mamy jakieś specjalizacje. Może to jest szufladkowanie, może lęk, albo zwyczajne lenistwo, ale nie zawsze da się wziąć cokolwiek. Będąc rycerzem backendu, biorę czasem taski frontendowe, ale raczej dotyczące kodu, niż dizajnu. Średnio czuję tę część tworzenia oprogramowania i nie potrafię dać jej tyle miłości, co choćby logice biznesowej. Więc o ile wezmę task pod tytułem Dodaj walidację pola X , o tyle zadanie Stwórz widok Y raczej ominę. Z drugiej strony wprowadzanie kategorii Frontend i Backend trochę sztucznie dzieli zespół i sprawia, że nigdy nie zagląd...