Szkodliwe pokusy w programowaniu


97

Ciekawe, jakie pokusy w programowaniu okazały się naprawdę szkodliwe dla twoich projektów?

Na przykład, kiedy naprawdę czujesz potrzebę zrobienia czegoś i wierzysz, że przyniesie to korzyść projektowi, albo po prostu oszukasz się, że tak jest, i po tygodniu zdajesz sobie sprawę, że nie rozwiązałeś żadnych prawdziwych problemów, ale stworzyłeś nowe lub , w najlepszym przypadku, zadowoli swoją wewnętrzną bestię bez widocznego wpływu.

Osobiście uważam, że bardzo trudno jest nie refaktoryzować złego kodu. Pracuję z dużą ilością złego, starszego kodu i potrzeba kilku głębokich oddechów, aby go nie dotknąć, gdy nie mam testów, aby udowodnić, że moje refaktoryzacja niczego nie psuje.

Kolejny demon dla mnie w interfejsie użytkownika, mogę dosłownie spędzać godziny zmieniając układ interfejsu tylko dlatego, że lubię to robić. Czasami mówię sobie, że pracuję nad użytecznością, ale prawda jest taka, że ​​uwielbiam poruszać przyciskami.

Jakie są twoje demony programujące i jak ich uniknąć?


19
Uważam za zabawne, że nikt nie był w stanie odpowiedzieć na drugą część twojego pytania - „[i] jak ich uniknąć?”.
Craige

3
Czy ktoś zauważył, że jest to najważniejsze pytanie na SE przez cały dzień.
msarchet

+1 za „... spędzam godziny zmieniając układ interfejsu ...” Zbyt często wpadam w tę pułapkę.
7wp

Odpowiedzi:


67

Przedwczesne uogólnienie to mój wielki błąd; zamiast najpierw rozwiązać problem i poczekać, aż pojawi się rzeczywista potrzeba rozwiązania ogólnej sprawy, zawsze zajmuję się ogólną sprawą i kończę na pisaniu ton kodu, który jest bardziej złożony niż powinien.

Aktualizacja:

Szczegółowy opis znajduje się w „ Sin 1 - Przedwczesne uogólnienie ”.


6
Nienawidzę tego, gdy robią to astronauci z architektury!
ozz

13
Och, radość z fabryk metafabrycznych :(

+1 „Badanie wielkich projektantów wykazało, że wszyscy byli dobrzy w przewidywaniu zmian” (Code Complete 2). Dobrze jest wiedzieć, jakie zmiany są prawdopodobne. Następnie możesz zdecydować, czy można coś zyskać, rozwiązując wcześniej bardziej ogólny przypadek - czy zaoszczędzi to później. Czasami nie jest tego warte, tak samo łatwo zmodyfikować kod później.
MarkJ


1
To. Obwiniam fakt, że tworzenie ładnego, uogólnionego i wielokrotnego użytku kodu jest bardzo satysfakcjonujące, szczególnie jeśli sam problem nie jest bardzo trudny i / lub jest tylko powtórzeniem tego, co zrobiłeś wcześniej. W tym przypadku ogólne operacje na bazie danych CRUD (interfejs użytkownika, reaguj na akcję użytkownika, zrób coś z bazą danych, thar).
Cthulhu

197

„Wrócimy do tego i naprawimy to później. Po prostu potrzebujemy, aby działał teraz!”


16
To jest absolutny diabeł.
alesplin

6
Dałbym ci za to +100, gdybym mógł. „Później” NIGDY NIE DZIAŁA. Rób rzeczy dobrze za pierwszym razem lub wcale.
szybko_now

12
czy nie jest to uzupełnienie spędzania godzin na refaktoryzacji złego kodu? Możemy podzielić świat na programistów, którzy „naprawią to później”, ale nie zrobią tego, a programiści, którzy za pierwszym razem próbują to naprawić, spędzają godziny na „refaktoryzacji złego kodu”.

6
ponownie powiedz to na „Wrócimy i naprawimy następną iterację ” i brzmi to o wiele bardziej uporządkowany
Chris S

4
Państwo musi to zrobić. Jeśli poświęcisz cały swój czas na doskonalenie, nigdy nie zostanie wysłany. Zakończ projekt, a następnie wypoleruj go.
Zan Lynx,

105

Termin jest bardzo odległy, mam wystarczająco dużo czasu, aby to zrobić, więc dlaczego nie poświęcić trochę czasu na surfowanie po Internecie?


72
zamień „web” na „programmers.stackexchange.com” :)
davidhaskins

1
Czy jest coś jeszcze w Internecie, co warto przeczytać? Zapomniałem, że jest coś jeszcze!
James McLeod

3
alias „Damn you, Minecraft”
johnc

1
@ David, to tylko punkt wyjścia w sieci - pytanie brzmi, jak daleko się

Nie mówię, że nie jest to już tak ważne z powodu Agile.
vartec

103

„To jest po prostu wyrzucony kod potwierdzający koncepcję. Kiedy im się spodoba, naprawdę go naprawię”.


13
Nazywa się to Rapid Application Development; i nigdy nie działa w środowisku biznesowym. :)
John Kraft

12
To zabawne, że dla mnie jest na odwrót - po prostu nie mogę zmusić się do napisania wyrzucanego kodu, nawet jeśli jest to dokładnie to, czego potrzeba.
Dan

6
Pracuję w dziale finansów, a RAD wciąż się rozwija, szczególnie w VBA / Excel. Jest w tym jednak talent, RAD nie musi oznaczać niechlujstwa.
Ian

5
Czasami aplikacja, którą spędziłeś dwa lata na doskonaleniu, kończy się wyrzucaniem kodu, ponieważ ktoś wyżej na drabinie zdecydował „och, nie możemy tego zrobić” lub inną wersję „nieważne”.
PSU

12
To. Ja: „To tylko mój dowód koncepcji. Jeśli ci się spodoba, napiszemy wersję produkcyjną”. Menedżer: „Twoja wersja działa, wysyłamy ją!” Ja: „Cóż, to nie obejmuje całego zastosowania, które… już wysłałeś, prawda?”

74
  1. Refaktoryzacja części kodu na kilka dni przed wydaniem.
  2. Internet: największa rozproszenie ze wszystkich.
  3. Nowa technologia : nie mogę oderwać rąk od nowej technologii.
  4. Optymalizuj: optymalizuj, optymalizuj. .. i więcej Optymalizuj
  5. Doskonałość : kod nigdy nie był zadowolony.
  6. DO ZROBIENIA: Brak czasu na zrobienie rzeczy, które nigdy nie zostaną wykonane.
  7. Szacowanie czasu: Wielu premierów nie traktuje tego jako „szacunku”. Biorą za fakt.
  8. Obietnice: dawanie zbyt wielu obietnic.

1
Kiedyś pracował nad projektem, który miał 100 osób w dużym pokoju, a tylko 2 wspólne komputery miały dostęp do Internetu. Wydajność była bardzo wysoka. Kierownictwo dało wszystkim internet i zastanawiało się, dlaczego wydajność pracy zmniejszyła się o połowę.
szybko_now

2
Jeśli chodzi o szacowanie czasu ... tak wielu menedżerów uważa to za punkt wyjścia w negocjacjach (jak negocjowanie ceny). Jedni, którzy traktują to jako fakt wprowadzony w błąd, ale w rzeczywistości powyżej średniej ...
dbkk

@quickly_now Odcięcie sieci prawdopodobnie działa w przypadku przyziemnych zadań, takich jak wprowadzanie danych lub rutynowe poprawki, w których nie trzeba niczego szukać. W przypadku wielu niezwykłych rzeczy (np. Wyszukiwanie dokumentów API / przykładowego kodu) Google jest twoim przyjacielem - samodzielne znalezienie go zajmuje 5 razy więcej czasu. Ponadto, jeśli ludzie nie są zmotywowani i chcą być rozproszeni, znajdą sposoby.
dbkk

@dbkk - tak do pewnego momentu. To wszystko było w Adzie, nie było API do wyszukania, było na wyspecjalizowanym sprzęcie i sklasyfikowane jako bezpieczeństwo narodowe. Umieszczenie niesklasyfikowanych maszyn podłączonych do Internetu w tym środowisku również było koszmarem bezpieczeństwa.
Szybko_niedz.

55

Pada ofiarą próby zbudowania wszystkiego we własnym zakresie, gdy istnieją już frameworki i biblioteki.


6
Czasami istniejące ramy i biblioteki są oznaczone Verboten dużymi czerwonymi literami zgodnie z prawem IT.
Christopher Mahan

22
I oczywiście odwrotna pokusa: użycie nieznanego frameworka lub biblioteki i założenie, że zrobi to, czego potrzebujesz i wszystko pójdzie gładko.
Carson63000,

„ale napisanie zajmie tylko tydzień, a nasza platforma zrobi dokładnie to, co chcemy, darmowa wersja online jest prawdopodobnie pełna błędów”

2
@Christopher: To byłby dobry powód do ponownej implementacji (lub znalezienia innej biblioteki z dopuszczalną licencją). Ale zbyt często powodem reimplementacji jest po prostu NIH…
Donal Fellows,

@Carson: +1 :-)
Macke

48

Moje powtarzające się demony: przedwczesna optymalizacja i nadinżynieria.

I wciąż nie mogę ich uniknąć w 100% ...


10
+1 za nadmierną inżynierię. Kiedyś napisałem całą „strukturę konfiguracji” z „adapterami parametrów konfiguracji” dla plików .ini, plików XML, tabel bazy danych i gniazd sieciowych (ponieważ każdy chce hostować konfiguracyjną usługę internetową, prawda?)
TMN

8
Przedwczesna nadmierna inżynieria?
Christopher Mahan

@Chris ma również zastosowanie „przedwczesna nadprodukcja”. To już wspomniano w innych odpowiedzi też. Wiem, że to jeden z moich banów.
Matthew Scharley

Co powiesz na przedwczesną, nadmiernie zoptymalizowaną mega-inżynierię ...
Newtopian,

4
To jest moje. Obwiniam winę za zarządzanie, dając mi wolne terminy panowania / dalekosiężne terminy i nie dając sobie terminów dla określonych składników.
Cthulhu,

46

Zbyt optymistyczne szacunki

Kiedy twój menedżer patrzy na ciebie z góry i czujesz palące uczucie, że dajesz niższą ocenę niż jelito mówi ... nie rób tego!

W końcu twoje jelita są już prawdopodobnie za niskie!


13
Kiedy pytają, czy to naprawdę potrwa tak długo, po prostu powiedz tak, a następnie usiądź w ciszy, aż poczują się niezręcznie ...
PeterAllenWebb

4
Mój profesor college'u powiedział mi kiedyś: „Ustal swoje najlepsze oszacowanie, a następnie podwoj je”. Do tej pory działało dla mnie.
zzzzBov,

2
Ewentualnie wypróbuj podejście SMBC .
detly

4
Jeden z moich starych szefów potroił szacunki programistów, a następnie podwoił negocjacje z klientami. Klienci myśleli, że dostali umowę, programiści mieli czas, którego potrzebowali, nawet jeśli nie wiedzieli. Win-win!
DaveE

2
Planowanie oparte na dowodach może pomóc w rozwiązaniu tego problemu: joelonsoftware.com/items/2007/107/10/26.html
Rei Miyasaka

33

Używanie technologii / narzędzia / języka w projekcie wyłącznie dlatego, że właśnie go nauczyłeś.

Aby spróbować udowodnić, jak dobry jesteś programistą.

Aby uznać kod, który napisałeś za swój.


Gdybym tylko mógł głosować za każdym razem, gdy to zrobiłem. Na szczęście połowa rozwiązań okazała się całkiem dobra. Połowa nie.
Dan

Lub taki, którego jeszcze się nie nauczyłeś. Nie zapomnij tylko przypiąć pasów, ponieważ będzie to długa jazda.
Evan Plaice,




23

Pełzanie funkcji

Zrób plan, trzymaj się go i wdrażaj. A potem wróć i dodaj rzeczy, o które ludzie proszą.

Widziałem to w kółko. Siadasz, opracowujesz projekt i zaczynasz kodować. Użytkownicy słyszą zdezorientowane bzdury o „zaginięciu” ulubionej funkcji i zaczynają lobbować za nią. Twój szef żąda, abyś dodał go o godzinie 11, fauluje wdrożenie, wszędzie wprowadza błędy, a 3 miesiące później, gdy wszyscy się uspokoją, zostaniesz usunięty, ponieważ nikt nie może zrozumieć, dlaczego umieściłeś ta gówniana funkcja retro w pierwszej kolejności! Nie możesz powiedzieć, że reszta projektu sprawiła, że ​​stało się to bezcelowe?


Pozostawienie specyfikacji niezamrożonej i otwartej jako ustępstwo, ponieważ pierwszy premier (który został teraz zwolniony) nie wiedział nic o rozwoju oprogramowania i zaprojektował całkowicie nierealistyczny harmonogram wydań. Najgorszy pomysł w historii.
Evan Plaice,

20
  1. Dodaj więcej funkcji

  2. Konkurs ma tę funkcję. Jest to więc funkcja obowiązkowa, dlatego więcej programowania niż analizy strategii, pozycjonowania itp.

  3. Konkurs NIE ma tej funkcji. Jest to więc cecha odróżniająca, dlatego więcej programowania niż analizy strategii, pozycjonowania itp.

  4. Rozwiązanie problemu biznesowego dzięki większej liczbie programów. np. lepszej wiedzy na temat administrowania serwerem linux, na którym hostowana jest twoja strona internetowa, nie można zdobyć poprzez zaprogramowanie większej liczby funkcji. Czasami musisz po prostu nauczyć się, jak rozwiązać problem, a nie przekodowywać całość w C # .Net

  5. Rozwiązanie problemu marketingowego dzięki większej liczbie programów. np. nadużywanie koncepcji fioletowej krowy Setha Godina, że ​​pośrednio rozwiązujesz problem marketingowy, programując więcej funkcji w swoim produkcie, aby uczynić go „fioletową krową”. Czasami jest to po prostu zmutowany potwór.

  6. Rozwiązanie problemu z produktywnością dzięki większej ilości programów argumentujących sobie, że czas poświęcony na napisanie tego skryptu zostanie w przyszłości zaoszczędzony w ciągu kilku godzin zamiast faktycznego programowania naprawdę ważnych rzeczy

  7. Planujesz kodować, ale jeszcze nie kodujesz, ponieważ chcesz „zrobić to dobrze”

  8. Kodowanie brudnej wersji i obiecanie, że „poprawisz ją później”, ale nigdy nie wróciłeś do „ulepszenia”

  9. Nie robienie makiety ani mapy witryny, ponieważ jest to „tak kłopotliwe”. Mogę po prostu zrzutować strony konkurenta pod kątem makiet i odręcznie rysować mapę witryny „później”, co nigdy nie jest. A potem przejdź od razu do programowania pierwszej strony, którą wizualizuję w mojej głowie.

Spowiedź: Popełniłem osobiście błędy 1, 3, 7, 8. Popełniłem również 2, 4, 5, 6, ale często oszukiwałem się, że tego nie zrobiłem.

Obecnie naprawiam 9.

EDYCJA Nie zdawałem sobie sprawy, że pytanie wymaga od nas rozwiązania.

1) Dodaj więcej funkcji Po prostu nie rób tego. Współpracuj ze swoim biznesem, marketingiem, założycielami, doradcami itp. I zredukuj swoją aplikację do jednej rzeczy.

Przeczytaj o twitteru, Grouponie itp. O tym, jak po prostu zmniejszają liczbę rzeczy do 1, co doprowadziło do ich sukcesu.

Jeśli uważasz, że to działa tylko wtedy, gdy chcesz budować duże firmy, pomyśl jeszcze raz. Ctrl + F dla tego wiersza „Im więcej funkcji dodam do oprogramowania, tym gorzej się sprzedaje. (Jest to, oczywiście, mało intuicyjne dla większości programistów).” W tym linku

2) Konkurs ma tę funkcję. Jest to więc funkcja obowiązkowa

Zobacz rozwiązanie 1

3) Konkurs NIE ma tej funkcji. Jest to więc cecha odróżniająca

Zobacz rozwiązanie 1

4) Rozwiązanie problemu biznesowego dzięki większej liczbie programów.

Jeśli potrzebujesz zatrudnić kogoś, aby cię uczył, udzielił konsultacji lub zrobił to dla ciebie, a następnie udokumentował, jak to zrobił, abyś mógł zrobić to sam następnym razem. PO PROSTU TO ZRÓB!! Nie przepisuj kodu, nie przechodź GO, nie zbieraj 200 $.

5) Rozwiązanie problemu marketingowego przy większej liczbie programów.

Jeśli ludzie nie rozumieją, co sprzedajesz, jest to problem marketingowy. Wróć do rozwiązania 1 i przestaw się.

6) Rozwiązanie problemu z wydajnością dzięki większej liczbie programów

Czekać.

Poczekaj, aż poczujesz, że Twoja produktywność cierpi z powodu konkretnego problemu z produktywnością przez okres dłuższy niż 2 tygodnie i będzie to możliwe przez kolejne 2 tygodnie.

Teraz oceń czas poświęcony na zaprogramowanie skryptu, aby rozwiązać ten problem. Pamiętaj, aby wziąć swoje najgorsze oszacowanie i pomnożyć przez 2.

Pomnóż szacunek przez stawkę godzinową.

Teraz przejrzyj alternatywne rozwiązania: outsourcing, kup gotowe rozwiązanie, nic z tym nie rób itp

Wybierz najbardziej opłacalne rozwiązanie.

Trzymaj się tego.

7) Planowanie kodowania, ale jeszcze nie kodowanie, ponieważ chcesz „zrobić to dobrze”

Idź ćwiczyć. Poczujesz przypływ endorfin, które zmotywują twój tyłek i sprawią, że planujesz działać. Wiem to, ponieważ właśnie zrobiłem wyciskanie 5x5 i przysiady 5x5.

8) Kodowanie brudnej wersji i obiecanie, że „poprawisz ją później”, ale nigdy nie wrócisz do „ulepszenia”

Skonfiguruj system plików drażniących w GTD. i agresywnie monitoruje. Postępuj zgodnie ze wszystkimi obietnicami dla siebie i innych.

9) Nie robienie makiety lub mapy witryny, ponieważ jest to „tak kłopotliwe”.

Idź wydać 75 USD na wersję balsamiq makiet na komputery. Wiem to, ponieważ kupiłem to 3 tygodnie temu. To sprawiło, że przerobiłem moje makiety, ponieważ czuję się artystą, architektem i wizjonerem w jednym, mimo że mój rysunek w prawdziwym świecie jest do bani. Czcionka używana w balsamiq nieświadomie przypomina, że ​​jest to tylko makieta, nie osadzona w kamieniu, która pomaga w RAD.

Zakończ edycję


Dałem +1 tej odpowiedzi, ale trudno mi było ją przeczytać. Nie do końca rozumiem kontekst pierwszych 9 punktów. Czy mógłbyś to wyjaśnić? Dobra robota.

@MattFenwick Cześć, dziękuję za +1. Punkty 1-5 zwykle stosuje się w scenariuszu tworzenia produktu do sprzedaży, ale można go również zastosować w scenariuszach, w których tendencja do znalezienia najlepszej odpowiedzi prowadzi do szeroko zakrojonych badań dotyczących stanu techniki. Np. W badaniach.
Kim Stacks,

Punkty 6-9 odnoszą się bardziej do neurotycznych tendencji programisty. Czytałem gdzieś (nie mogę go znaleźć), że projektant zawsze podchodziłby do każdego problemu z rozwiązaniem projektowym; marketer z rozwiązaniem marketingowym; i programista z rozwiązaniem kodu. Tak, przerażające: „Kiedy masz złoty młot, wszystko, co widzisz, to zespół paznokci”. Jest to szczególnie widoczne w punkcie 6). Rozwiązywanie problemu z wydajnością przy większym programowaniu
Kim Stacks,

@MattFenwick przepraszam, jeśli pomyliłeś się z moim imieniem. Zmieniłem swój pseudonim po napisaniu tej odpowiedzi. Widzę, że twoje pochodzenie jest bardziej w badaniach. Moja odpowiedź wynika w dużej mierze z mojego doświadczenia w opracowywaniu rozwiązań do sprzedaży. Ale jestem pewien, że istnieją pewne podobieństwa między moją pracą a twoją, ponieważ oboje zajmujemy się programowaniem.
Kim Stacks,

17

Kilka piw pomoże mi pracować lepiej i dłużej.


11
Zaraz ... masz na myśli, że nie? ( xkcd.com/323 )
Craige

4
@Craige: po 21 latach doświadczenia w piciu i 20 latach doświadczenia jako profesjonalny inżynier oprogramowania nadal pracuję nad częścią dotyczącą kalibracji.
Adam Crossland

4
@adam, zajęło ci rok picia, aby zostać inżynierem?

17
Kodowanie podczas picia piwa pomaga tworzyć niezwykle popularne sieci społecznościowe, które za kilka lat będą warte miliardy. To prawda, widziałem to w filmie.
janosrusiczki

1
@Kitsched: Yep! Zwłaszcza jeśli masz do zerwania wcześniejszy projekt innej osoby.
Mason Wheeler,

16

„Tak, mogę zmienić ten gigantyczny bałagan 2000 linii spaghetti w ciągu jednego dnia ...”


13
Alternatywnie: „nowy facet [który absolutnie nic nie wie o oprogramowaniu ani strukturze jego kodu] nic nie robi, może to naprawić”. Punkty bonusowe, gdy facet nigdy nie używał języka, w którym napisany jest kod.
wildpeaks

16

„Mogę sobie z tym poradzić bez testu. To zbyt trudne do przetestowania”.

i to zły brat

„Muszę mieć na to test, bez względu na to, jak trudny jest test, aby napisać lub zrozumieć”.


2
Jeśli test jest trudny do napisania, być może nie programujesz go poprawnie :)
Merlyn Morgan-Graham

2
@ Merlyn Morgan-Graham, całkiem prawda. Ale są pewne obszary, takie jak współbieżność, które są po prostu trudniejsze do przetestowania.
Wayne Conrad,

1
@Merlyn: Jeśli okaże się, że piszesz symulator instrukcji, aby wymusić zmianę kontekstu w odpowiednich miejscach, to prawdopodobnie posunąłeś się za daleko w testowaniu współbieżności. :)
Zan Lynx

1
@Zan: Zgadzam się - w wymaganym momencie odepchnąłem programistów i spróbowałem zmusić ich do zmiany kodu i pozwolić mi wstawiać kpiny. Pracuję przeciwko wysokim językom, gdzie patrzymy na Big-O, optymalizujemy wąskie gardła, musimy myśleć o współbieżności przede wszystkim pod kątem integralności danych, a nie surowej prędkości, i dostarczać (i często żadną z nich, ponieważ jest to po prostu wystarczająco szybkie poza pudełko).
Merlyn Morgan-Graham

15

Zwlekanie i optymistyczne szacowanie zadań to moje największe grzechy.

Rozciąganie, pompki lub pompki (lub inne ćwiczenia fizyczne) dla pierwszego i pesymistyczny nastrój przed podaniem oceny dla drugiego.


Wyjaśnienie ... Przez „optymistyczne oszacowanie zadania” masz na myśli „syndrom łatwego gówna”, prawda? :)
Evan Plaice

@Evan Plaice - dokładnie. Na przykład „och, to takie trywialne”, a następnie przeglądanie każdej litery kodu po rozpoczęciu właściwego kodowania.
Nikita Barsukov

13

„Znacznie łatwiej jest przywrócić funkcjonalność od podstaw niż zrozumieć istniejący kod”.


2
Tak, c2.com/cgi/wiki?RewriteCodeFromScratch twierdzi, że jest to jedna z „rzeczy, których nigdy nie powinieneś robić”.
David Cary

Praca na otwartym oprogramowaniu pomaga w tej tendencji. Osobiście wpatrywałem się w łatki przed zezem, a potem napisałem własną implementację tylko po to, aby zdać sobie sprawę, że jest ona prawie identyczna z łatką (nawet po ulepszeniu / refaktoryzacji mojego kodu). Zabawne, jak to działa.
Evan Plaice,

10

Jedną z bardzo szkodliwych pokus, na które cierpiał projekt, na którym jestem, jest „efekt platformy wewnętrznej”. Jest to podejście, które Architekci, którzy już dawno odeszli, oparli się na swojej nieskończonej mądrości, która stworzyła projekt, który generuje około 20 milionów dolarów rocznie, ale kosztuje 60 milionów na aktualizację i utrzymanie (przybliżone liczby oczywiście, ale taka jest wielkość problemu).


10

NIH - nie wynalazł tutaj

Naprawdę trudno mi dać uczciwym szansom rozwiązania innych firm. Wszyscy powinni naturalnie sceptycznie podchodzić do rozwiązań innych firm, które nie były dla nich dostosowane, ale trudno mi być obiektywnym w 100%.

Oszczędność czasu może być tak duża, że nawet jeśli 9 razy na 10 Należy unikać rozwiązanie innej firmy, muszę być na tyle cel zrealizować jedną , która będzie pracować.


1
Widzę twój punkt widzenia i muszę z tym cały czas żyć. Jestem wręcz przeciwnie zdania, że ​​czasami zasługuje na odpowiedź tuż obok ciebie. Trudno mi jednak uwierzyć, że mogę zrobić lepiej w ciągu tygodnia niż grupa ekspertów w tej sprawie, która jest od lat. Oczywiście musisz upewnić się, że osoby stojące za wspomnianą stroną trzecią są rzeczywiście ekspertami. Dobre badanie otaczającego środowiska komponentu znacznie pomogło w prawidłowym wyborze między adaptacją a kodowaniem.
Newtopian

1
@Newtopian „poprawny” sposób jest zdecydowanie gdzieś pośrodku. Mój problem z bibliotekami stron trzecich nie polega na tym, czy dam sobie radę lepiej niż zespół ekspertów dysponujących miesiącami lub tygodniami, ale rzadko , a może nigdy nie znajdę biblioteki, która jest dokładnie tym, czego potrzebujemy. Zawsze jest przystosowanie do zrobienia, a potem często ja i inni spędzają tyle czasu zapasy z tym, jak pisanie rozwiązanie, które jest dokładnie to, czego potrzebujemy.
Nicole,

Ja, pochodzący z przeciwległego końca spektrum, byłem tylko ciekawy, jak udało ci się osiągnąć to „tylko środkowe”, jeśli w ogóle. Byłem także ciekawy, co sprawia, że ​​nie chcesz korzystać z usług stron trzecich, próbując zrozumieć, co sprawia, że ​​nadużywam ich, ponieważ jestem pewien, że oba są równie szkodliwe dla wydajności.
Newtopian

@Newtopian, czy moje powyższe wyjaśnienie ma sens, dlaczego? Moja próba osiągnięcia środka jest prosta, aby być bardziej obiektywnym podczas oceny i szukania rozwiązań innych firm.
Nicole,

9

Projektowanie, kodowanie i / lub testowanie jednostkowe na podstawie dostarczonych „przykładowych danych” zamiast analizowania kopii faktycznej bazy danych klientów. Termin był krótki i wciąż powtarzali, że nadchodzi, ale nigdy tak nie było. Po rozmieszczeniu eksplozja była spektakularna. Naprawdę, kto spodziewałby się, że klient będzie miał 3 klientów macierzystych.

Nigdy więcej nie rozpocznę projektu, dopóki nie będę miał kopii prawdziwych danych.


Jeśli nie ma jeszcze produktu, czy będą jakieś dane do skopiowania?
Svish

Jeśli nie ma danych, zawsze jest papier. Pomogłyby w tym również dane firmowe.
burnt_hand

9

Jest musi być biblioteka, która robi to gdzieś syndrom.

blisko związany z

Plugin Fetish


2
Wydaje mi się, że zawsze potrafię znaleźć bibliotekę, która „robi to”. Moim problemem często jest sprawienie, by działały zgodnie z reklamą. :(
Ben L

Łatwo znaleźć bibliotekę - Trudno znaleźć bibliotekę z wbudowanymi dobrymi testami jednostkowymi
burnt_hand

8

Perfekcjonizm zabija; prawdopodobnie największy powód, dla którego projekty się nie powiodły.


Możliwe, że to prawda, ale nigdy nie brałem udziału w projekcie, który nie powiódł się z tego powodu lub nawet się spóźnił.
PeterAllenWebb

Zależy, w jaki sposób definiujesz perfekcję i jaki jej poziom chcesz osiągnąć.
Svish


7

Przepisywanie zamiast refaktoryzacji.


Zgodzić się. Jeśli chcesz zaangażować się w wysiłek wymagany do ponownego napisania, prawie ZAWSZE lepiej jest zrefaktować. Nadal potrwa to dłużej, niż się spodziewałeś, ale stopniowo przeprowadzasz refaktoryzację, prawda? Możesz przestać, zanim będzie „idealny”.
PeterAllenWebb

1
jako następstwo .... pisząc jeszcze raz w innym miejscu zamiast ponownego faktorowania. Nasza baza kodu ma tak wiele różnych implementacji tych samych rzeczy, że nie można uzyskać żadnej spójności.
Newtopian

6

Myślenie, że musi być lepszy sposób, aby to zrobić. Nie zamierzam zadowolić się czymś, co może być „wystarczająco dobre”. Biorę tylko perfekcję! Zazwyczaj można tego uniknąć, rozmawiając z innymi osobami, które mogą mieć inne spojrzenie na problem lub widząc rozwiązanie z innej perspektywy.


5

Automatyzacja wszystkiego do tego stopnia, że ​​więcej czasu poświęca się na utrzymanie narzędzi niż na faktyczną pracę.

Rozwiązanie: podobnie jak w przypadku optymalizacji kodu, najpierw znajdź wąskie gardła związane z produktywnością, a dopiero po ich wykryciu napraw je za pomocą dobrej automatyzacji .


Zasadniczo mogę się z tym zgodzić, ale w praktyce nigdy nie widziałem nadmiernej automatyzacji. To może być tylko moje doświadczenie.
PeterAllenWebb

4

Jakie są twoje demony programistyczne?

Oprócz tego, o czym wspominali inni.

Priorytetyzacja : ignorowanie prac o wysokim priorytecie w odniesieniu do projektu i praca nad innymi rzeczami w projekcie, ponieważ są one bardziej interesujące!

Jak ich uniknąć?

Z odrobiną samodyscypliny. Poważnie, samodyscyplina i motywacja do właściwego postępowania pomaga uniknąć większości z tych „demonów”.


3

Nie otrzymaliśmy jeszcze zgody od klienta, ale zbliża się ostateczny termin, więc oto kilka wstępnych konkursów, dzięki którym możesz zacząć ...

Później, po zakończeniu budowania projektu w celu dopasowania do komp ...

Och, oto poprawki klienta, oni chcą tylko zmienić kilka drobnych rzeczy *

(* główna funkcjonalność jest zupełnie inna)

Następnie ciągle refaktoryzujesz swój oryginalny kod, w oparciu o oryginalny wadliwy model, zamiast zaczynać od zera, ponieważ jesteś pod presją krótkiego terminu i zakładasz, że były to ostatnie poprawki.

Cały czas mnie to obchodzi. Trudno tego uniknąć jako twórca stron internetowych. Moja najlepsza rada to naciskać na więcej czasu, aby można było wprowadzić zmiany we właściwy sposób.


2
Przyjmij zasadę, zgodnie z którą nie zaczynasz tworzenia, dopóki nie uzyskasz podpisu klienta.
Ben L

1
@Ben: Gdyby tylko to było pod naszą kontrolą!
sevenseacat
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.