Jak zorganizować zespół i poprowadzić projekt.

3

Zostałem niedawno koordynatorem małego, zdalnego, zespołu programistów (4 sztuki). Pierwszy projekt już prawie skończony, ogarnąłem specyfikacje i architekturę projektu, taski lecą przez Trello, pracujemy w tygodniowych sprintach, robimy wzajemnie code review itd.. Wiem jednak że dużo mi brakuje do bycia dobrym kierownikiem.

Największy problem sprawia mi odpowiedni podział projektu na taski, żeby wszyscy mogli pracować jednocześnie, bez konieczności tworzenia mocków, lub czekania aż ktoś inny skończy API innego modułu. Poza tym, często muszę uciekać się do mikrozarządzania, żeby całość ze sobą zagrała. No i finalnie, nie wiem jak podchodzić do całości od strony ludzkiej, starać się z nimi zakolegować, czy raczej trzymać chłodny dystans. Moglibyście mi polecić książki/blogi/filmy/szkolenia na temat skutecznego zarządzania zespołami, projektami i ludźmi? Podzielić się, jak wygląda workflow u was, od otrzymania specyfikacji do zdania projektu?

3

Raczej nie mam dobrych rad, za mało konkretów podajesz.

  1. Mikrozarządzanie - chyba większość managierów stosujących mikrozarządzanie nie ma pojęcia, że je stosuje. Nie wiem co u Ciebie znaczy mikrozarządzanie.
  2. Robienie mocków, czekanie na API jest normalne, w każdym projekcie. To nie kopanie rowów, wielu zależności nie widać i wychodzą w praniu.
  3. Jak wiem co jest celem projektu to zwykle w trakcie czekania jestem sobie znaleźć sensowne zadanie w projekcie.
  4. starać się z nimi zakolegować, czy raczej trzymać chłodny dystans. - chcesz się zakolegować z programistami, zrób swoje demko 4k w asmie. To najłatwiejszy sposób.
  5. Do specyfikacji często używamy wiki lub google docsów - w mniejszych projektach. Ważne żeby każdy mógł edytować, szukać i żeby była historia zmian.
  6. Co Ci dają sprinty ?

Tak przy okazji to ostatnio w projekcie typu: specyfikacja, realizacja, zdanie to byłem z 6 lat temu, ale to dla linii lotniczej - wprost powiedzieli, że są bardzo nie agile.

0

Ludzie są społeczni i odwzajemniają emocje, możesz rzucać słowami z nie adekwatnymi emocjami, a ludzie to jakoś przyjmą, ale w sumie to w czasie rozmowy wyczujesz jak rozmowa będzie niekomfortowa.

0

Sprinty to może za dużo powiedziane, daleko mi do frameworków zarządzania. Chodzi o wymóg żeby co piątek program się kompilował i przechodził wszystkie testy. Po pierwsze, jest czas żeby przez weekend pogadać z klientem i wprowadzić ewentualne poprawki. Nie wszystko można wyłapać w fazie projektowania. Po drugie narzuca to pewien rygor doprowadzania rzeczy do końca, zamiast rozgrzebywać całość na hurra. Wymusza też podział programu na niezależne moduły. Podobnie działa TDD przy pisaniu logiki, nie stricte dla testów, ale dla jakości kodu.

@jarekr000000 Jeżeli mogę zapytać, jaki był podział zadań? Projekt był rozbity na małe kęsy po kilka roboczogodzin, które były rozdzielane na ludzi, czy raczej każdy dostawał do zrobienia cały moduł, na kilkanaście dni pracy i sam sobie dalej organizował jak to przerobi?

5

Chodzi o wymóg żeby co piątek program się kompilował i przechodził wszystkie testy

o_O branch master zawsze powinien sie kompilować i przechodzić wszystkie testy. Jak jakiś feature jest scalany do mastera to znaczy że przeszedł wszystkie testy na środowisku testowym.
Niewiele ma to wspólnego ze Sprintami czy z kończeniem tasków. To jest ortogonalna kwestia. Niemniej moim zdaniem takie sztuczne narzucanie że "feature ma być zrobiony do końca sprintu w piątek" kończy się zawsze źle:

  1. Albo programiści będą estymować zachowawczo mniej - powiedzą że są w stanie zrobić dużo mniej, żeby nie ryzykować ze się nie wyrobią.
  2. Albo będą robić fuszerkę z serii "nie ma testów" i "kiedyś sie to zrefaktoruje", co w najlepszym wypadku skonczy się długiem techniczny, a w najgorszym wysadzi wam kiedyś produkcje
  3. Albo będą olewać wszystko inne (np. jakiś pożar na produkcji) żeby nie "tracić czasu", bo się nie wyrobią. Widziałem takie akcje -> coś sie sypie na produkcji a gość odpowiedzialny za dany serwis mówi ci, że mogą ten problem omówić na planningu za tydzień i może wrzucą w kolejny sprint więc przy dobrych wiatrach za 2-3 tygodnie będzie naprawione :D

Poza jakimiś mocno formalnymi środowiskami, gdzie przyjecie przez klienta nowej wersji jest ustandaryzowane w jakiś sposób, w ogóle bym sie w takie coś nie pakował. Jeśli mozecie sobie pozwolić na ciągłą integrację, to z tego korzystajcie. Jak feature jest gotowy to leci na proda a developer bierze następny task. Nie ma sensu czekać do jakiegoś mitycznego "końca sprintu".

0
Shalom napisał(a):
  1. Albo będą olewać wszystko inne (np. jakiś pożar na produkcji) żeby nie "tracić czasu", bo się nie wyrobią. Widziałem takie akcje -> coś sie sypie na produkcji a gość odpowiedzialny za dany serwis mówi ci, że mogą ten problem omówić na planningu za tydzień i może wrzucą w kolejny sprint więc przy dobrych wiatrach za 2-3 tygodnie będzie naprawione :D

@Shalom wiadomo że przy pożarach to trzeba interweniować natychmiast, ale być może chodziło o to że klient nie dogadał się z PO/analitykami/programistami i jest powiedzmy minor, czyli że główne funkcjonalności działają i ogólnie przez te 2-3 tygodnie produkcja może żyć?

2

@Pinek nie, po prostu kwestia kto za co jest odpowiedzialny. Twój zespół jest odpowiedzialny za serwisy X, Y i Z, a inny zespół za A, B i C. Wyobraź sobie że twój serwis X zależy od serwisu A i nagle coś przestało działać na tym styku, ale wszystkie "biznesowe" funkcjonalnosci A, B i C działają, więc tamten zespół ma generalnie wywalone na twój problem. A reszta to klasyczna "spychologia" - jak nie chcesz czekać tych 2-3 tygodni aż oni to poprawią, to siadaj i napraw sam a potem wystaw pull request. Wszystko w imie "scruma", żeby tylko się wyrobić na mityczny koniec sprintu ;]

0

@Kamil Raju

, żeby wszyscy mogli pracować jednocześnie, bez konieczności tworzenia mocków,

Ale przecież tego typu mocki w czasie developerki to akurat pożyteczny wynalazek, genialny w swojej prostocie, bo właśnie pozwala pracować jednocześnie. Mock pozwala pracować nad rzeczami, które jeszcze nie są zrobione, więc jest w projekcie odpowiednikiem tego, co w programowaniu nazywa się "promise" albo "future".

Problem zaczyna się wtedy, kiedy mock całkowicie inaczej wygląda/działa niż moduł, który ktoś inny faktycznie robi, ale to wtedy jest to albo porażka komunikacji albo porażka zarządzania (może po prostu nad pewnymi rzeczami nie powinno się pracować za wcześnie).

czekania aż ktoś inny skończy API innego modułu.

Z drugiej strony z mocków można by w ogóle zrezygnować, jeśli ludzie by robili ciągłą integrację i cały czas integrowali nowe API. Więc wtedy zawsze byłoby dostępne prawdziwe API. więc ktoś po prostu tego API by użył, a nie robił mocka.

Tylko żeby to było możliwe, programiści musieliby dostarczać działające kawałki kodu do integracji codziennie, ew. kilka razy na tydzień. A nie raz tydzień, czy dwa tygodnie.

Podobnie działa TDD przy pisaniu logiki, nie stricte dla testów, ale dla jakości kodu.

TDD nie zapewnia dobrej jakości kodu, wręcz przeciwnie. TDD pozwala na bezpieczne pisanie kodu spaghetti (bo zawsze można zrefaktorować). Jedną z korowych zasad TDD jest to, żeby pisać tylko tyle kodu, byleby tylko testy przeszły. Innymi słowy możesz pisać byle jak. Z TDD możesz pisać nawet po pijaku albo od niechcenia i jeśli tylko testy przejdą, to jesteś w domu i masz pewność, że nic nie zepsułeś i że to co robisz, działa (ale TDD nie gwarantuje, że to, co robisz ma w ogóle sens, czy jest wysokiej jakości)..

1

Jak budujesz projekt bottom-up, to nie są potrzebne mocki. Jakby budowlańcy zaczynali budowę od dachu, to w wtedy faktycznie potrzebowali by mocków ścian i fundamentów :P

1

Może po prostu masz za dużo ludzi w projekcie?

1
Kamil Raju napisał(a):

Chodzi o wymóg żeby co piątek program się kompilował i przechodził wszystkie testy.

Nawet w Bangalore nie ma takich niskich standardów.

LukeJL napisał(a):

Ale przecież tego typu mocki w czasie developerki to akurat pożyteczny wynalazek, genialny w swojej prostocie, bo właśnie pozwala pracować jednocześnie. Mock pozwala pracować nad rzeczami, które jeszcze nie są zrobione, więc jest w projekcie odpowiednikiem tego, co w programowaniu nazywa się "promise" albo "future".

Problem zaczyna się wtedy, kiedy mock całkowicie inaczej wygląda/działa niż moduł, który ktoś inny faktycznie robi, ale to wtedy jest to albo porażka komunikacji albo porażka zarządzania (może po prostu nad pewnymi rzeczami nie powinno się pracować za wcześnie).

No i dlatego lepiej pracować na prawdziwych serwisach, nie na mockach. Bo potem nagle może się okazać, że dopasowanie systemu do faktycznej instancji zajmuje wiele miesięcy. A tworzenie i utrzymywanie mocków to też jest koszt, który jest de facto wyrzuceniem pieniędzy w błoto.

Z drugiej strony z mocków można by w ogóle zrezygnować, jeśli ludzie by robili ciągłą integrację i cały czas integrowali nowe API. Więc wtedy zawsze byłoby dostępne prawdziwe API. więc ktoś po prostu tego API by użył, a nie robił mocka.

No i co za problem? Pracuję w firmie, która w ten sposób działa już od wielu lat. Nie ma dodatkowego kosztu utrzymania mocków, nie ma niespodzianek przy podłączaniu do realnego serwisu.
Jedyna wada to to, że czasem realny serwis się może wywalić i zastrzymać pracę zespołu. Ale to jednocześnie zaleta, bo w takiej sytuacji można sprawdzić, czy nasze serwisy prawidłowo sobie radzą w sytuacji failowania swoich zależności. Przy zabawie w mocki nie ma na to szans - zawsze wszystko działa, dopiero po deployu okazuje się, jakie badziewie zostało wdrożone.

0

Do obecnego zespołu i firmy dołączyłem (między innemi), dlatego że w zasadach mieli, robienie mocków do wszystkich zewnętrznych zależności. Dzięki temu można spokojnie pracować nad systemem będąc totalnie offline. Niektóre mocki mają całkiem skomplikowaną logike i symulują całkiem niezłe rzeczywiste systemy.

W poprzedniej firmy ilość strat generowana przez to, ze jakiś z systemów nie działał i nie mozna było nawet GUI dopalić - była kosmiczna. Całe roboczo tygodnie w p...du.

0

@Krolik

Jak budujesz projekt bottom-up, to nie są potrzebne mocki. Jakby budowlańcy zaczynali
budowę od dachu, to w wtedy faktycznie potrzebowali by mocków ścian i fundamentów :P

to, to! Też chciałem to napisać, ale pomyślałem, że nie ma sensu, bo OP i tak pewnie nie wcieli tej zasady, ponieważ zasada budowania top-down jest wręcz dogmatem w wielu firmach (sam fakt, że OP jest "koordynatorem" - czyli w nazwie stanowiska ma wpisaną zasadę top-down). Namawianie do podejścia bottom-up to tak jakby powiedzieć koordynatorowi, żeby przestał być koordynatorem. -

Wydaje mi się, że coś jest szalenie zepsute w metodykach budowania komercyjnego softu. Dlatego właśnie w wielu firmach "agile" panuje dalej waterfall, bo te firmy dalej opierają się na zasadzie top-down (czyli: waterfall), zamiast zrobić coś takiego jak jest w open source projektach - że jeden programista tworzy moduł/bibliotek, a inni programiści używają tej biblioteki. Łączą wiele niskopoziomowych bibliotek/modułów w większe biblioteki, czy w całe aplikacje

Trochę tak jakby to były 2 inne światy, gdzie w open source budowałoby się metodą syntezy (tworzenia czegoś większego z małych elementów - budowanie jak klocków), a komercyjny soft byłby robiony metodą analizy (gdzie bierze się jeden wielki projekt i dzieli się ten projekt na wiele małych stories czy tasków). To wynika w dużej mierze ze struktury władzy (może dziwnie brzmi to słowo w tym kontekście, ale chodzi mi o to, kto podejmuje decyzje, czy idzie z góry, z duchem waterfalla, czy może samowystarczalne zespoły, i poszczególni programiści, mają autonomie piszą soft współpracując ze sobą).

Swoją drogą zamiast dzielenia tasków, ja bym zapronował coś w stylu opracowania spójnych standardów / reguł współpracy / zasad.

bez konieczności tworzenia mocków, lub czekania aż ktoś inny skończy API innego modułu.

Gdyby istniały spójne standardy, to nie trzeba byłoby czekać aż skończy API modułu, ponieważ moduły miałyby standardowy kształt API (wg jakiegoś tam dobrze znanego standardu).

O ile w ogóle nie byłyby skończone (czemu też można by zapobiec przez continous integration).

Czemu tak często w komercyjnym sofcie odkrywa się koło na nowo (NIH) i pisze się soft na zasadzie "wielkich zmian co jakiś czas" zamiast "małych zmian codziennie"?

0

@LukeJL: Nie mam nad sobą nikogo technicznego, tylko Prezes, dla którego liczy się co zrobię, a nie jak. Mogę eksperymentować do woli. Jednocześnie zupełnie nie rozumiem jak mógłbym wprowadzić bottom-up. Projekt zaczyna się zebraniem listy wymagań od klienta. Potem, tak jak mówisz, analiza na moduły, featury, taski. Open Sourcowa synteza rozwija program, ale robi to w przypadkowych kierunkach, podczas gdy ja muszę trafić najkrótszą drogą do postawionej specyfikacji. W jaki sposób zastąpiłbyś taski ogólnym standardem pracy? W sensie, jak taki standard miałby być zdefiniowany?

Ogólnie miło jeżeli ktoś rozwinął by jak wprowadzić to Bottom-Up. Szczerze powiedziawszy sam nie potrafię powiedzieć z którego podejścia korzystam, raz jest tak, raz inaczej.

Btw. Może warto dodać do kontekstu: pracuję nad małymi, krótkimi projektami (1-3 tygodnie) programów lokalnych, nie web. Mocki nie są używane do separacji programu od innych serwisów, tylko udają funkcjonalności, które aktualnie tworzą inni członkowie zespołu.

2

Niezłe. Masz projekty na 1-3 tygodnie i narzekasz. Do tego masz tygoniowe sprinty(?) - co wskazuje na to, że część projektów udaje Ci się zrobić w jednym sprincie. Powiniście dostać wręcz jakąś specjalna nagrodę, bo udaje i sie zrobić projekty w mitycznym modelu waterfall, którego mało kto próbował przed wami. A Ty narzekasz.

Ludzie doskonale opanowali zasady współpracy, robią mocki żeby móc pracowac nad swoimi częściami, nie czekając na innych, a Ty nadal narzekasz.

Trudno Ci tu będzie chyba dostać rozsądne porady, bo nie rozumiem nawet twoich problemów i strzelam, że wielu innych forumowiczów nie ogarnie. Nawet jak pracowałem w Januszsofcie i robiłem strony dla warzywniaków, to wyciągniecie od klienta co ma być na tej pierwszej stronie, poza jego gębą..., wymagało więcej czasu niż te kilka tygodni, w które wy robicie całe projekty.

0

swoją drogą, jeśli jest dużo krótkich projektów, to przypuszczam, że są one jakoś podobne do siebie? Nie można by np. wydzielić wspólnego rdzenia (jakieś biblioteki "core") i używać w kolejnych projektach (żeby jeszcze szybciej szły / albo żeby krócej pracować, a nie 70 h tygodniowo). No i też dużo małych, podobnych (jak przypuszczam) projektów, to też można ustalić jakieś spójne zasady współpracy (między programistami nawzajem, ale także między firmą a każdym nowym klientem), żeby za każdym razem od początku wszystkiego nie wymyślać i nie kłócić się o pierdoły?

(ew. tak jak @jarekr000000 wspomniał - może już jest dobrze i nie trzeba nic zmieniać, bo nie wszystko się da ulepszyć i czasem pewne rzeczy lepiej zostawić w statusie quo?).

Open Sourcowa synteza rozwija program, ale robi to w przypadkowych kierunkach, podczas gdy ja muszę trafić
najkrótszą drogą do postawionej specyfikacji.

To jest dobre pytanie. Z jednej strony przydaje się mieć kogoś, kto nada kierunek (widać co się dzieje w GNU/Linux, gdzie jest totalnie rozdrobniony ekosystem, a istniejące rozwiązania często też są dziwne w obsłudze - np. Gimp, ja się co prawda przyzwyczaiłem, ale wiele osób narzeka). Podobnie te wszystkie setki słabych bibliotek JSowych, które robią to samo (i społeczność JSowa lepiej by skorzystała, gdyby ludzie dopracowywali istniejące narzędzia).

Ale z drugiej strony praca według "postawionej specyfikacji" to zwykle "idiotokracja", bo o kształcie projektu decydują zwykle idioci (nie zawsze oczywiście, ale zwykle tak bywa*). Ew. idąc w poprawność polityczną - ludzie niekompetentni, którzy nie są w stanie przemyśleć tego, co robią, a kierują się płytkimi emocjami/ambicjami (np. "chcę mieć to i to na stronie, bo strona konkurencji to ma").

Więc czy lepsza jest open source'owa anarchia czy dyktatura idiotów? :|

* a te rzadkie przypadki, kiedy na górze jest mądry człowiek, pozwalają na stworzenie czegoś naprawdę fajnego. No ale to rzadko się zdarza, bo nie każdy jest Stevem Jobsem

0

@jarekr000000: jestem ogólnie bardzo zaskoczony i zdziwiony teraz. Myślałem, że podobnie jak ja jesteś przeciwnikiem mockowania, a teraz okazało się, że tak naprawdę jesteś jakimś kryptomockofilem.

Choroba to jest coś negatywnego, co utrudnia funkcjonowanie. Wspólne dla zespołu serwisy i baza ułatwiają pracę, więc nie są chorobą lecz jej przeciwieństwem. Chorobą są mocki, które co prawda na początku pomagają lepiej kłamać, że w kodzie wszystko jest w porządku i wszystko działa, ale kiedyś w końcu nadchodzi czas wielkiego jeb. To jest dobre tylko, jeśli nas nie ma już wtedy w projekcie.

Wspólne serwisy i baza pozwalają na:

  • Oszczędność czasu z instalowaniem i konfigurowaniem dziesiątek serwisów, baz i systemu operacyjnego po to tylko aby uruchomić jakieś odległe zależności swojego projektu.
  • Wygodniejszą pracę, bo mniej softu działającego lokalnie, to też mniejsze zużycie zasobów.
  • Sprawdzenie wytworzonych danych w różnych aplikacjach służących do ich odczytu. Dane wstawione lokalnie widać w systemach postawionych na środowisku zespołowym, dane wstawione tamże są dostępne lokalnie. W przypadku jakichkolwiek błędów wszytko mogę sprawdzić czytając z tych samych baz i serwisów, co testerzy, zamiast żmudnie reprodukować lokalnie.
  • W pewnym zakresie darmowe testy wydajnościowe.
  • Brak big-bang deploymentów i związanego z tym gaszenia pożarów.
  • Cntionous integration na poziomie organizacji, a nie tylko pojedynczej aplikacji.

Wada jest jedna - nie można pracować bez dostępu do sieci. Ale zawsze można wziąć zadanie, który nie wymaga zależności zewnętrznych.

Dla porównania wady mocków:

  • Potrzebne oddzielne testy integracyjne.
  • Potrzeba więcej testów wydajnościowe.
  • Big-bang deployment i gaszenie pożarów po nim.

Co dają mocki?

  • Możliwość pisania kodu współpracującego z nieistniejącymi systemami.
    Czyli kup pan tonę uranu, bo w TV obiecali, że niedługo każdy w domu będzie miał reaktor.
0
somekind napisał(a):

@jarekr000000: jestem ogólnie bardzo zaskoczony i zdziwiony teraz. Myślałem, że podobnie jak ja jesteś przeciwnikiem mockowania, a teraz okazało się, że tak naprawdę jesteś jakimś kryptomockofilem.

Jestem zwolennikiem totalnie prostej i bezproblemowej pracy w samolocie, ogródku i w lesie. Do tego bez konfliktów z innymi teamami i czekaniem aż coś naprawią.
Dawno temu juz pisałem, że nie mockuje zazwyczaj klas kolegów. Nie mockuję też własnych baz danych.

Ale mockowanie i to całkiem zaawansowane - wszelkich systemów zewnętrznych to podstawa. Bez tego straty na "czekaniu" (bo ktoś coś spierd... ) są zbyt duże. I widzę to wystarczająco często, żeby uwierzyć w alternatywne cuda.

Poza tym, lubię sobie pojeździć po konferencjach i nie tylko. Bez zmockowanych serwisów nie miałbym szansy sensownie pokodować.

Zresztą nie muszą to być stricte mocki, jak zapewnisz mi jednoklikowe postawienie całej infrastruktury na moim kompie to jestem jak najbardziej na tak.

EDIT:

Wspólne serwisy i baza pozwalają na:

  • Oszczędność czasu z instalowaniem i konfigurowaniem dziesiątek serwisów, baz i systemu operacyjnego po to tylko aby uruchomić jakieś odległe zależności swojego projektu.

Jak jest kiepska infrastruktura, że ta instalacja zajmuje czas - to tak jest, ale to gdzie indziej jest choroba.

  • Wygodniejszą pracę, bo mniej softu działającego lokalnie, to też mniejsze zużycie zasobów.

Ale większe użycie sieci i potencjalnych problemów z tym związanych. (np. paskudnie wolne działanie lokalnej aplikacji).

  • Sprawdzenie wytworzonych danych w różnych aplikacjach służących do ich odczytu. Dane wstawione lokalnie widać w systemach postawionych na środowisku zespołowym, dane wstawione tamże są dostępne lokalnie. W przypadku jakichkolwiek błędów wszytko mogę sprawdzić czytając z tych samych baz i serwisów, co testerzy, zamiast żmudnie reprodukować lokalnie.

I potem się okazuje, że tester bawił się z uprawnieniami, zasymulował śmierć babci - i twój pracowicie zrobiony przypadek testowy poszedł się rypać. Akurat na demo. (coś podobnego miałem).

  • W pewnym zakresie darmowe testy wydajnościowe.

To jest najlepsze. Jakie testy wydajnościowe, jak wszyscy korzystają w tym czasie ze wspólnej infrastruktury. To jak robienie odcinka specjalnego WRC w centrum Warszawy w godzinach szczytu. Co te testy mierzą? Jak można porównywać ich wyniki?
Przeważnie kończy się to raczej: panowie dziś miedzy 13:00-15:00 nikt nic nie tyka, bo beda robione testy wydajnościowe (autentyk).

  • Brak big-bang deploymentów i związanego z tym gaszenia pożarów.

Mocki nic przecież nie mają wspólnego z big bang deployment. WTF? Raczej jest stałe gaszenie pożarów, bo wrzucenie drobnej, experymentalnej zmiany na DEV kończy się krzykiem z sąsienich zespołów, że im nie działa.... Nie możesz np. przetestować kawałka infrastruktury z nowymi serwisami itp.

  • Cntionous integration na poziomie organizacji, a nie tylko pojedynczej aplikacji.

Ja to przerabiałem i to był continuues desintegration. Testy e2e były wywalone przez pół roku - zawsze coś było nie tak i nie dawało się ustabilizować (przy 150 developerach i 120 aplikacjach zawsze ktos coś grzebie).

0
jarekr000000 napisał(a):

Ale mockowanie i to całkiem zaawansowane - wszelkich systemów zewnętrznych to podstawa. Bez tego straty na "czekaniu" (bo ktoś coś spierd... ) są zbyt duże.

To jest mnie niż minuta czekania, bo tyle trwa przywracanie poprzedniej wersji z panelu TeamCity.

Zresztą nie muszą to być stricte mocki, jak zapewnisz mi jednoklikowe postawienie całej infrastruktury na moim kompie to jestem jak najbardziej na tak.

Ty chyba w ogóle nie czytasz tego, co ja piszę. Zupełnie nie chodzi mi o to, żeby mieć wszystko łatwo postawione u siebie.

Ale większe użycie sieci i potencjalnych problemów z tym związanych. (np. paskudnie wolne działanie lokalnej aplikacji).

Ok, tak się czasem może stać. Akurat nie u mnie, bo straty na transferze przez sieć nadrabia przetwarzanie na nieco lepszych niż developerska maszynkach w chmurze.

I potem się okazuje, że tester bawił się z uprawnieniami, zasymulował śmierć babci - i twój pracowicie zrobiony przypadek testowy poszedł się rypać. Akurat na demo. (coś podobnego miałem).

No, ale jak pisałem, to jest jakiś problem albo z testerem albo z tym, że macie jedną babcię do testów. Nie wiem, kto zarządza babciami do testów, ale może da się ich załatwić więcej... babcie nie są drogie. Ale ok, rozumiem, że w jakimś tam specyficznym przypadku u Ciebie tak to nie może działać. Ja mam o tyle łatwiej, że po prostu sam sobie klientów tworzę.
Nie rozumiem tylko czemu brak testowych użytkowników wymusza stosowanie mocków. Jak na moje proste rozumowanie, to są to niezależne kwestie.

To jest najlepsze. Jakie testy wydajnościowe, jak wszyscy korzystają w tym czasie ze wspólnej infrastruktury. To jak robienie odcinka specjalnego WRC w centrum Warszawy w godzinach szczytu. Co te testy mierzą? Jak można porównywać ich wyniki?

Dlatego napisałem "w pewnym zakresie". Nie chodzi mi o mierzenie szybkości przetwarzania requestów, ale np. o to, że jeśli na naszym środowisku user na którym chodzą testy integracyjne ma zrealizowanych 100 tys zamówień i da się bez problemu przeglądać ich historię, to znaczy, że z typowym klientem na produkcji też nie będzie problemu.

Przeważnie kończy się to raczej: panowie dziś miedzy 13:00-15:00 nikt nic nie tyka, bo beda robione testy wydajnościowe (autentyk).

Ja też - ale tylko tam, gdzie były mocki. Po zgaszeniu pożarów po big-bang deploymencie można było dopiero zacząć testowanie wydajnościowe.

Mcoki nic to przecież nie mają wspólnego z big bang deployment? WTF?

Skoro mocki stosuje się po to, aby móc pisać kod dla nieistniejącej zależności, to gdy ona w końcu powstanie, to zostanie na raz wdrożona w całej swej okazałości. To jest big-bang deployment.
I z tym przede wszystkim kojarzą mi się mocki, bo coś takiego przeżyłem kilka lat temu. Przez 1,5 roku soft był tworzony w oparciu o mocki, a potem przyszedł faktyczny system i wszystko stanęło w miejscu, bo okazało się, że poza standardowymi rzeczami takimi jak niezgodność formatów danych po serializacji, to autoryzacja trwa 5 minut.
To było 3 lata temu, na produkcję wyszli jakoś na wiosnę tego roku. Tyle w temacie braku chorób bez mocków.

Raczej jest stałe gaszenie pożarów, bo wrzucenie drobnej, experymentalnej zmiany na DEV kończy się krzykiem z sąsienich zespołów, że im nie działa....

Nie ma żadnego DEV. Są środowiska zespołów: Dev1, Dev2 ... Dev150. Na każdym środowisku zespół rozwija swój soft i ma zainstalowane zależności innych zespołów. Nikt z drugiego zespołu swoimi eksperymentami nie zepsuje mi mojego środowiska. Może się to stać dopiero, gdy my sobie zainstalujemy nową wersję oficjalnie stabilnej zależności. Wtedy trzeba przywrócić poprzednią wersję, a autorom zgłosić buga.

Nie możesz np. przetestować kawałka infrastruktury z nowymi serwisami itp.

Mogę - robię Dev151, albo raczej korzystam z jakiegoś porzuconego środowiska.

Ja to przerabiałem i to był continuues desintegration. Testy e2e były wywalone przez pół roku - zawsze coś było nie tak i nie dawało się ustabilizować (przy 150 developerach i 120 aplikacjach zawsze ktos coś grzebie).

A u nas jest 350 developerów, 200 serwisów oraz 800 narzędzi pomocniczych, do tego kilkanaście stron www i jakoś wszystkie testy działają. W ogóle wszystko jest stabilne, na produkcji także.

1
somekind napisał(a):

Ok, tak się czasem może stać. Akurat nie u mnie, bo straty na transferze przez sieć nadrabia przetwarzanie na nieco lepszych niż developerska maszynkach w chmurze.

Ty nie wiesz jaką ja mam maszynę :-) Prawda jest taka, że u głownego klienta nie mogę jednak na niej developować.

Skoro mocki stosuje się po to, aby móc pisać kod dla nieistniejącej zależności, to gdy ona w końcu powstanie, to zostanie na raz wdrożona w całej swej okazałości. To jest big-bang deployment.
I z tym przede wszystkim kojarzą mi się mocki, bo coś takiego przeżyłem kilka lat temu. Przez 1,5 roku soft był tworzony w oparciu o mocki, a potem przyszedł faktyczny system i wszystko stanęło w miejscu, bo okazało się, że poza standardowymi rzeczami takimi jak niezgodność formatów danych po serializacji, to autoryzacja trwa 5 minut.
To było 3 lata temu, na produkcję wyszli jakoś na wiosnę tego roku. Tyle w temacie braku chorób bez mocków.

I tu leży pies pogrzebany. Zupełnie nie przyszło mi nawet do głowy developowanie na mockach bez ciągłej weryfikacji z normalnymi serwisami. Skąd ten pomysł? Ja sobię głównie programuje na mockach na mojej maszynie (zresztą przestawiam czasem wajchy na realne, bo np. testuje nową wersję serwisu). Natomiast i tak każdy push leci na takiego deva dla mojego zespołu. Czasem tam zaglądam nawet.
I tam już mamy różne walki z innymi zespołami - najczęsciej związane z security. zwykle przywrócenie czegoś trwa... pół dnia (taką ma infrastukturę klient, najlepsze jak wywali się przy tym jenkins (czyli odpowiednik teamcity :-) ) ). Dla mnie jest wązne, że mogę iść (prawie) zawsze z developerką do przodu, również jak jestem w pociągu w tunelu (ważny problem pierwszego świata).

Z dodatków:
Częśc tych mocków to sa całkiem ciekawe symulatory - potrafią wygenerować mi w parę minut ruch i dane, który prawdziwi testerzy i systemy musieliby robić przez 3 dni. Co więcej na lokalnej maszynie robię sobie clean - czyszcze wsie bazy danych i za pare minut mam system postawiony od nowa. Z danymi testowymi na czysto od konkretnej daty. Niektórych ficzerów (przez dość skomplikowane obliczenia) nie byłbym w stanie przestestować na realnym devowym środowisku. Wyszłyby mi liczby, których nie mógłbym w rozsądnym czasie zweryfikować, za dużo danych, a tak wiem jakie dla mam mieć wyniki i jak mają się prezentować w GUI wykresy na dany dzień. Współczuje białkowym testerom, którzy to musza na faktycznych danych z systemu sprawdzać, mają chyba excele cięższe niż mój kod backendu.

Podsumowując: z pewnością chęć do mocków wynika czasem z takiej sobie infrastruktury u niektórych klientów. Ale mam te mocki/symulatory nawet tam gdzie infrastruktura jest całkiem dobra, albo prosta - np. zależę od raptem jednego serwisu. Mam kilka tuneli na trasie do pracy, mój symulator potrafi przez parę minut wygenerować ruch za cały rok - co świetnie pozwala mi sprawdzać działanie systemu pod obciążeniem, na mojej prywatnej 8kilowej chmurze.

EDIT:
Tak się składa, że po prostu prawcowąłem już w różnych systemach - tylko realne połączenia z serwisami, do bólu i wszystko zamokowane( z zewnętrznych połączeń). Druga wersja na tyle przypadła mi do gustu, że jest w liscie pytań do pracodawcy (i do obecnej firmie trafiłem, bo pokazali mi te mocki). Gdybym nie jeździł po konferencjach i nie spędził wielu smutnych godzin czekając na to aż goście z infrastruktury coś naprawią, bo im się omskło - to może bym nie miał takiego podejścia.

1 użytkowników online, w tym zalogowanych: 0, gości: 1