Duże serwisy internetowe. Różne branże.

Najgorzej jak rozjada sie wymagania biznesowe i nagle okazuje sie, ze biznes chcial cos innego niz zostalo dostarczone, mimo, ze pod wzgledem jakosci jest bardzo dobrze technicznie

U siebie w zasadzie piszemy w TDD, więc kod jest otestowany. Zdarzają się też testerzy/klikacze-psuje, ale ostateczna decyzja należy do klienta, który też testuje.
Ale mimo wszystko dev ma inny interes, chce, żeby dzialalo, a tester chce popsuć. w pewnym etapie projektu mogą się przydać, ale na stałe? Bez sensu.

***
http://www.wykop.pl/link/2867541/lewaki ... za-dobrze/
Lewaki narzekają, że specjalistom IT jest w Polsce za dobrze

Developerzy przewaznie wykonuja testy funkcyjne/jednostkowe. Dla zlozonych systemow, ktore np skladaja sie z wielu roznych podsystemow testy funkcyjne sa niewystarczajace, przydaloby sie np. zrobic system testy (characteristics, overload, stability, robustness etc). Jezeli ktos twierdzi testy funkcjonalne wystarcza, zeby osiagnac wymagana jakosc softu to chyba nie do konca rozumie czym sa system testy i najefektywniej/najtaniej jest robic to rownolegle z praca designu. Moze dla "web systemow" developer ogarnie wszystko ale np w telco czesto jest tak, ze proces testowania trwa dluzej niz pisanie kodu a sam soft jest pisany przez kilkadziesiad zespolow designerskich. Wiec sila rzeczy developer jest specjalista w obrebie obszaru ktory tworzy ale juz niekoniecznie ogarnia system jako calosc()...
I czesci rzeczy nie da sie zautomatyzowac albo jest to bardzo trudne, nie wspominajac np o field testach.

Masz rację. System testy jak najbardziej są ważną częścią developmentu, my od e2e testów w ogóle zaczynamy pracę. W systemach webowych jest to w miarę proste, w telco pewnie nie, ale to wynika z faktu, że tam musisz testować całą infrastrukture, a to już w dużej mierze nie jest działka programistów. Ja uważam, że programista powinien przetestować cały kod od wejścia sygnału do wyjścia i tam dodatkowych testerów nie potrzeba. Natomiast punkty stykowe pomiędzy komponentami trzeba przetestować w inny sposób, tyle że to już nie jest testowanie samego oprogramowania i muszą się tym zajmować osoby kompetentne a nie "generyczny" dział testerów.

No ale dobrze by bylo aby ktos inny przetestowal kod napisany przez "generycznych developerow"...

Ogolnie niech zgadne - w robocie korzystacie z TDD i DDD? Nie wiem czemu ale sporo osob, ktore zaczyna tego uzywac (lub uzywa tylko tego w pracy) uwaza ze developerzy wykorzystujacy to sa swietni. Natomiast osoby korzystujace z innych wzorcow (np anemic domain model/transaction script) sa mierne. No i na koncu zazwyczaj udowadniaja ze swietni devsi piszacy w tdd/ddd napisza lepszy soft niz mierni w innych technologiach. Jakos zawsze umyka im ze w swoich rozwazaniach za bardzo skupiaja sie na ludziach.

Wogole co to jest generyczny tester? Jesli mamy generycznego testera to mamy i generycznego developera i caly projekt idzie wpizdu. Zaloz ze mozna miec doby zespol testerski, ktory rozumie domene (zespol z ludzmi tak samo wartosciowymi jak developerzy). I wnosi duzo dobrego. Oczywiscie jesli wszystko sami testujecie to moze i to dziala dobrze u was. Ale przypuszczam ze przy dobrym zespole testerskim i dobrym procesie byloby lepiej. Idac Twoja logika mozemy zalozyc ze cala idea devops to tez pomylka bo programista moze ogarnac swoj kod. I faktycznie moze lecz w duzych projektach/firmach zaczynaja sie pojawiac ludzie, ktorzy praktycznie tylko tym sie zajmuja i z mojego punktu widzenia to sie sprawdza. Oczywiscie z zespolem testerskim jest sporo problemow: trzeba za nich placic, zatrudnia sie studentow/osoby z indii liczac ze to wystarczy itp (ogolnie testerow wiele osob ciagle traktuje jako tania sile robocza).

Ps
Zeby nie bylo - uwazam TDD i DDD za podejscia, ktore sie sprawdzily (DDD samym "wspolny" jezykiem i naciskiem na bounded contextem wniosl wystarczajaco duzo aby stac sie podstawa, ktora kazdy musi znac).

nikt nic takiego nie napisal, a siebie uważam za lamera Czesc osob uwaza, ze trzeba pisac tak dobry kod, zeby nie bylo potrzeba testow
Ale nie rozumiem po co mieliby byc testerzy, ktorzy _tylko_ pisza testy jednostkowe czy integracyjne. Penetracyjnych testow devsi raczej robic nie beda.

devops mega przydatni, przyspieszaja prace devow.

teraz IoT to przyszlosc!
smart kibel!
http://www.kohler.com/numi/#comfort.html

Tak szczerze powiedziawszy, jak czytam te wszystkie definicje DevOps, DDD itp to pod skrótami itp kryją się rzeczy dość oczywiste i często stosowane podczas developmentu, mimo tego że nikt z nazwy ich nie kojarzy, często nawet nie zdaje sobie sprawy z tego że tak sformułowane zasady istnieją.

Zgadłeś TDD od lat. A DDD od dwóch. Z tym, że już się nauczyliśmy, że sedno DDD - strategic patterns (UL, context mapy itd.) stosuje się tylko w core domain, a DDD lite, tactical patterns, to po prostu dobrze napisany OOP. Dlatego nie traktujemy anemicznych encji i transaction script jako coś z góry złe. Wszystko zależy od skomplikowania domeny. Zresztą tego też uczy TDD, że zaczynasz od prostych implementacji, bez narzutu wielu wzorców, a później refaktorujesz w miarę potrzeb.

Co do DevOps to w żcyiu bym nie powiedział, że są niepotrzebni, są zajebiście potrzebni i u nas jest niestety ich niedostatek. Różnica między dedykowanym DevOpsem i dedykowanym testerem jest taka, że DevOps nie musi znać dobrze domeny, a tester moim zdaniem musi. Oczywiście, jeżeli pracujecie nad jednym produktem cały czas, to stały tester będzie miał duże pojęcie o danej aplikacji i na pewno wniesie więcej niż tester przydzielany z doskoku.
Taki tester rzeczywiście może znaleźć miejsca, które nie zostały otestowane, tu sie zgadzam. Największym problemem developera przy testach jest znalezienie wszystkich przypadków do otestowania, jak o którymś zapomnisz to mogą być niezłe kwiatki.

W każdym bądź razie nadal uważam, że osoba, która zajmuje się tylko testami nie będzie w stanie pisać dobrych testów automatycznych (czyli takich które się nie wysypią po najmniejszym refactorze, nie będą uciążliwe w utrzymaniu i przede wszystkim będą czytelne), a na testy manualne przeważnie szkoda zasobów.

Jeszcze wracając do DDD i Bounded Context - granice contextu idealnie wyznaczają microservice dzięki czemu w końcu odeszliśmy od monolitu, ale teraz potrzeba nam dużo więcej devopsów.

A umie ktos cos polecic do poczytania o microservices i jak w ogole to oceniacie?

Ostatnio mnie boli troche integracja miedzy naszymi uslugami, zwlaszcza,ze nie do konca jest to micro i jeden modul ma za duzo zaleznosci.

Ale ogolnie srednio mi sie podoba, ze np. Jedna uslugaprzechowuje np. Liste id i jak potrzebuje to wysyla request po dane z nimi zwiazane i zwraca je na frontend. Jak jest komunikacja backend to backend to niby spoko... Jak kwestia sie zamyka w max 2 requesty to niby tez ok. Ale jak pobiera dane z kilku modulow to co? Mozna czasem zrobic cos asynchronicznie. Jakied dobre praktyki na to?

Osobiscie, uwazam ze to SOA ubrane w nowe slowa. Przy okazji dorzucanie narzutu na RPC na prawie wszystko. Ale najwyrazniej dobrze sie sprzedaje.

Jesli przyjdzie moment, ze system bedzie mial byc rozproszony (z rozmaitych wzgledow), to bedziesz wiedzial ze tego potrzebujesz. W innym przypadku - na 99% wcale tego nie potrzebujesz, a dostaniesz w bonusie problemy o ktorych do tej pory nie miales pojecia i o ktorych w ogole nie myslales*.


* - moze za malym wyjatkiem niektorych actor systems, zarowno w przypadku komunikacji wewnatrz procesu, jak i miedzy maszynami, ze strony API wyglada to dokladnie tak samo (location transparency), wiec tak czy inaczej trzeba sie z tym zmierzyc. No ale dodatkowo trzeba tez ladnie obslugiwac timeouty, ktore na pewno beda sie zdarzac etc.

Mikroserwisy są podzbiorem SOA, mają "ciaśniejsze" zasady. Np. każdy mikroserwis posiada własny stacktechnologiczny, własny deploy i jest uruchomiony w osobnym procesie, natomiast zasady SOA tego nie narzucają. W SOA można mieć wydzielone usługi wewnątrz jednego procesu i komunikować się korzystając bezpośrednio z obiektów serwisów.

Co do tego, że mikroserwisy są dużym narzutem to w 100% się zgadzam. Nie radzę nikomu się pchać w mikroserwisy jeśli nie widzi w tym sporego zysku.
Zalety mikroserwisu:
- jak padnie jeden serwis, to reszta działa (oprócz tych, które są od niego zależne)
- multiplatformowość, czyli możliwość tworzenia jednego serwisu w Pythonie, drugiego w PHP a trzeciego w Scali (to się tyczy równiez różnych wersji, np. Python2 i 3)
- brak możliwość grzebania sobie po bebechach, co u nas zdarzało się wielokrotnie, najczęściej z lenistwa
- deploy małej części aplikacji, a nie całości

Minusy:
- trzeba dobrze określić granice mikroserwisu, jak tu się popełni błąd na początku, to później ciężko go naprawić
- poziom skomplikowania,
- praktycznie na każdy mikroserwis potrzebny jest devop,
- komunikacja pomiędzy serwisami i wszystkie problemy z tym związane (również async),

Fowler ma dobrą prezentację o tym: https://www.youtube.com/watch?v=wgdBVIX9ifA

Dzieki, pozniej pewnie napisze wiecej. Ale ja jak przyszedlem do pracy to ten projekt od razu byl oparty na mikroserwisach. Na poczatku byly one niemal niezalezne od siebie wiec byl luz. Pozniej na 3 miesiace zniknalem w innym projekcie, gdzie mialem pojedyncza appke, ktora sam pisalem z frontendowcem, no to wedlug mnie tam moglem byc bardziej elastyczny. Debugowanie tez bylo proste.

Przy tych mi mikroserwisach masakra jest dla mnie trzymanie czesci sharowanych do innych modulow. Wrzucanie tego na jakiegos nexusa, ciagle zaciaganie nowych dependencies po wprowadzeniu zmian do mavena czy gradla itp. I mozna tez o tym zapomniec A i tak mamy to niezle zautomatyzowane. Debugowanie przy udziale kilku modulow jest problematyczne, najczesciej trzeba szukac w logach serwera bo lokalnie nie odpale, albo za duzy trud by to zrobic. No i jeden modul jest za duzy co tez sprawia problemy. Testowanie tez takie proste nie jest.

Ogolnie mam mieszane uczucia, czasem mam wrazenie, ze wiecej czasu trace na konfiguracje niz wlasciwy development heh.

Tu jest jeszcze jeden ważny plus mikroserwisów i generalnie SOA, którego sam tak dobrze nie wytłumaczę: https://vimeo.com/108441214
Świetny talk.

Najwiekszy plus jest taki, ze moze klepne jakis microservice napisany w Scali do naszej appki, taki mam plan
Dzięki za resource.

Jak ktoś jedzie na http://boilingfrogs.pl/ albo http://craft-conf.com/2016 to można się ustawić, bo tez prawdopodobnie będę.

Calkiem pro ta konferencja we wrocku, chyba sie zorganizuje i postaram sie byc.

szkoda ze niemiecki breslau a nie warszaffka

wbic na konfe nie jest latwo w warshau ,miejsc malo a chetnych zawsze duzo

W Londonie luzik, ostatnio bylem na Digital Marketing Show w ExCeLu, calkiem kameralnie, a prelegenci sensowni:

czy ja wiem, po prostu trzeba się odpowiednio wcześniej zapisac. Rok temu byłem na 4developers w wawce i nie było problemów.

Z ciekawostek, to ostatnio do pracy kupili serwer 1 tera ramu, masakra. ;d