Tak, rzeczywisty świat znacznie różni się od tego, czego uczysz się na uniwersytecie.

Kiedy pracujesz dla firmy, zadaniem jest osiąganie zysków, a nie dostarczanie oprogramowania zgodnie z wyidealizowanym oprogramowaniem proces rozwoju. W większości przypadków te rzeczy się pokrywają, ale nie zawsze.

Od czasu do czasu „iść na skróty” jest całkowicie uzasadnione.

Chociaż możesz narzekać, że szef tego nie robi Aby zrozumieć znaczenie testowania oprogramowania, mogą narzekać, że nie jesteś świadomy presji biznesowej, która ma wpływ na biznes. Oznacza to, że może być konieczne wysłanie rzeczy bez automatycznego testowania. Uważam, że nie jest sprawiedliwe klasyfikowanie twojego szefa jako ignorującego znaczenie testów. Oczywiście przypisują temu inny stopień ważności niż ty lub są świadomi różnych czynników tego, kim jesteś.

Twoja rola w tej sytuacji polega na zwróceniu uwagi na ryzyko związane z brakiem automatycznych testów swojemu przełożonemu i pozwól im dokonać oceny, mając wszystkie dostępne informacje.

Tworzenie oprogramowania polega na zarządzaniu ryzykiem w nieznanych lub niepewnych środowiskach, a jednocześnie często wykonuje nowatorskie prace. Kompromisy dotyczące czasu, zakresu i jakości mają miejsce przez cały czas. Ważne jest, aby pomóc interesariuszom zrozumieć wpływ ich decyzji na projekt. Według mnie odpowiedzi typu „rzucić pracę” lub „zgłoś problem” byłyby zarezerwowane dla przypadków, w których decyzje podjęte w ramach projektu miałyby poważne konsekwencje dla życia i bezpieczeństwa, prywatności lub poufności, bezpieczeństwa lub innego „krytycznego czynnika” (co będzie się różnić w zależności od tego, co tworzysz).

Niestety nie ma sprawdzonych metod ani algorytmów służących do podejmowania takich decyzji. Nauka przychodzi z czasem i doświadczeniem. Możesz studiować doświadczenia innych, ale najlepsze doświadczenia należą do Ciebie i pracuj nad kompromisami ze swoimi współpracownikami, aby zrozumieć uzasadnienie procesu podejmowania decyzji. Takie decyzje są bardzo zależne od kontekstu.

Tak, dług techniczny jest w wielu przypadkach całkowicie uzasadnioną decyzją; Podobnie jak zaciągnięcie realnego długu jest w wielu przypadkach ważną decyzją biznesową, mającą na celu realizację celów biznesowych. (Zarobimy $ $, gdybyśmy mieli $ do zainwestowania w biznes, więc zaciągnięcie pożyczki za $ i spłata $ $ nadal daje nam przewagę na dłuższą metę.)

Ale moim zdaniem pomijanie testów automatycznych nigdy nie jest dobrą pożyczką . Zaoszczędzony czas jest często wykorzystywany nie w latach czy miesiącach, ale tygodniach. (A spłata staje się wykładniczo trudniejsza.) Nie pomijaj testów, chyba że termin płatności przypada dzisiaj; to nie będzie tego warte.

To jeden z powodów, dla których warto śledzić TDD IMHO. Ponieważ nigdy nie jesteśmy w sytuacji, w której możemy powiedzieć, że funkcja jest „ukończona”, ale „nadal wymaga przetestowania”. To zbyt kuszące dla nietechnicznego menedżera, aby odciąć testy i nazwać je wykonanymi. Mają teraz tylko znacznie lepsze opcje ograniczania zakresu, zmiany harmonogramu dostaw lub, gdy jest to naprawdę konieczne, korzystania z innych rodzajów długu technicznego (nadużywanie zarządzania stanem, pomijanie solidnych architektur itp.).

To, co nazywasz „skrótami”, to w rzeczywistości kompromisy i są nieodłącznie związane z każdym projektem, w każdej dyscyplinie, którą podejmiesz. To jest nieuniknione. W świecie inżynierii istnieje idiom (tak, umieściłem to w komentarzu powyżej): Możesz to zrobić dobrze, możesz to zrobić szybko lub tanio. W najlepszym przypadku możesz wybrać 2, więc musisz podjąć decyzję, które 2 są najważniejsze w danych okolicznościach.

Aby użyć swojej sytuacji jako przykładu, masz mały zespół ( tanio) i napiętym terminie (szybko), więc wynika z tego, że to, co zbudujesz, będzie prawdopodobnie miało wiele błędów i możesz nie dostać się do testów, które chcesz zrobić. To jest decyzja, którą podjął twój menedżer i będzie musiał poradzić sobie z jej konsekwencjami. Chcesz przeprowadzić więcej testów, aby stworzyć lepszy produkt? Będzie musiał albo dać ci więcej czasu (stracić na „szybkich”), albo dodać więcej osób do wykonania testów (stracić „tanio”). To po prostu może nie być opcją dla projektu. To jest nieuniknione.

Więc rzucenie pracy niczego nie rozwiąże, ponieważ ta zasada będzie tam gdziekolwiek pójdziesz. Jedyne, co możesz zrobić, to znaleźć innego pracodawcę, który może kładzie nacisk na inną część triady, ale nawet to będzie się różnić w zależności od projektu. Podejmują decyzje tak, jak Twój obecny menedżer.

Każda decyzja podjęta przeciwko tej triadie będzie miała konsekwencje i ktoś będzie musiał dowiedzieć się, czy są one do przyjęcia. Spowolnienie w tworzeniu lepszego produktu oznacza, że ​​możesz przegapić termin. Dodanie większej liczby osób oznacza, że ​​nie będą pracować nad czymś innym. Zbudowanie go szybko i tanio oznacza poświęcenie więcej czasu na późniejsze wspieranie go (lub życie z tandetnym produktem). W zależności od wymagań każda z tych decyzji może być ważna. Kluczem jest zrozumienie kompromisów, ich znaczenia dla biznesu i upewnienie się, że decydenci je rozumieją. To jedna z najważniejszych umiejętności, jakie możesz posiadać.

„Kompromisy” są prawie zawsze wymagane, ale dostarczanie bzdur już nie. Jeśli zostaniesz poproszony o dostarczenie śmieci, rozważ odejście. Lub, jeśli oprogramowanie dotyczy finansów, bezpieczeństwa informacji lub zdrowia, uciekaj . (Bo gdy to się nie powiedzie, zarząd będzie szukał kozłów ofiarnych.)

Jakie działania należy podjąć: pierwsze to wyjaśnienie przełożonemu, jaki koszt może spowodować skrót dla firmy. W najgorszym przypadku skrót oznacza zagrażanie i prawdopodobnie zabijanie ludzi. Najbardziej nieszkodliwym przypadkiem jest naprawienie problemu w przyszłym tygodniu i nic się nie dzieje. Twój kierownik musi wiedzieć, co to znaczy podjąć świadomą decyzję.

Następną czynnością jest podjęcie kroków, które „naprawią” skrót w razie potrzeby. Czasami nie jest to potrzebne. Czasami piszesz oprogramowanie do jednorazowego użytku i albo działa, albo nie, i możesz zobaczyć, czy zadziałało. W takim przypadku, jeśli oprogramowanie działało, nie ma znaczenia, jakie skróty wybrałeś.

Czasami skróty są uzasadnione. Powiedzmy, że jesteś jedynym programistą, a oprogramowanie musi być gotowe w dniu X. Jeśli jesteś gotowy w dniu X, firma zarabia dużo pieniędzy, wystarczy, aby zatrudnić dwóch kolejnych programistów. Jeśli nie jesteś gotowy w dniu X, firma nie zarabia i tracisz pracę. Najwyraźniej wybierasz skrót. Jeśli wszystko działa dobrze, dwaj dodatkowi programiści mogą więcej niż posprzątać cały bałagan, który powstał po to, by działać szybko.

Dobrze, jeśli możesz nauczyć swojego menedżera, że ​​jeśli Twoje oprogramowanie jest w dobrym stanie, możesz czasami iść na skróty. Możesz być w stanie wykonać pracę, która powinna zająć cztery tygodnie w ciągu tygodnia (ale teraz oprogramowanie jest pomieszane). Ale możesz to zrobić tylko raz, a potem musisz poświęcić trzy tygodnie na sprzątanie. Jeśli nie posprzątasz, następne cztery tygodnie pracy zajmą albo siedem tygodni łącznie ze sprzątaniem, albo cztery tygodnie pozostawiając jeszcze więcej bałaganu, a potem masz kłopoty.

Chciałbym podważyć przesłankę twojego pytania.

Kto jest ekspertem w tworzeniu oprogramowania? Ty czy Twój szef? Twój szef zatrudnił cię, ponieważ jesteś ekspertem, profesjonalistą. Automatyczne testowanie jest częścią Twojej pracy. Zachowuj się więc jak profesjonalista i wdrażaj testy automatyczne, jeśli uznasz to za konieczne. Czy Twój szef również decyduje o tym, czy klikniesz, aby przejść do następnej linii, czy użyjesz klawiatury? Czy Twój szef decyduje, czy używasz tabulatorów czy spacji? Twój szef nie ma w tym nic do powiedzenia, chyba że jest też programistą. To samo dotyczy testów automatycznych. Są częścią twojej pracy i twój szef też nie ma w tym nic do powiedzenia.

Jasne, czasami chcesz kompromisów, ale szefowie mogą wybierać tylko funkcje. Mogą również poprosić Cię o szybsze programowanie. Ale tylko Ty, profesjonalista, którego zatrudnili do rozwoju, możesz decydować o kompromisach dotyczących jakości kodu. Twoim zadaniem jest wiedzieć, co sprawia, że ​​programujesz szybciej, a nie ich.