Jak balansujesz między „zrób to dobrze” a „zrób to jak najszybciej” w codziennej pracy? [Zamknięte]

180

Od czasu do czasu zastanawiam się nad tym pytaniem. Chcę robić rzeczy we właściwy sposób: pisać czysty, zrozumiały i poprawny kod, który jest łatwy w utrzymaniu. W końcu jednak piszę łatkę na łatce; tylko dlatego, że nie ma czasu, klienci czekają, błąd należy naprawić z dnia na dzień, firma traci pieniądze na ten problem, kierownik mocno naciska itp. itp.

Wiem doskonale, że na dłuższą metę tracę więcej czasu na te plastry, ale ponieważ ten czas obejmuje miesiące pracy, nikogo to nie obchodzi. Ponadto, jak mawiał jeden z moich menedżerów: „nie wiemy, czy będzie to długoterminowe, jeśli nie naprawimy go teraz”.

Jestem pewien, że nie jestem jedynym uwięzionym w tych nieskończonych cyklach wyboru rzeczywistego / idealnego. Jak więc sobie radzicie, moi koledzy, programiści?

AKTUALIZACJA: Dziękuję wszystkim za tę interesującą dyskusję. To smutne, że tak wiele osób musi codziennie wybierać między ilością a jakością swojego kodu. Mimo to, zaskakująco wiele osób uważa, że ​​można wygrać tę bitwę, więc dziękuję wszystkim za tę zachętę.

Flot2011
źródło
12
Proste: zrób to dobrze i zrób to szybko
ren
158
@ren: Cóż, przypuszczam, że nie jesteś programistą, jesteś menedżerem :-)
Flot2011
44
Obowiązkowy. xkcd.com/844
MikeTheLiar
5
Zrób to jak najszybciej. Jeśli nadal masz czas, zrób to dobrze.
Laurent Couvidou,
8
Jak mówi wujek Bob: Wolna droga jest szybka. Poświęć trochę czasu na napisanie testów jednostkowych i dobrze napisz swój kod. Może to spowodować, że wdrożenie tej funkcji zajmie więcej czasu, ale na dłuższą metę pozwoli zaoszczędzić czas, ponieważ inni będą mogli łatwiej modyfikować i naprawiać błędy.
martiert

Odpowiedzi:

106

W rzeczywistości jest to bardzo trudne pytanie, ponieważ nie ma absolutnie właściwej odpowiedzi. W naszej organizacji wprowadziliśmy lepsze procesy w celu uzyskania lepszego kodu. Zaktualizowaliśmy nasze standardy kodowania, aby odzwierciedlić, w jaki sposób, jako grupa, piszemy kod, i ustanowiliśmy bardzo silną pętlę testowania / refaktoryzacji / projektowania / kodu. Dostarczamy w sposób ciągły lub przynajmniej staramy się. Przynajmniej mamy coś do pokazania interesariuszom co dwa tygodnie. Uważamy, że jesteśmy rzemieślnikami oprogramowania, a morale jest wysokie. Ale pomimo tych wszystkich kontroli i równowagi mamy ten sam problem, co ty.

Pod koniec dnia dostarczamy produkt płatnemu klientowi. Ten klient ma potrzeby i oczekiwania, realistyczne lub nie. Często zespół sprzedaży wpędza nas w kłopoty tylko po to, aby otrzymać prowizję. Czasami klient ma rzeczywiste oczekiwania, które są nierealne lub wymagają zmiany, nawet jeśli mamy podpisaną umowę. Czasy się zdarzają. Może się zdarzyć WOM i stracone dni podczas sprintu. Kulminacją wszelkiego rodzaju drobiazgów jest sytuacja, w której musimy wpaść w zagadkę „zrób to dobrze” lub „zrób to jak najszybciej”. Prawie zawsze jesteśmy zmuszeni „zrobić to jak najszybciej”.

Jako rzemieślnicy oprogramowania, programiści, programiści, ludzie kodujący pracę - naszą naturalną skłonnością jest „robić to dobrze”. „Zrób to jak najszybciej” to, co dzieje się, gdy pracujemy, aby przetrwać, jak większość z nas. Bilans jest trudny.

Zawsze zaczynam od podejścia do zarządzania (jestem dyrektorem ds. Rozwoju oprogramowania i aktywnym programistą w tej grupie), aby bronić harmonogramu, zespołu i wykonywanej pracy. Zwykle w tym momencie mówi mi się, że klient musi to mieć teraz i musi działać. Kiedy wiem, że nie ma miejsca na negocjacje ani dawanie, wracam i współpracuję z zespołem, aby zobaczyć, jakie rogi można skrócić. Nie poświęcę jakości w funkcji, która napędza potrzebę klienta, aby jak najszybciej, ale coś pójdzie i zostanie zepchnięty do kolejnego sprintu. To prawie zawsze jest OK.

Jeśli nie możesz dostarczyć, ponieważ jest tak wiele błędów, jakość kodu jest zła i pogarsza się, a terminy są coraz krótsze, wtedy znajdujesz się w innej sytuacji niż to, co opisuję. W takim przypadku obecne lub wcześniejsze niewłaściwe zarządzanie, złe praktyki programistyczne, które doprowadziły do ​​złej jakości kodu lub inne czynniki mogą zabrać cię na marsz śmierci.

Uważam, że staram się bronić dobrego kodu i najlepszych praktyk, aby zacząć wyciągać firmę z rowów. Jeśli nie ma ani jednego kolegi chętnego do wysłuchania grupy lub pójścia na nią wbrew kierownictwu, być może nadszedł czas, aby zacząć szukać nowej pracy.

W końcu prawdziwe życie przebija wszystko. Jeśli pracujesz dla firmy, która musi sprzedawać to, co rozwijasz, codziennie spotkasz się z tym kompromisem. Tylko starając się wcześnie osiągnąć dobre zasady programowania, udało mi się wyprzedzić krzywą jakości kodu.

Push i pull między deweloperami a sprzedawcami przypomina mi żart. „Jaka jest różnica między sprzedawcą używanych samochodów a sprzedawcą oprogramowania? Przynajmniej sprzedawca używanych samochodów wie, że kłamie”. Utrzymuj podbródek i staraj się „postępować właściwie”.

Akira71
źródło
14
„Często zespół sprzedaży wpędza nas w kłopoty tylko po to, aby uzyskać prowizję” - w którym momencie uważa Pan, że sprzedaż powinna być odpowiedzialna za sprzedaż czegoś, czego firma nie może dostarczyć - zakładając, że istnieje? Czy masz przykłady, w których przekroczyli granicę między agresywnym marketingiem a nadmierną sprzedażą?
Tom W
8
@TomW Mam kilka wewnętrznych przykładów, których nie mogłem opublikować tutaj, ale kiedy to się dzieje, prawie zawsze zdarza się, gdy potrzebujemy konta referencyjnego lub pod koniec kwartału. Mamy kilku bardzo dobrych sprzedawców i innych niezbyt dobrych. Ostatnio nastąpiła duża zmiana w sprzątaniu domu, gdy ustalono, że nie chodzi o rozwój, a cała struktura sprzedaży zmieniła się na lepsze. Od tego czasu sprawy potoczyły się cudownie. Chciałbym być bardziej konkretny, ale nie mogę.
Akira71,
9
+1 - „Nie poświęcę jakości w funkcji, która powoduje, że klienci muszą uzyskać ją jak najszybciej, ale coś pójdzie” … to było fantastyczne.
Joel B,
59
@TomW - Zawsze lubię zwracać uwagę, że główny architekt morski Titanica, który ostrzegał przed obniżką kosztów (Thomas Andrews), poszedł ze statkiem, podczas gdy najlepszy sprzedawca / marketing, który nalegał na obniżenie kosztów i załatwienie sprawy JAK NAJSZYBCIEJ (Bruce Ismay) uciekł w łodzi ratunkowej.
jfrankcarr
4
Chciałbym, aby czas wpisał taką odpowiedź, ale mam klienta dzwoniącego do mojego szefa przez telefon. „Często zespół sprzedaży wpędza nas w kłopoty tylko po to, aby uzyskać prowizję”. To samo tutaj ... ale jakoś wciąż dostają te bonusy!
Kenzo,
62

W mojej karierze zdałem sobie sprawę, że zawsze jest czas, aby zrobić to dobrze. Tak, twój menedżer może naciskać. Klient może być wkurzony. Ale nie wiedzą, jak długo to trwa. Jeśli ty (twój zespół deweloperów) tego nie zrobisz, nie da się tego zrobić; utrzymujesz całą dźwignię.

Ponieważ wiesz, co tak naprawdę spowoduje, że Twój menedżer zmusi Ciebie lub Twojego klienta do wkurzenia? Niska jakość .

Telastyn
źródło
43
Chociaż zwykle jest czas na dobrą robotę, zwykle nie ma czasu na robienie tego idealnie. Jest między nimi świat różnic.
Donal Fellows,
2
@DonalFellows oczywiście. „Właściwe” zawsze „postępuje zgodnie z najlepszymi praktykami, wykorzystując nasze najlepsze zrozumienie problemu w tym momencie, najlepiej jak potrafimy”. Ludzie popełniają błędy. Wymagania się zmieniają. Zmieniają się najlepsze praktyki. Nie tnij zakrętów i nie zmieniaj faktów, gdy coś się dzieje.
Telastyn,
3
@DonalFellows - „Wróg doskonałości to perfekcja”. Program napisany w sposób umożliwiający utrzymanie, który spełnia wymagania klientów i robi to z zadowalającą wydajnością, jest programem „wykonanym”. Nie ma w tym nic z kości słoniowej.
KeithS,
1
@DonalFellows Nikt nie użył słowa „idealne”, idealne rozwiązanie jest złym rozwiązaniem, Telastyn mówi o właściwym rozwiązaniu. Właściwym rozwiązaniem jest to, które spełnia wymagania i jest mało prawdopodobne, aby powodowało problemy w przyszłości, a jednocześnie jest łatwe w obsłudze w takim przypadku. Absoluty są zawsze złe.
Jimmy Hoffa,
7
+1 - dla Telastyn, podczas gdy wszyscy klienci chcą, aby ich rzeczy były zrobione teraz. DALEKO WIĘCEJ klienci chcą, aby ich produkty działały bardziej niż robienie tego teraz. Wygląda na to, że każdy, kto nie zgadza się z Telastyn, twierdzi, że straci klienta, jeśli nie zostanie to zrobione szybko. To zdecydowanie wyjątek, a nie reguła. Zasadą jest, że większość ludzi, którzy się nie zgadzają, ignoruje fakt, że straci znacznie więcej klientów, dostarczając tandetne produkty. Twierdzenie, że klient tego chce, jest obecnie zwykłą wymówką dla ludzi, którzy nie dbają o jakość. Jestem więc sceptycznie nastawiony do deklarowanego ryzyka.
Dunk
21

Sprowadza się to do tego, co zacząłem myśleć o „Wiecznym konflikcie” (między biznesem a inżynierią). Nie mam rozwiązania, ponieważ jest to problem, który nigdy nie ustępuje, ale możesz robić rzeczy, które pomogą złagodzić.

  • Przekaż wartość

Ludzie często nie zdają sobie sprawy, że jako inżynierowie zakładamy, że problem „udanego biznesu” jest zawsze podany. Chcemy, aby nasz kod był ładny, schludny i łatwy w utrzymaniu, abyśmy mogli szybko dodawać nowe funkcje i poprawiać istniejące, przy minimalnej liczbie klientów wykonujących dla nas kontrolę jakości, odkrywając dziwaczne przypadki, które zostałyby udaremnione przez lepszy kod. Utrzymywanie klientów i utrzymywanie przewagi konkurencyjnej dzięki funkcjom i finezji, których nikt inny nie jest w stanie wyprodukować wystarczająco szybko, to zarówno wygrane biznesowe, do których dobry kod bezpośrednio przyczynia się i informuje wiele z powodów, dla których chcemy przede wszystkim lepszego kodu.

Więc przeliteruj to. „Chcemy wykonać X w naszej bazie kodu, ponieważ jeśli tego nie zrobimy, wpłynie to negatywnie na biznes z powodu Y” lub „… ponieważ zwiększy naszą zdolność do pozostania konkurencyjnym poprzez poprawę naszej zdolności do szybszego wprowadzania nowych ulepszeń i funkcji . ”

I staraj się uzyskać namacalne dowody na to, że udoskonalenia działają. Jeśli ulepszenie jakiegoś podzbioru aplikacji spowodowało szybsze działanie / ulepszenie, sprawdź, jakie narzędzie zaległości, którego możesz użyć, jest tego dowodem i wskaż je na odpowiednich spotkaniach.

  • Umieść zespół na tej samej przeklętej stronie

Ego są często problemem. Jedną rzeczą, której zespoły inżynierskie bardzo potrzebują, jest ustalenie wartości uzgodnionego spójnego podejścia do rozwiązywania określonych rodzajów problemów w stosunku do każdego, kto robi swój własny puchar Kool Aid d'jour, ponieważ wiedzą lepiej. Można wierzyć, że preferencje drugiego faceta są gorsze niż twoje, ale cenisz sobie konsekwencję w stosunku do bycia bardziej właściwym, jeśli jego podejście jest wykonalne i jest to argument, którego nie możesz wygrać. Kompromis ze względu na spójność jest kluczem. Kiedy rzeczy są spójne, trudniej jest je zrobić źle, ponieważ konsekwentnie ustalony sposób będzie zwykle najszybszy.

  • Wybierz odpowiednie narzędzia

Istnieją dwie szkoły frameworków / zestawów narzędzi / bibliotek / cokolwiek innego. „Ustaw dla mnie 99%, więc muszę wiedzieć / robić bardzo mało” vs. stosować raczej na zasadzie marchewki niż na patyczku. ” Sprzyjaj drugiemu. Elastyczności i szczegółowej kontroli nigdy nie należy poświęcać przy ołtarzu szybkiego zwrotu, ponieważ dziwne: „nie możemy tego zrobić, ponieważ nasze własne narzędzia nam na to nie pozwolą”, nigdy nie jest akceptowalną odpowiedzią, a pytanie zawsze będzie wymyślić trywialna / jednorazowa inżynieria produktu. Z mojego doświadczenia wynika, że ​​nieelastyczne narzędzia prawie zawsze są rozwalane na oścież lub pracują nieelegancko i robią wielkiego giganta, którego nie da się utrzymać. Częściej niż nie elastyczne / łatwiejsze do modyfikacji rozwiązania są tak samo lub bardzo szybkie w krótkim okresie, niezależnie od tego. Szybkie, elastyczne i łatwe w utrzymaniu są możliwe dzięki odpowiednim narzędziom.

  • FFS, jeśli inżynierowie nie podejmują decyzji, przynajmniej uzyskaj wkład inżyniera w wybór narzędzi

Wydaje mi się, że jest to pytanie z perspektywy programisty, ale byłem w zbyt wielu sytuacjach, w których decyzje technologiczne były podejmowane przy zerowym wkładzie inżyniera. Co to do diabła jest? Tak, ktoś ostatecznie musi zadzwonić, ale uzyskać kwalifikowane opinie, jeśli jesteś nietechnicznym menedżerem, a nie to, co mówi sprzedawca lub strona demonstracyjna na temat własnych produktów. Wszystko, co obiecuje zaoszczędzić ci pieniądze, ponieważ ludzie nie muszą być tak mądrzy lub dlatego, że chroni programistów przed sobą, jest brudnym, brudnym kłamstwem. Zatrudnij talent, któremu możesz zaufać. Powiedz im, co chcesz ze stosu lub innego rozwiązania technologicznego, i poważnie podejmij ich uwagi, zanim zdecydujesz, na który modowy pas technologiczny wskoczyć.

  • Skoncentruj się na projektowaniu a wdrażaniu

Narzędzia są do wdrożenia i jako takie mogą ci pomóc, ale priorytetem musi być architektura bez względu na zestaw zabawek, które masz do budowania tej architektury. Pod koniec dnia KISS i DRY oraz wszystkie doskonałe filozofie, które wywodzą się z tych kwestii, są ważniejsze niż to, czy jest to .NET czy Java, a może coś, co jest zarówno wolne, jak i nie jest do bani.

  • Zaloguj swoje obawy

Kiedy strona dziwna nalega, abyś zrobił to źle, zapisz ten e-mail, szczególnie w tej części, w której powiedziałeś, dlaczego to cię kosztuje. Kiedy wszystkie twoje prognozy się sprawdzą i pojawią się poważne, szkodliwe dla biznesu problemy, wtedy masz mnóstwo argumentów za poważniejszym traktowaniem problemów inżynierów. Ale czas ostrożnie. W środku płonącego piekła jest zły czas na „tak ci powiedziałem” na temat przestrzegania kodu ogniowego. Wygaś ogień i przenieś swoją listę wcześniej ignorowanych obaw na retrospektywne spotkanie / rozmowę i staraj się skupiać na problemach technicznych wyrażonych i zignorowanych oraz rozumowaniu, które rozumiesz, dlaczego były ignorowane, a nie imiona i nazwiska rzeczywistych ludzi podejmowanie decyzji o zignorowaniu. Jesteś inżynierem Trzymaj się problemów, nie ludzi. „ Wyraziliśmy zaniepokojenie z powodu X, ponieważ baliśmy się, że doprowadzi to do problemów z Y. Powiedziano nam Z i żebyśmy się tym nie zajmowali. ”

Erik Reppen
źródło
Bardzo miła i dogłębna odpowiedź. Dodam, że miałem już problem ze znalezieniem odpowiednich narzędzi , co spowodowało znaczną stratę czasu. Możemy wysłać produkt miesiąc później, po podjęciu decyzji, że porzucamy ten produkt i używamy czegoś, co nas nie blokuje.
mj
1
Czuję się dobrze z tą odpowiedzią, ale właśnie znalazłem swoją pierwszą pracę, w której biz i deweloperzy nie są ciągle w gardłach, a efekt jest zachwycający. Po prostu załatwiamy sprawy. Nie zawsze tak szybko, jak tylko chcemy, ale bierzemy pod uwagę przyszłość, która pokazuje zarówno produkt, jak i naszą zdolność do modyfikowania go w miarę zmieniających się potrzeb. Nieunikniona Big Ball of Mud to kłamstwo, IMO.
Erik Reppen
19

Jest tylko jedno rozwiązanie. Zarezerwuj około 10-20% czasu projektu / pracy na refaktoryzację. Jeśli trudno jest przekonać kierownictwo, że jest to uzasadnione zadanie, daj im jedyny prawdziwy argument: bez refaktoryzacji koszty utrzymania kodu będą rosły wykładniczo z czasem. Dobrze jest mieć kilka wskaźników / artykułów / wyników badań na poparcie tej tezy podczas spotkania z kierownikiem :)

Edycja: istnieje kilka dobrych zasobów na temat „refaktoryzacji kontra rosnące koszty utrzymania” wspomnianych w niniejszym oficjalnym dokumencie: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf

Andrzej Bobak
źródło
12
Jest lepsza opcja: spraw, aby refaktoryzacja stała się częścią twojego zwyczajnego kodowania. Dzienne Cogodzinny. Ilekroć dodajesz lub zmieniasz funkcję. Nie musisz więc rezerwować na to dodatkowego czasu ani „przekonywać kierownictwa”.
Doc Brown
Jest ważny tylko wtedy, gdy nie masz do czynienia z kodem, który jest już napisany. Powszechnym zadaniem jest dodawanie nowej wartości do starego / odziedziczonego / odziedziczonego kodu źródłowego. Ale kiedy patrzysz na ten kod, nie wiesz od czego zacząć i czujesz, że łatwiej jest napisać ten kod od nowa, niż dowiedzieć się, jak on działa. Spróbuj uzasadnić te szacunki: dwa dni, aby dodać nową wartość, sześć dni, aby przebudować stary kod, aby był możliwy do utrzymania. Często słyszy się „nie zmieniaj faktury, po prostu dodaj nową wartość, później ustalimy, co zrobić ze starym kodem”.
Andrzej Bobak,
1
@ Flot2011 Masz tylko jedno rozwiązanie. Niech rutynowym zadaniem będzie refaktoryzacja z dnia na dzień. Na przykład w każdy wtorek skupiamy się wyłącznie na poprawie jakości kodu. Upewnij się, że kierownictwo przestrzega tego i upewnij się, że refaktoryzacja nie jest stratą czasu. Bez spełnienia tych dwóch warunków wcześniej czy później porzucą pomysł ulepszenia „czegoś, co już jest i działa”.
Andrzej Bobak,
1
@DocBrown Działa, gdy rozmawiasz z zarządem. Jeśli porozmawiasz ze starszym programistą i powiesz mu, że dodasz dwa pola do formularza, a zajmie Ci to 3 dni ... Powodzenia :).
Andrzej Bobak,
2
Konieczność zawyżenia szacunków w celu uzyskania czasu konserwacji jest problematyczna z wielu powodów. Czasami warto zaciągnąć dług techniczny. Co się dzieje, gdy biz nagle zauważa, że ​​w sytuacji awaryjnej zajęło 15 minut uderzenie w dwa nowe pola, gdy ostatni raz zajęło to 8 dni. IMO, biz musi być świadomy długu technologicznego i jego długoterminowego wpływu. Problem należy rozumieć jako albo płacisz teraz, albo płacisz 5 razy więcej później, kiedy wszystko jest gotowe.
Erik Reppen
14

Ilekroć masz czas na zrobienie czegoś dobrze, użyj go - napisz najlepszy kod, jaki możesz, i stale go ulepszaj. Nie rób trudniejszej pracy, pozostając niechlujnym i wprowadzając dług techniczny, gdy nie ma takiej potrzeby.

Telefony alarmowe w celu naprawienia poważnego błędu nie są rzeczami, którymi sam możesz kontrolować, kiedy wystąpią, musisz zareagować jak najszybciej, to jest życie. Oczywiście, jeśli masz wrażenie, że cała twoja praca składa się z połączeń alarmowych i nigdy nie masz wystarczająco dużo czasu, aby zrobić dobrze, to jesteś na drodze do wypalenia i powinieneś porozmawiać z szefem.

Jeśli to nie pomoże, nadal istnieje „strategia Scotty'ego”, aby uzyskać wystarczająco dużo czasu na właściwe działania: pomnóż wszystkie swoje szacunki przez współczynnik 4:

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/

Doktor Brown
źródło
Strategia Scotty'ego działa. Tylko nie mów szefowi, że to robisz. Często czas, jaki zajmuje w rzeczywistości, jest podwójny. Zawsze lepiej jest zakończyć wcześniej niż późno.
Łukasz
11

Widzę moją pracę jako dostarczanie oprogramowania najlepszej jakości, które jest możliwe w ramach ograniczeń czasowych dozwolonych dla projektu. Jeśli obawiam się, że poziom jakości będzie niski, zaangażuję właściciela projektu. Opisuję swoje obawy i omawiam potencjalne ryzyko związane z wdrażaniem oprogramowania w tym stanie. W tym momencie wydarzy się jedna z 3 rzeczy:

  1. Właściciel projektu nie będzie chciał zaakceptować ryzyka i cofnie harmonogram, abyśmy mogli poświęcić więcej czasu na jakość oprogramowania.

  2. Właściciel projektu nie będzie chciał zaakceptować ryzyka, ale nie może cofnąć harmonogramu. Jeśli tak się stanie, musimy negocjować, które funkcje / funkcje należy usunąć z zakresu projektu, aby spędzić więcej czasu na jakości oprogramowania dla głównych części aplikacji.

  3. Właściciel projektu zaakceptuje ryzyko, a oprogramowanie niskiej jakości wyjdzie na czas. Czasami ryzyko biznesowe braku wdrożenia (lub wdrożenia późnego) jest znacznie większe niż ryzyko biznesowe związane z wdrożeniem oprogramowania niskiej jakości i tylko właściciel projektu może podjąć taką decyzję.

Oprogramowanie do pisania przypomina malowanie portretu. Nie można powiedzieć, że portret wykonano „dobrze” lub „perfekcyjnie”. Idealny jest wrogiem zrobionych. Możesz dosłownie spędzić 1 miesiąc pracując nad jedną metodą, a niektórzy nadal nie uważają jej za „idealną”. Moim zadaniem jest namalowanie portretu, z którego klient jest zadowolony.

Shane
źródło
7

To nie zadziała w każdym przypadku, ale miałem trochę szczęścia w stosowaniu tej strategii, jeśli problemem jest zepsuty problem z produkcją, który należy pilnie rozwiązać. Oszacuj czas na szybką poprawkę, aby uruchomić produkcję i czas na poprawkę jakości na przyszłość. Przedstaw swoje prognozy swojemu szefowi / klientowi i uzyskaj czas zatwierdzony dla obu. Następnie wykonujesz szybką poprawkę, aby uruchomić produkcję, a długoterminową naprawę natychmiast po zakończeniu pilnej presji czasu. Uważam, że jeśli przedstawię to, ponieważ potrzebuję tego czasu, aby dobrze wykonać pracę, ale mogę wprowadzić tymczasową poprawkę, dopóki nie będę mógł tego zrobić, że moim klientom podobają się takie podejścia. Ponownie uruchamia prod i zaspokaja długoterminową potrzebę.

HLGEM
źródło
7

Optymalną równowagą może być poświęcenie tyle dodatkowego czasu, aby zrobić to dobrze, ile zmarnowałbyś naprawianie błędów, które eliminujesz, robiąc to dobrze. Unikaj pozłacania roztworu. W większości przypadków dobrze wykonane rozwiązanie Volkswagena jest tak dobre, jak rozwiązanie Cadillac. Zwykle możesz dokonać aktualizacji później, gdy okaże się, że potrzebujesz Cadillaca.

Naprawianie kodu, który nie przestrzegał najlepszych praktyk, często trwa znacznie dłużej. Próba znalezienia skąd pochodzi wartość null, gdy wywołanie wygląda jak abcde (), może zająć dużo czasu.

Zastosowanie DRY i ponowne użycie istniejącego kodu jest zwykle znacznie szybsze niż kodowanie i testowanie jeszcze innego rozwiązania. Ułatwia także wprowadzanie zmian, gdy się pojawią. Musisz tylko zmienić i przetestować jeden zestaw kodu, a nie dwa, trzy lub dwadzieścia.

Cel dla solidnego kodu podstawowego. Wiele czasu można zmarnować, próbując uczynić go idealnym. Istnieją najlepsze praktyki, które prowadzą do szybkiego kodu, ale niekoniecznie najszybszego. Poza tym, próba przewidywania wąskich gardeł i optymalizacji kodu podczas jego tworzenia może być zmarnowanym czasem. Co gorsza, optymalizacja może spowolnić kod.

Jeśli to możliwe, zapewnij minimalne działające rozwiązanie. Widziałem tygodnie zmarnowanych rozwiązań w zakresie złocenia. Zachowaj szczególną ostrożność co do zakresu.

Spędziłem trochę czasu pracując nad projektem, który powinien zająć sześć miesięcy. Kiedy dołączyłem, trwało to półtora roku. Kierownik projektu zadał kierownikowi projektu jedno pytanie na początku: „Chcesz, żebym zrobił to dobrze, czy reagował?” W ciągu tygodnia funkcja została zaimplementowana w poniedziałek, środę i piątek; We wtorek i czwartek funkcja została usunięta.

EDYCJA: Gdy kod zostanie wykonany na zadowalającym poziomie, pozostaw go. Nie wracaj, aby to naprawić, jeśli znajdziesz lepszy sposób. Jeśli musisz zrobić notatkę. Jeśli wymagane są zmiany, przejrzyj swój pomysł i zastosuj go, jeśli nadal ma sens.

Jeśli są miejsca, w których chcesz zaimplementować rozszerzenia dla nadchodzących funkcji, nie implementuj ich. Możesz zostawić komentarz znacznika, aby przypomnieć, gdzie wprowadzić zmiany.

BillThor
źródło
Chyba że DRY oznacza mylące, nieczytelne wdrożenie masowych kaskadowych schematów dziedziczenia. Nie rób tego Przepraszam, często to mówię, ale naprawdę tego nie znoszę. Ponadto +1 za minimalne działające rozwiązanie w większości przypadków. Czasami niektóre przyszłościowe elementy architektoniczne mogą być pomocne, o ile nie przesadzisz.
Erik Reppen
1
@ErikReppen Kod, który jest mylący, nieczytelny i implementacja masowych kaskadowych schematów dziedziczenia, zawiódłaby moją definicję DRY. Jeśli musisz wymyślić kod za każdym razem, gdy go używasz, projekt wyraźnie nie wysycha, nawet jeśli implementacja się powiedzie.
BillThor,
Może to jednak wymagać ponownego wykorzystania kodu. Irytujące jest wspinanie się na drzewo 18 klas lub prototypów, aby znaleźć rzeczywistą definicję metody, która robi coś naprawdę irytującego, szczególnie jeśli istnieją przesłonięcia.
Erik Reppen
6

Spraw, by działało, a następnie dopracuj

Mogę narysować trochę luzu - ale jeśli liczy się czas, Twoim głównym priorytetem powinno być sprawienie, by było to proste. Komentuj obszernie o niedociągnięciach w kodzie i zanotuj to, co zrobiłeś w dowolnym oprogramowaniu do zarządzania projektami / czasem, którego używasz.

Mamy nadzieję, że da ci to więcej czasu na powrót do tych problemów i uczynienie ich idealnymi.

Oczywiście nie ma absolutnie poprawnej odpowiedzi na to pytanie, ale jest to odpowiedź, której staram się trzymać. Jednak może nie być odpowiedni dla twojego obecnego stylu pracy. Co prowadzi mnie do alternatywy ...

Po prostu znajdź metodę, która Ci odpowiada ; i trzymaj się tego. Każdy ma swój własny sposób radzenia sobie z projektami i nie ma podejścia „jeden rozmiar dla wszystkich”. Znajdź podejście i wybierz je dla siebie.

Fergus In London
źródło
3
Gdy kierownictwo wie, że to działa. Biorą to za gotowe i nie chcą, abyś poświęcał inne wysiłki na refaktoryzację itp.
Adronius
5

„Właściwe postępowanie” oznacza dokonanie właściwych kompromisów w konkretnej sytuacji. Niektórzy z nich są:

  1. Czas i koszt opracowania
  2. Łatwość czytania, debugowania i późniejszego aktualizowania kodu (wszystko od nazw zmiennych po architekturę)
  3. Dokładność rozwiązania (przypadki brzegowe)
  4. Szybkość wykonania

Oczywiście, jeśli fragment kodu zostanie użyty raz i wyrzucony, # 2 można poświęcić dla dowolnego z pozostałych. (Ale uwaga: możesz myśleć, że zamierzasz go wyrzucić, a potem odkryć, że musisz nadal go używać i utrzymywać, w którym to momencie trudniej będzie przekonać ludzi, aby dać ci czas na ulepszenie czegoś, co „działa”).

Jeśli ty i / lub twój zespół będziecie nadal używać i aktualizować jakiś kod, stosowanie skrótów oznacza teraz spowolnienie później.

Jeśli obecnie dostarczasz błędny kod (słaby na 4) i zajmuje ci to dużo czasu (słaby na 1), a to dlatego, że próbujesz zaktualizować kod, który był słaby na 2, cóż, masz otrzymali solidny, pragmatyczny argument za zmianą praktyk.

Nathan Long
źródło
1
Sugerowałbym: „Jeśli NIKT nie zamierza zachować fragmentu kodu ...”: Pisanie śmieci, zrzutowanie i uruchamianie nie powinno być opcją (dla każdego z sumieniem), ale zdarza się to zbyt często; kontrahenci / konsultanci / menedżerowie upewniają się, że są bezpiecznie tuż za drzwiami, zanim „to” uderzy w wentylator.
Phill W.
@PhillW. - absolutnie się zgadzam. Odpowiednio zredagowane.
Nathan Long
4

Jeśli to błąd, zrób to jak najszybciej, jeśli to nowa funkcja, nie spiesz się.

A jeśli pracujesz dla firmy, która nie szanuje pracy programistów, możesz nie mieć wyboru, musisz zrobić to szybko i poświęcić się jakości.

Pracowałem dla wielu firm, które przechodziły od projektu do projektu i robiły wszystko szybko. Ostatecznie odniosły niewielki sukces w każdym projekcie, ponieważ wdrożenie (nie tylko programowanie) zostało przyspieszone.

Najlepsze firmy wiedzą, że dobre oprogramowanie wymaga czasu i kunsztu.

Dimitry
źródło
3

W sytuacji awaryjnej stwórz rozwiązanie do łatania. Stwórz nowy błąd w śledzeniu błędów, wspominając o tym. Zrób to dobrze, ilekroć masz odpowiedni czas.

Manoj R.
źródło
5
Problem polega na tym, że prawie nigdy nie ma odpowiedniego czasu, to jest właśnie problem, a tego rodzaju błędy zawsze będą miały najniższy priorytet.
Flot2011,
Powiedziałbym, że jest to prawdą tylko wtedy, gdy przez „nagły wypadek” rozumiesz „coś, co dzieje się nie częściej niż raz na sześć miesięcy”, a przez „kiedy masz czas” masz na myśli „w ciągu tygodnia”. W przeciwnym razie twoje pytanie będzie brzmiało „pomoc, klient potrzebuje CZYTA jak najszybciej, ale kod, który muszę zmienić, jest mylącym bałaganem i zajmie mi to tygodnie!”
Nathan Long,
3

Myślę, że robię to, co robią wszyscy, którzy utknęli w pracy w tej branży. Robię to tak szybko, jak to możliwe, a jeśli muszę pominąć niektóre miłe rzeczy, które mogłyby pomóc w zapobieganiu problemom w przyszłości lub ułatwić rozwiązywanie problemów w przyszłości, robię to. Nie jest to sytuacja optymalna, ale kiedy utkniesz w terminach opartych na szacunkach opartych na szacunkach, opartych na wielu nieznanych zmiennych, jest to najlepsze, co możesz zrobić.

Matt
źródło
3

Oto dobry plan:

  1. Spraw, aby Twój plan „zrób to dobrze” zajął dokładnie tyle samo czasu, co zrób to jak najszybciej.
  2. Zoptymalizuj swój czas, aby to zrobić, dopóki twoje środowisko nie będzie szczęśliwe; zachowaj jakość
  3. ???
  4. Powodzenie
tp1
źródło
1

Robię większość rzeczy rutynowo, pierwszy sposób, jaki przychodzi mi na myśl. To szybkie i lubię myśleć, że jestem przyzwoitym programistą i robię większość rzeczy w miarę dobrze za pierwszym razem.

Od czasu do czasu (chciałbym powiedzieć dwa razy dziennie, ale dwa razy w tygodniu jest bardziej realistyczny), szczególnie gdy znajduję coś wyjątkowo nudnego w rutynowy sposób, myślę „jaki byłby NIESAMOWITY sposób na zrobienie tego ? i spędzam dodatkowy czas, aby znaleźć lub wymyślić lepszy sposób na zrobienie tego.

Myślę, że jeśli będę to robił wystarczająco często, moje rutynowe kodowanie będzie nadal się poprawiać.

RemcoGerlich
źródło
1

Oprogramowanie jest dziwne, a proces tworzenia oprogramowania jest dziwniejszy.

W przeciwieństwie do większości rzeczy w prawdziwym życiu, ale jak większość rzeczy związanych z komputerami

Szybszy jest bardziej niezawodny

Jest to sprzeczne z każdą intuicją, której nauczyło Cię dotychczasowe życie, dobrze dostrojone samochody psują się częściej niż standardowe, szybko budowane domy rozpadają się szybciej, zadania domowe wykonane z tyłu autobusu szkolnego nie otrzymują wysokich not.

Ale powolne procedury metodyczne nie dają lepszego oprogramowania. Faceci, którzy spędzają tygodnie na opracowywaniu dokumentów wymagań i dni na diagramach klas przed napisaniem kodu, nie produkują lepszego oprogramowania. Facet, który spełnia podstawowe wymagania, wyjaśnia kilka problemów, zapisuje schemat klasowy na tablicy i otrzymuje kodowanie swojego zespołu, prawie zawsze będzie produkować bardziej niezawodne i lepsze oprogramowanie, i zrobi to za kilka dni, a nie miesięcy.

James Anderson
źródło
Nie jestem pewien, czy się z tobą zgadzam, ale jest to interesujący, niekonwencjonalny punkt widzenia. +1 za nieszablonowe myślenie.
Flot2011
-1

Ta praca nie jest dla ciebie odpowiednia.

Napisany kod niskiej jakości „ponieważ nie ma czasu, klienci czekają, błąd powinien zostać naprawiony z dnia na dzień, firma traci pieniądze na ten problem, menedżer mocno naciska” jest objawem źle zarządzanej firmy.

Jeśli chcesz być dumny ze swojej pracy i pisać wysokiej jakości kod, najlepiej jest znaleźć pracodawcę, który to zrozumie i zapłaci ci za to.

B Seven
źródło