Szkodliwe pokusy w programowaniu

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ąć?

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

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

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?

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

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.

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

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

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

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!

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.

Zrobię sobie przerwę i spojrzę na stackoverflow.com;)

Najgorsza pokusa:

Och, cóż ... Myślę, że jeden brudny mały trick / hack / fix nie zaszkodzi.

Zgadnij co, to boli. :)

Zapomnienie o tym, że pisanie kodu jest ostatecznością dla rozwiązania problemu .

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?

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ę

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

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

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

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.

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

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

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

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.

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

blisko związany z

Plugin Fetish

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

Czasami programowanie doprowadza mnie do butelki.

Przepisywanie zamiast refaktoryzacji.

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.

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 .

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

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.