Jak zorganizować zespół i poprowadzić projekt.

Odpowiedz Nowy wątek
2018-08-28 14:45
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?

Pozostało 580 znaków

2018-09-13 13:44
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.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 2x, ostatnio: jarekr000000, 2018-09-13 13:47
Pokaż pozostałe 15 komentarzy
@somekind: coś podkapcasz? WYstarczy, że byłem ileś razy w takich głupich konstelacjach to wiem jak to wygląda. Żadnych sabotazystów tu nie trzeba i żadnego kasowania w bazie (nic o bazie nie pisałem). Trzech ludzi odpala co lepsze testy e2e równocześnie i się wywala, jeśli idzie na wspólnej bazie danych (zweykle wielu wspólnych bazach), bo własnie mamy np. tych samych userów. I się konta nie zgadzają... Na zakłamanych zależnościach można przetestować wszystko - nawet cały bank - nawet zasymulować dwa lata pracy. - jarekr000000 2018-09-21 15:19
Nie znam słowa podkapcać. Nawet jeśli nie chodziło Ci o bazę, to napisałeś o kasowaniu. Odpalenie testów e2e powoduje znikanie danych? Nie rozumiem jak. - somekind 2018-09-21 15:27
Bo np. testuje dość konkretnie, rejestrowanie użytkownika w systemie, obsługe jego konta, zawieszanie jego konta i co dość ważne: koniec współpracy (ten ostatni punkt nawet szczególnie trudny/zabawny). Do tego jeszcze nie tylko w bazach aplikacji, ale jeszcze w całym security. A ponieważ system działał właśnie jak normalny, normalny stage DEV/INT - to nie za bardzo działać mogło wymyślanie użytkowników. Np. przez dość ograniczona pulę dostępnych userów z ldap, na potrzeby testów - dramat. - jarekr000000 2018-09-21 15:33
A to serio nie można mieć więcej userów do testów i programiści muszą się nimi dzielić? Jak dla mnie to wygląda na problem organizacyjny. - somekind 2018-09-21 15:40
Tak, to jest problem organizacyjny pod tytułemjedna współdzielona infrastruktura do testów. Za to prawdziwa. - jarekr000000 2018-09-21 15:41

Pozostało 580 znaków

2018-09-14 01:53
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"?


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 5x, ostatnio: LukeJL, 2018-09-14 12:59

Pozostało 580 znaków

2018-09-21 00:15
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.

Pozostało 580 znaków

2018-09-21 09:17
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.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 3x, ostatnio: jarekr000000, 2018-09-21 09:41
Nie narzekam, mam nadzieję że to tak nie zabrzmiało. Praca idzie bardzo dobrze, firma dostaje coraz więcej zleceń, całość się rozrasta. Ale sam mówisz że robię typowego Waterfalla. Narzucone przeze mnie sprinty to też chybiony pomysł. Poza tym, pierwszy raz spotkałem się z określeniem organizacji Bottom-Up. Właśnie o takie rzeczy pytam, nie zawsze będę miał wokół siebie tylko doświadczonych ludzi, chcę być dobry w tym co robię. Projekty 1-3 tygodnie, ale pracowania w opór po 70 godzin tygodniowo, ot, specyfika branży. - Kamil Raju 2018-09-21 13:19
70 godzin tygodniowo? Specyfika branży? To branża cyrkowa? - jarekr000000 2018-09-21 14:12
Kioski multimedialne. Klient zgłasza że potrzebuje xyz na targi, oczywiście na ostatnią chwile, my klepiemy. 2-3 tygodnie gułagu, potem tydzień-dwa luzu, wolne albo po 3-4 godziny przy utrzymaniu programów które są w stałej ofercie. Cokolwiek każde zlecenie to niezły wyścig z czasem, więc cały proces deweloperski musi być dobrze spasowany. - Kamil Raju 2018-09-21 14:49
Czyli cyrk. Nawet byłem w okolicach tego cyrku (reklama). I tak bardzo mnie nie zmęczyły te głupie terminy jak niestety klienci - w tej branży chyba trzeba mieć wyobraźnie porównywalną z workiem cementu, żeby zostać tzw. kreatywnym. - jarekr000000 2018-09-21 14:57

Pozostało 580 znaków

2018-09-21 13:52
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


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
mając teraz 60 lat, prawdopodobnie urodziłeś się gdy tranzystory umożliwiły rozpoczęcie miniaturyzacji, pierwsze systemy unix kiełkowały i języki programowania. Większość pracy steva jobsa to było wzięcie hajsu za te opensource projekty i przeznaczenie tych środków na rozwój, który dalej był płatne. On tylko zgarnął wszystko co ludzie stworzyli i rozwinął z ich sprzedaży. - Szalony Programista 2018-09-21 15:11

Pozostało 580 znaków

2018-09-21 15:30
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.

"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2018-09-21 15:40
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).


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 8x, ostatnio: jarekr000000, 2018-09-21 16:23

Pozostało 580 znaków

2018-09-21 17:24
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2018-09-21 19:36
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.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 7x, ostatnio: jarekr000000, 2018-09-21 19:45

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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