W którym momencie zrezygnowałbyś z niektórych zasad tworzenia oprogramowania ze względu na więcej pieniędzy?

Chciałbym zadać to pytanie, aby ciekawie zobaczyć, gdzie jest to medium.

Przyznam, że w ciągu ostatnich 12 miesięcy kupiłem TDD i wiele zwinnych wartości w tworzeniu oprogramowania. Byłem tak przytłoczony, o ile lepszy stał się mój rozwój oprogramowania, że ​​nigdy nie porzuciłbym ich z zasady. Aż do ... zaproponowano mi kontraktową rolę, która podwoiła moje wynagrodzenie za rok.

Firma, do której dołączyłem, nie stosowała żadnej konkretnej metodologii, zespół nie słyszał czegoś takiego jak zapachy kodu, SOLID itp., A na pewno nie zamierzałbym uciec od spędzania czasu na TDD, gdyby zespół nigdy nawet widziane testy jednostkowe w praktyce. Czy jestem wyprzedany? Nie, nie do końca ... Kod zawsze zostanie napisany „czysto” (zgodnie z naukami wuja Boba), a zasady SOLID zawsze będą stosowane do kodu, który piszę, gdy jest potrzebny. Testowanie zostało jednak dla mnie przerwane, firma nie mogła sobie pozwolić na przekazanie tak nieznanego zespołu, który, szczerze mówiąc, nawet ja stworzyłem ramy testowe, nigdy nie użyliby / nie utrzymywali poprawnie ramy testowej.

Korzystając z tego jako przykładu, w jakim sensie deweloper nigdy nie powinien rezygnować z zasad kunsztu w imię pieniędzy / innych korzyści dla nich osobiście? Rozumiem, że może to być bardzo osobista opinia na temat troski o własne potrzeby, potrzeby biznesowe, rzemiosło itp. Można jednak pomyśleć, że na przykład można zrezygnować z testów, jeśli firma zdecyduje, że wolałaby zespół testowy, zamiast rozumieć testowanie jednostkowe w programowaniu, czy byłoby to coś, za co mógłbyś sobie wybaczyć, tak jak ja? Więc biorąc pod uwagę, że jest coś, co byś upuścił, zwykle w biznesie powinien być taki sam koszt, który zrekompensuje to, co upuścisz - miejmy nadzieję, chyba że oczywiście jesteś dość chętny do wyłożenia własnych kieszeni i nie współpracujesz ze społecznością / społecznością; ).

Podwój swoje pieniądze, wróć do RAD? Lub chodź dalej i poszukaj kogoś, kto robi Agile, i nigdy nie oglądaj się za siebie ...

Ponieważ uzależniłem się od testów jednostkowych ponad 10 lat temu, w większości moich miejsc pracy byłem pierwszym, który o nich słyszał. Niemniej jednak ciągle pisałem moje małe testy jednostkowe, kiedy tylko mogłem, i oszacowałem koszt testów jednostkowych w moich zadaniach. Ilekroć ktoś pytał o moje nawyki kodowania, mówiłem, co robię i dlaczego to działa. Zwykle przynajmniej niektórzy ludzie byli zainteresowani i ostatecznie mogłem wygłaszać prezentacje na ten temat i pomagać ludziom w pisaniu pierwszych testów jednostkowych.

Nie musisz zaczynać przekonywać ludzi o zwinnym sposobie już pierwszego dnia w nowym miejscu pracy. Po prostu przestrzegaj zasad w swojej pracy, jak możesz. Jeśli zrobisz to dobrze, dostarczysz lepszy kod. Jeśli twoi współpracownicy i / lub kierownictwo to zauważą, zapytają, jak to robisz. Potem możesz im powiedzieć.

Aktualizacja

Większość doświadczonych programistów (i menedżerów) widziała trendy i mody, więc nie ekscytują ich najnowsze modne słowa. Jeśli jednak potrafisz wykazać, że pewne podejście (narzędzie, sposób myślenia) naprawdę działa w praktyce, w rzeczywistym projekcie ci, którym zależy na ich rzemiośle, prawie na pewno usiądą i będą słuchać. Ale jeśli nie masz takich ludzi w zespole, może czas poszukać lepszego miejsca ...

Myślę, że w tym miejscu wszyscy programiści powinni znać trochę zarządzanie projektami. Wszystko jest kompromisem między czasem, pieniędzmi i zasobami. Uważaj się za zasób.

W ciągu 12 lat programowania nie sądzę, że kiedykolwiek ukończyłem projekt i uważałem go za zrealizowany lub kompletny w mojej głowie. Zawsze było coś, co chciałbym móc zrobić lepiej lub bardziej. Bardzo długo zajęło mi zrozumienie, że dzieje się tak z powodu tych kompromisów.

Więc jeśli myślisz o zmianie pracy tylko dlatego, że nie ma metodologii, pomyślałbym jeszcze raz, gdybym był tobą. Te kompromisy są stałe i dotyczą wszystkich programistów. Nawet najbardziej oddani twórcy gier chcieliby, aby mogli zrobić coś jeszcze raz lub przećwiczyć inną metodologię, gdyby mieli szansę.

Powiedziałbym, że powinieneś przyjrzeć się swoim zwinnym praktykom programistycznym i zdać sobie sprawę, że możesz to zrobić nawet na poziomie mikro. Upewnij się, że twoi koledzy z zespołu mogą być na lądzie, robiąc wszystko, co chcą, ale twoja osobista satysfakcja będzie większa i na pewno wygenerujesz lepszy kod niż oni na dłuższą metę. Kiedy menedżer przychodzi i pyta, dlaczego Twój kod jest o wiele lepszy, masz szansę przekonwertować zespół :)

Ale jeśli nie lubisz ludzi ani pracy, myślę, że znasz już odpowiedź. Ale bardzo wątpię, aby ktokolwiek wszedł do pokoju i powiedział ci, abyś nie stosował zwinnych zasad programistycznych podczas kodowania ... jeśli to zrobi ... zacznie krzyczeć.

Nigdy nie upuszczaj czegoś, co sprawi, że będziesz nieszczęśliwy na dłuższą metę. Oczywiście możesz zacząć od lądu bez ziemi i spróbować popchnąć drużynę w twoim kierunku. Jeśli chcesz włożyć w to wysiłek, a praca jest tego warta, może to być nawet interesujące wyzwanie.

Ale jeśli musisz zostawić te same rzeczy, które utrzymują przyjemność z kodowania (lub jakąkolwiek inną pracę w tym zakresie), moje doświadczenie jest takie, że prędzej czy później odejdziesz. Dowiedziałem się, że frustracji nigdy nie należy lekceważyć ...

Ludzie w twojej ostatniej pracy wiedzieli już o TDD, SOLID itp. To świetnie. Jestem pewien, że dobrze się tam pracujesz i dużo się nauczyłeś. Teraz masz okazję uczyć tych pojęć (jednocześnie zarabiając duże pieniądze). Z mojego doświadczenia wynika, że ​​konieczność uczenia kogoś innej koncepcji zawsze pomogła mi nauczyć się jej jeszcze bardziej szczegółowo. Po prostu bądź cierpliwy wobec nich i kontynuuj wdrażanie swoich pomysłów pojedynczo. Kiedy czujesz się sfrustrowany, idź do domu i licz swoje pieniądze. Lub poszukaj wsparcia w SE.

Muszę przyznać, że pod tym względem jestem * * *. Jako freelancer, niezależnie od tego, co klient uzna za odpowiednią metodologię dla projektu, nie mam nic przeciwko. To nie znaczy, że pieniądze są jedyną rzeczą, na której mi zależy, ale decyzja o tym, co robić i co pominąć, zależy od klienta. Jednak nie zaakceptowałbym złych warunków pracy (głośno, długie godziny itp.).

Chcę zacytować mojego byłego kolegę. Powiedział, że za każdym razem, gdy szuka pracy lub projektu w niepełnym wymiarze godzin, muszą spełnić trzy kryteria:

• Praca z nim musi być fajna
• Musi to korzystnie wpłynąć na rozwój kompetencji (nie jestem pewien, czy to właściwy sposób wyrażenia tego)
• Powinien dobrze zapłacić

Kiedy czytam twoje pytanie, ten projekt spełnia tylko ostatnie kryteria.

Ponieważ polubiłeś TDD (tak jak ja), myślę, że będziesz się codziennie przemieszczać i żałować, że wszyscy twoi współpracownicy nie osiągnęli takiego samego wglądu, jak ty. Pierwsze kryteria prawdopodobnie nie zostałyby spełnione.

Po drugie, jeśli chcesz realizować projekty TDD i być może zdobycie większego doświadczenia w budowaniu zwinnych zespołów, praca nad tym projektem nie pomoże ci wzmocnić tych umiejętności. Dlatego drugi prawdopodobnie też nie zostanie spełniony.

Więc osobiście, gdybym był na twojej pozycji i nie byłbym w stanie pomóc w wprowadzeniu TDD do firmy, szukałbym gdzie indziej.

Nigdy.

Życie jest zbyt krótkie (zwłaszcza gdy się starzejesz), aby robić rzeczy, których będziesz nienawidzić.

Oczywiście utrudnia to zmianę pracy i jest mniej miejsc do pracy.

Ale przynajmniej tylko starszy kod brzydko pachnie. (I mam autonomię, dzięki czemu możemy robić sensowne rzeczy, takie jak spędzić tydzień na eliminowaniu ostrzeżeń kompilatora ze starej bazy kodu ...)

Krótko mówiąc, metodologia rozwoju nie jest częścią ciebie. To nie jest relegion i nie jest to, kim jesteś. To jest narzędzie. Rób to, co ci się mówi, jak ci się mówi i zarabiaj dodatkowe pieniądze. Tysiące systemów zostało opracowanych i działa dzisiaj bez TDD, Code Smell itp. Za kilka lat nikt nie będzie wiedział, co oznaczają te terminy, ponieważ metodologie przychodzą i odchodzą częściej niż autobus miejski. Pracuj ciężko, jak ci każą, i bierz pieniądze, które są doceniane przez cały czas :)

Upewnij się, że praca z nowym zespołem to dobra inwestycja twojego czasu.

Być może działają one bardziej wydajnie niż do tej pory? Jeśli tak, praca z nimi będzie dla Ciebie wspaniałym doświadczeniem edukacyjnym (stąd dobra inwestycja).

Z drugiej strony metodologie nowego zespołu mogą być dla ciebie mało wartościowe (zbyt wiele „kodowania kowbojów” itp.). W takim przypadku dodatkowe pieniądze prawdopodobnie nie są tego warte (chyba że jest to start-up przed IPO lub coś niezwykłego). Prawdopodobnie nie nauczysz się wiele ... i ryzykujesz wypaleniem.

Nie pracowałbym gdzieś, co nie pozwalało mi pracować tak, jak chciałem. Rozumiem przez to, że nie chcę być mikrozarządzany.

Pracuję przy założeniu, że jestem dobry w tym, co robię, a jeśli dasz mi jakieś zadania, wykonam je sprawnie i skutecznie. To, jak je zaimplementuję, pod warunkiem, że nie złamię wytycznych i wzorców kodu, zależy ode mnie. To zabawna część mojej pracy.

Gdybym chciał przetestować jednostkę w każdej klasie, którą piszę, może to stanowić problem, ale pisanie testów jednostkowych jest ogólnie w porządku, pod warunkiem, że nadal dotrzymuję terminów. Oczekuję, że zwolennik TDD będzie argumentował, że testy jednostkowe pisania faktycznie zwiększają produktywność (później itd.). Gdybym był w twoich butach, napisałbym kilka testów jednostkowych, które zaoszczędzą mi trochę czasu na torze (przypuszczalnie mniej błędów, łatwiejsze poprawki). Jeśli ponownie zainwestujesz ten czas zaoszczędzony w więcej testów, to przyczyni się do jeszcze większej oszczędności czasu i ostatecznie będziesz mógł usiąść z dużym uśmiechem, gdy masz niesamowity zestaw testów, i możesz łatwo sprawdzić zmiany kodu, gdy jakieś nowe 11 godziny pojawia się wymóg.

Jeśli nie mógłbym tego zrobić, to nie wiem, czy chciałbym tam pracować.

Mówię o tym, że uważam, że w tych sprawach należy dać i przyjąć - trochę negocjacji. Im więcej mi płacą, tym mniej spodziewam się niepieniężnych subtelności. Ale zawsze potrzebuję pewnej autonomii i szacunku dla siebie, szczególnie gdy nie trzeba odmawiać. Odrzucę każdą inną zasadę, o ile będę miał trochę autonomii. W końcu coś, co może wydawać się zwariowaną metodologią, może być najlepszą rzeczą, jaką kiedykolwiek zrobiłeś!