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

16

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 ...

Martin Blore
źródło
19
Koleś, czy zostałeś prany mózgu? Nie bądź głupi i zabierz ich pieniądze. Wyprzedaż? Co ty wariujesz? Jeśli czujesz się winny, możesz podzielić się ze mną połową swoich dodatkowych zarobków. Za dodatkowe dolary możesz wcześniej kupić dom, a tym samym upewnić się, że masz pasywne źródło dochodu (czynsz) - to właśnie bym zrobił. W ten sposób możesz pozwolić sobie na kapryśność i częściej ustalać własne warunki.
Job
1
Sprowadzało się to do tego, że jest to nowe miejsce, więc zawsze jest element nauki, ale może nie na długo. Kupno domu było dla mnie największą wygraną, nawet jeśli robię to przez rok i przechodzę do czegoś na dłuższą metę, gdzie procesy są prawidłowe itp. Masz rację Job, byłbym szalony, żeby to odrzucić . Ale cała sytuacja skłoniła mnie do zastanowienia się, co inni mogli już zrobić w swojej karierze.
Martin Blore,
5
Ludzie, prawie wszyscy z was każą mu wziąć pieniądze. Czy przyszło ci do głowy, że dla kogoś taki kompromis może być równy fizycznemu poproszonemu o zbudowanie broni nuklearnej lub chemikowi do produkcji narkotyków. OK, zły kod prawdopodobnie nie spowoduje śmierci. Ale zasady są tym, co określa nas i naszą postać, zastanów się dwa razy, zanim je poświęcisz.
Dave O.
1
@Dave: to zależy od skali krytyczności projektu: en.wikipedia.org/wiki/Cockburn_Scale
rwong
1
Wziąłbym pracę. Zawsze możesz spróbować przekonwertować współpracowników z dala od Ciemnej Strony.
Nikt

Odpowiedzi:

25

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 ...

Péter Török
źródło
Dziękuję Peter. Miło wiedzieć, że doświadczyłeś tego już wcześniej i na pewno skorzystam z twojej rady.
Martin Blore,
17

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ć.

Roloc
źródło
s / zasoby / jakość / g = czas i pieniądze kwalifikują zasoby. Rzeczywista równowaga to czas, koszt i jakość. Innymi słowy: mogę to zrobić szybko, mogę to zrobić dobrze, mogę to zrobić szybko, wybrać dowolne dwa.
asoundmove
10

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ć ...

Joris Meys
źródło
4
+1 „Dowiedziałem się, że frustracji nigdy nie należy lekceważyć ...” - zbyt prawdziwe. Długotrwałe frustracje zdecydowanie zabijają pracę.
Martin Blore,
7

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.

Marcie
źródło
3

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.).

użytkownik 281377
źródło
2

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.

Pete
źródło
Lubię też rozważać lokalizację. Jednak nawet w przypadku tylko tych trzech często nie znajdziesz wszystkich trzech w jednym projekcie. Zwykle zadowalam się dwoma. I za każdym razem są to zwykle dwa różne.
Mawg mówi o przywróceniu Moniki
2

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 ...)

Tim Williscroft
źródło
2

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 :)

Bez szans
źródło
1

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.

MrDatabase
źródło
1

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ś!

Kirk Broadhurst
źródło