"Dzwony dzwonią ale nie wiadomo w którym kościele" - tutaj prezentujecie inne podejście https://www.spreaker.com/user/devenv/devcast-06 ~4:25 "Mieliśmy dużą ilość testów na różnych poziomach którym kompletnie nie był w stanie zaufać. Nie były deterministyczne. [...] Spotykasz dużą ilość testów, sam brak nie musi być rzeczą negatywną bo ich nadmierna ilość albo ich wadliwa jakość też może nie być dobra dokumentacją projektu. " Pragmatyzm ponad dogmatyzmem - tzn KPI / cel aby osiągnąć 100% test coverage nie jest dobrym. Dobry programista pisze dobre testy, tworzy dobrą architekturą, tworzy dobry design.

Osobiście jestem zdania że testy jednostkowe należy ograniczyć do minimum, tam gdzie naprawdę maja one sens. Np. mam jakąś klasę enkapsulujacą operacje na czasie, wtedy chce ja oddzielnie pokryć testami jednostkowymi aby sprawdzić każdy przypadek użycia. W każdym innym razie zdaje się na testowanie konkretnego scenariusza w obrębie danej aplikacji/serwisu. Podmieniam zewnętrzne zależności (inne serwisy, bazy danych itp.) natomiast (zakładając aplikację webową) w teście stawiam wirtualny host, wykonuje jakiś request i sprawdzam wynik. W ten sposób testowany jest cały pipeline danej operacji. Osiągam te same profity co przy użyciu testów jednostkowych, ale bez niepotrzebnego rozdrabniania się i kilku/kilkunastu testów wyrwanych z kontekstu, w miejsce jednego który właśnie tenże kontekst testuje.

Przez jakiś bug nie mogę zmodyfikować mojego postu, a wypadałoby dorzucić inną ważną informację: każda struktura w Ruście ma z góry określony, znany w trakcie kompilacji rozmiar (w odniesieniu do pierwszego cytowanego przeze mnie wyżej fragmentu). Typami odbiegającymi od tego są jedynie traity i slice'y (https://doc.rust-lang.org/nomicon/exotic-sizes.html).

Dzięki @Patryk27.

• W Rust nie ma słówka kluczowego class, ale jakoś struktura, która implementuje traity lub własne funkcje jest dla mnie klasą. Reprezentuje dane wraz z zachowaniami.
  Trait to jest deklaracja interfejsu podobna do tych z C# lub Javy, ale nie identyczna.

• Miałem to rozdzielone, bo to o czym wspominasz czyli implementacja trait Copy opisana była poniżej. Podkreśliłem to bardziej.

• Typy proste to prymitywy. Typy złożone to struktury.

• Co macie na myśli poprzez wykorzystać dziedziczenie? Zmieniłem by było jasno wypisane, że chodzi o implementacje konkretnego traita a nie o całe zjawisko dziedziczenia.

• W kolejnych częściach planuje opisać: Borrowing, wpływ mutowalności, slice. Nie chciałem naraz wprowadzać dużej ilości pojęć. Dodałem zdanie zapowiadające by czytelnik wiedział.

• Rc, Arc, Mutex planuje wprowadzić dopiero w późniejszych częściach, bo to są mechanizmy skierowane na współbieżność.

Dzięki za feedback i pomoc :)

DSL w Groovym czy Rubym pisze się równie łatwo. I nawet lepiej to wygląda (wcale nie jak hybryda, którą straszą w artykule) bo tam przy jednym argumencie nawiasy są opcjonalne. W Lispie musisz używać dodatkowo nawiasów. Gdy ktoś chce programować funkcyjnie to część osób go odradza także ze względu na dynamiczne typowanie.

Niby scrum master OK, ale gdy pojawiają się w teamie problemy to ani scrum master ani kierownik nie pomoże, tylko zamiatanie pod dywan, bo nikt nie chce problemów widzieć, a jak ty widzisz problem, to podejście, że to ty masz problem. Szkoda gadać, można wydać fulll kasy na scrum masterów, konsultacje z agile itp itd a ludzi zostawić samych z ich problemami. Taka patologia, gdzie liczą się pozory a nie realne działania i zdrowy rozsądek.

Najlepiej zatrudnić dwóch i patrzeć jak się zabijają próbując pokazać którego scrum jest bardziej scrumowy i który jest bardziej agile