Jak zostać „szybszym” programistą?


142

Moja ostatnia ocena pracy zawierała tylko jeden słaby punkt: terminowość. Jestem już świadomy pewnych rzeczy, które mogę zrobić, aby to poprawić, ale szukam czegoś więcej.

Czy ktoś ma wskazówki lub porady na temat tego, co zrobić, aby zwiększyć szybkość produkcji bez poświęcania jej jakości?

Jak oceniasz terminy i trzymasz się ich? Co robisz, aby zrobić więcej w krótszych odstępach czasu?

Wszelkie opinie są mile widziane, dzięki,


96
Jeśli to zrobisz, poświęć mniej czasu na SO w pracy.
San Jacinto,

52
Jeśli to czytasz, jest już za późno

32
Przeczytałem „Jak zostać grubszym programistą”.
Rozśmieszyło

13
Zadałbym ci kolejne pytanie. Czy pragnienie bycia „szybszym programistą” jest wynikiem własnej słabej wydajności (AKA, musisz doskonalić swoje umiejętności, musisz skupić się i eliminować rozproszenia (takie jak SO) itp.), Czy też źle planujesz na podstawie rozwoju punkt widzenia (AKA, dostałeś 1 tydzień na zrobienie czegoś, co każda rozsądna osoba wiedziałaby, że zajmie to 1 miesiąc). Każda pozycja ma bardzo różne rozwiązania.

3
Nie ma jednej właściwej odpowiedzi, więc zmień się w pytanie społeczności wiki lub zadaj pytanie zamknięte.
Donal Fellows

Odpowiedzi:


190

Wyłącz komputer. Weź ołówek i papier. Naszkicuj swój projekt. Przejrzyj to z kolegami. Następnie napisz kod.


9
LUB możesz pozostawić komputer włączony i otwarty, tj. MS Visio
sshow

208
Ołówek i papier lub tablica są szybsze niż większość aplikacji, z których korzystałem.
Thomas Owens

24
Robienie tego na papierze skupia umysł.

100
dlaczego nie mogę głosować za komentarzem Visio? Nieużywanie programu Visio to pewien sposób na przyspieszenie rozwoju!

52
Ugh .... Visio. Za każdym razem, gdy jestem proszony o „użycie Visio w dokumencie projektowym”, najpierw szkicuję go na papierze, a następnie spędzam następne dwa dni walcząc o poprawienie wszystkich linii w Visio.
Robert Fraser,

149

Jakieś pomysły...

  • Unikaj pozłacania - rób tylko to, o co Cię prosisz (pod względem wymagań)
  • Poznaj wymagania biznesowe i zrób to dobrze za pierwszym razem
  • Dokładnie zrozum swoje środowisko i narzędzia
  • Zostań fantastyczną maszynistką, używaj skrótów klawiaturowych zamiast myszy
  • Podejdź iteracyjnie i zastosuj kontrolę czystości, aby upewnić się, że podążasz właściwą drogą
  • Nie wymyślaj na nowo koła, rozważ ponowne wykorzystanie wcześniejszej pracy i pracy innych
  • Wyeliminuj rozproszenie uwagi, nie sprawdzaj poczty e-mail, nie spoglądaj na zewnątrz, rozmawiaj ze współpracownikami itp.
  • Nie przepracuj się - rozpoznaj, kiedy musisz robić przerwy

7
+1 za nieumyślenie koła. Naucz się tworzyć kod wielokrotnego użytku, który może być podłączony do innego kodu i pracować z zerowym lub małym ponownym pisaniem. (np .: funkcje z parametrami zamiast kodowania na sztywno)

34
+1 za „unikanie pozłacania” - to spowodowało, że straciłem zdecydowanie zbyt wiele terminów z powodu moich skłonności do perfekcjonizmu / zatrzymywania anali.
Dinah

7
Pisanie na maszynie - ważny punkt. Zawsze jestem zdumiony liczbą programistów, których spotykam, którzy nie nauczyli się pisać ...
Paddy

2
+1 eliminuje rozproszenie uwagi. Widzę, że jedzą głównie czas.

2
+1 za wskazówki dotyczące mikro-ulepszeń (zamiast makro-ulepszeń w zakresie planowania projektów).

132

Twoje pragnienie bycia „szybszym” programistą jest godne pochwały. Jednak niedostarczenie na czas nie oznacza, że ​​jesteś wolny, oznacza to, że projekt został źle zaplanowany. Bycie „szybszym” programistą nie pomoże; oznacza to tylko, że szybciej przekroczysz termin.

Ty (i Twój zespół) popełniacie jeden z następujących błędów (lub wszystkie z nich):

  • niedocenianie pracy, którą należy wykonać;
  • brakuje dużego wymagania lub fragmentu architektury podczas planowania;
  • mylące prognozy pracy z prognozami kalendarza i nie uwzględniające takich rzeczy jak spotkania / telefon / inne koszty ogólne;

Istnieje wiele sposobów rozwiązania jednego z trzech powyższych przypadków. Ale zanim będziesz mógł ulepszyć którekolwiek z nich, musisz wiedzieć, dlaczego wszystko idzie tak, jak jest. Wykonaj pośmiertnie szacunki ostatnich dwóch lub trzech projektów w stosunku do faktycznego czasu i dowiedz się, gdzie upłynął dodatkowy czas.

Powtórzę to jeszcze raz - powolne pisanie kodu nie spowoduje przekroczenia terminu , jeśli właściwie zaplanowałeś, aby uwzględnić ten fakt.


47
Jednak niektórzy deweloperzy są naprawdę zbyt powolni. To może być problem.

12
Tak, to może być problem, ale jest to problem osobisty. Nigdy nie powinien stać się problemem projektowym lub zespołowym. Innymi słowy, może mieć wpływ na karierę, ale nigdy nie powinien wpływać na harmonogram projektu.
Franci Penov

12
„niedostarczenie na czas nie oznacza, że ​​jesteś wolny, oznacza to, że projekt został źle zaplanowany” - to opis nieprawidłowego argumentu w polu tekstowym. istnieje wiele innych powodów, dla których możesz nie dotrzymać terminów, z których jednym może być powolność.
mięso

15
@flesh - jeśli wiesz, że jesteś powolny, dlaczego nie miałbyś planować, aby uwzględnić ten fakt w harmonogramie? Innymi słowy, jeśli wiesz, że nie możesz biec tak szybko jak Usain Bolt, czy planowałbyś biec 100 mw 9,7 s?
Franci Penov

5
@Kibbee - w tej sytuacji ograniczasz funkcje. nie możesz obiecać wykonania określonej pracy w określonym czasie, gdy wiesz, że nie da się tego zrobić, i masz nadzieję na cud.
Franci Penov

89

Naprawdę, naprawdę naucz się swojego edytora. Jeśli używasz IDE, upewnij się, że korzystasz ze wszystkich funkcji, które oferuje. Zdobądź ściąg, aby poznać skróty klawiaturowe dla wybranego edytora. Jeśli używasz powłoki, skonfiguruj skróty do często używanych katalogów


3
To czasem może drastycznie zwiększyć produktywność
pokaż

6
Pisanie rzeczywistego kodu to tylko część pracy dewelopera. Poświęcenie czasu na opanowanie IDE do perfekcji jest optymalizacją punktową; i wiesz, co mówią o optymalizacjach, prawda? - „Najpierw zmierz, a następnie zoptymalizuj wąskie gardła”.
Franci Penov

1
W ogóle tego nie widzę. Jeśli obniżę o 50% czas pisania, ile czasu to pozwoli mi zaoszczędzić w ciągu jednego dnia? Z mojego doświadczenia, spędzam większość czasu myśląc o / testując / oceniając / nieznacznie modyfikując / etc kodu, w porównaniu do faktycznego pisania, myślę, że nie byłby to zbyt duży sukces.

4
To sprawia, że ​​poruszanie się po IDE jest czymś, co robisz bez zastanowienia. Wszystko, co wymaga jakiegokolwiek świadomego wysiłku, takie jak przejście do małego szarego przycisku oznaczonego czymś lub innym obok wszystkich innych szarych przycisków spowalnia cię, przerywając twoje myślenie. Posiadanie ctrl-n pod palcami bez żadnego ruchu jest dużą wygraną netto.
Paul McMillan,

5
W tym samym wierszu: naucz się ogólnych „skrótów”. Np. W wielu programach Windows ... Kopiuj: Ctrl + c Wytnij: Ctrl + x („x” wygląda jak otwarta para nożyczek) Wklej: Ctrl + v (tuż obok „c” i „x” powyżej) Idź na początek wiersza: Strona główna Idź na koniec wiersza: Koniec Przesuń kursor według słowa (nie znak): [Shift] + Ctrl + lewo lub prawo Idź na górę dokumentu: Ctrl + Home Idź do końca dokumentu: Ctrl + End itp.

38

„Czy ktoś ma wskazówki lub porady na temat tego, co robi, aby zwiększyć szybkość produkcji bez poświęcania jej jakości?”

Wiele osób dąży do uzyskania „najwyższej” jakości kosztem czegoś, co jest (a) proste, (b) niezawodne i (c) prawidłowe.

Najważniejszym sposobem na przyspieszenie rozwoju jest uproszczenie tego, co robisz, aby było to absolutnie tak proste, jak to możliwe.

Większość ludzi, którzy mają problemy z dostarczeniem na czas, dostarcza zbyt wiele. Podane powody są często głupie. Często są to tylko postrzegane wymagania, a nie rzeczywiste wymagania.

Słyszałem, że wiele osób mówi mi, czego „oczekuje” klient. To zła polityka.

Zbuduj najprostszą możliwą rzecz. Jeśli klient wymaga więcej, zbuduj więcej. Ale najpierw zbuduj najprostszą możliwą rzecz.


„Wielu, wielu ludzi dąży do„ najwyższej ”jakości kosztem czegoś, co jest (a) proste, (b) niezawodne i (c) prawidłowe”. Mogłeś to zostawić, a ja głosowałbym na to.
corymathews,

„Uprość, uprość”. ~ Henry David Thoreau

2
Tak ... to też oznacza przedwczesną abstrakcję. Jeśli coś będzie miało tylko jedną implementację, nie rób z tego interfejsu.
Robert Fraser,

3
Jeden z moich ulubionych cytatów jest odpowiedni w tej sytuacji „zrób coś tak prostego, jak to możliwe, ale nie prostszego” ~ parafraza, Albert Einstein
Nemi

Uprość to, czego nawet wielu programistów nie rozumie poprawnie: wpadają w pułapkę „przedwczesnej optymalizacji, która jest źródłem wszelkiego zła”, którą łatwo można złapać. Zwykle najprostszym programem jest najszybszy lub najwyższej jakości.

32

Unikaj dopracowywania kodu do perfekcji, po prostu spraw, aby działał. Tego oczekuje firma.

Ale często zwiększenie prędkości oznacza poświęcenie jakości.


10
Proponuję „sprawić, by działało”, a jeśli czas pozwoli na jego udoskonalenie!
Preets

28
-1: Nie ma powodu, by poświęcać jakość. Zawsze możesz poświęcić funkcje.
S.Lott,

6
Widziałem to wielokrotnie. Programiści rozłączają się przy ostatnim 1% danej funkcji, a następnie próbują uzupełnić pozostałe funkcje, nadrabiając zaległości i pozostając w tyle. Najpierw wypełnij to, czego się od ciebie oczekuje, a następnie wróć i wypoleruj.

3
Często wzrost jakości oznacza zwiększenie prędkości. Jeśli poświęcisz trochę czasu, aby to dobrze zrobić, możesz zaoszczędzić więcej czasu na testowaniu i debugowaniu.
David Thornley,

2
Jeśli utknąłeś przy jednej funkcji, popracuj nad czymś innym.

29

Ponowne użycie - staram się wyliczyć sprytne elementy z poprzednich projektów, aby móc ich ponownie użyć w przyszłych przedsięwzięciach. Zawsze warto zadać sobie pytanie: „czy mógłbym kiedyś tego użyć ponownie?”


Idealny stan umysłu do szybszego programowania na dłuższą metę, chociaż na początku może to zająć więcej czasu.

8
+1: Uważaj jednak, przyłapałem się na uogólnianiu i abstrakcji czegoś, abym mógł użyć go ponownie następnego dnia ... i spóźniłem się na ten dzień lub podwoiłem czas, jaki błąd powinien naprawić ... aby móc „może” później zaoszczędzić czas.
Steven Evers,

2
Kluczem jest posiadanie „torby sztuczek”. Jeśli staje się to dla ciebie problemem, warto poświęcić trochę czasu na opracowanie elementów wielokrotnego użytku (zakładając, że domena, w której pracujesz, nadaje się do ponownego użycia kodu).

24

Nie komplikuj.

Jeśli korzystasz z TDD, postępuj zgodnie z „ czerwonym, zielonym, refaktorem ”:

  1. Napisz test negatywny ( czerwony ). (Często ze względu na funkcjonalność kodu jeszcze nie ma).
  2. Popełniaj straszne przestępstwa związane z kodowaniem, aby pomyślnie przejść testy ( zielony ). W razie potrzeby kod stały.
  3. Refaktoryzacja , prawdopodobnie przełamywanie testów na krótki czas, ale ogólnie poprawa projektu.

3
Podczas wykonywania TDD masz testera, który generuje czerwony / zielony raport dla każdego testu, aby wskazać, czy zdał.

2
@Konstantin: Pisanie kodu przy użyciu TDD może potrwać o 20% dłużej, ale daje także lepszy kod, a na dłuższą metę, gdy system rośnie, szybkość wprowadzania zmian pozostaje taka sama. TDD pomaga uniknąć długu technicznego, który cię spowalnia.

3
Pisanie nigdy nie było powolną częścią programowania. Nawet jeśli musisz pisać więcej za pomocą TDD, nie spowalnia Cię to. Może nawet cię przyspieszyć, ponieważ napisanie testu pomaga skoncentrować się na tym, co jest potrzebne, zanim pomyślisz o tym, jak go wdrożyć.

1
Jeśli kierownictwo nie rozumie jakiejś kluczowej koncepcji, powinieneś im to wyjaśnić. Na przykład martinfowler.com/bliki/TechnicalDebt.html

3
@Konstantin, jeśli uważasz, że „rozwój” jest aktem pisania instrukcji kodowej, zgodziłbym się z tobą. Jeśli jednak uważasz, że „rozwój” obejmuje pakowanie, przygotowywanie notatek kompilacji, wdrażanie, testowanie, tworzenie raportów o defektach, przeglądanie i ustalanie priorytetów defektów, przydzielanie zadań, badanie, debugowanie i naprawianie oraz rozpoczynanie procesu od nowa - to 15 minut na napisz test jednostkowy przeważa ponad 1000 dni i utrata zaufania klientów.

22

Pobierz lokalnie wszystkie dokumenty dotyczące swoich języków / bibliotek na komputer, a następnie odłącz kabel sieciowy / wyłącz Wi-Fi .

Nie próbuję tu być zabawnym. To mi naprawdę pomaga!


Robię to samo.

Wyszukiwania dokumentacji online i rozwiązywania problemów są przeceniane.

Zainstaluj zaporę sieciową i skonfiguruj ją tak, aby blokowała prawie cały dostęp do sieci (mam wyjątki dla kilku domen, np. MSDN)
finnw

Naprawdę zastanawiam się nad zrobieniem tego (fakt, że zostawiam ten komentarz wystarczający
dowód

I stracić SO? piekło nie

20

Zwróć uwagę, gdy czytasz zbyt długo Przepełnienie stosu. Wymówka „Kompilowanie” działa tylko tak długo. :)


15
Zależy od tego, jak szybki jest twój kompilator. Więc może „rozwiązaniem” jest znalezienie wolniejszego kompilatora i uruchomienie go na Pentium 2 z pamięcią 128 MB? :-)
Franci Penov

@Franci, być może nawet umieszczenie przestrzeni wymiany na dyskietce. Lub dwa w RAID.

20

Zbyt często unikaj przełączania zadań. Rozproszenie uwagi i przełączanie zadań mogą zabić dzień, nawet jeśli używasz narzędzi takich jak Mylyn do zarządzania zadaniami.

Ustal granularność (np. 30 minut) i pracuj tylko nad rzeczami związanymi z danym zadaniem. Wszystko inne (nowe raporty o błędach, e-maile dotyczące innych problemów, kwestie proceduralne, które nie są ze sobą powiązane) jest opóźnione przynajmniej do „następnego punktu kontrolnego”. Pamiętaj, aby wyłączyć wyskakujące powiadomienia e-mail, aby się nie wciągnąć.

Jest to szczególnie skuteczne, jeśli masz kumpla w swoim zespole, który poinformuje cię, czy rzeczy naprawdę się stopią i wymagają natychmiastowej uwagi.


To nie zadziała, jeśli masz szefa, który oczekuje odpowiedzi na e-maile w ciągu 10 minut.
finnw

To jest naprawdę bardzo istotne. O ile jest to racjonalnie możliwe, nie pozwól sobie paść ofiarą samolubnych przykuwających uwagę i trzymaj się swojego pierwotnego zadania. Jeśli pozwolisz sobie na ciągnięcie w różnych kierunkach, efekt końcowy jest taki, że nic nie osiągniesz zamiast czegoś.
AndyUK

14

Zrób to dobrze, najlepszy sposób, za pierwszym razem. Jeśli to oznacza, że ​​musisz przestać i zastanowić się przez chwilę, zanim zaczniesz, zrób to. Działa w 90% przypadków.


2
+1 To prawda. Nie oznacza to, że musisz być „doskonały”; wszyscy popełniamy błędy. Ale jeśli za pierwszym razem zrobimy wszystko, co możliwe, konsekwencje tych błędów będą znacznie mniejsze.

+1 - Wydaje mi się, że czytam gdzieś, że różnica między dobrymi i złymi programistami nie jest szybka. Różnica polega na tym, że dobrzy programiści zatrzymają więcej kodu.
Jason Baker

To moje motto, zrób to po raz pierwszy we właściwy sposób. Nie przyzwyczajaj się do konieczności wracania i poprawiania kodu, ponieważ nie zrobiłeś tego poprawnie zgodnie ze specyfikacją.

„Jeśli nie masz czasu, aby zrobić to dobrze, to jak będziesz miał czas to zrobić?”
Alex Feinman

Może trzeba doświadczenia od rzeczywistego oprogramowania, aby móc określić, co jest najlepszym sposobem. W takim przypadku nie można tego zrobić za pierwszym razem.

14

Naucz się pisać jak najszybciej .


2
To niezły bonus ... ale nie sądzę, żeby miał on ogólnie duży wpływ. Wpisywanie kodu jest prawdopodobnie najmniej czasochłonną częścią. (Tak, śledziłem i czytałem link. Po prostu się z nim nie zgadzam.)

Jeśli czynnikiem ograniczającym kodowanie jest szybkość pisania, prawdopodobnie pracujesz na niewłaściwym poziomie abstrakcji.
Pete Kirkham

+1. Świetny link, świetny artykuł dla tych, którzy czytają go do końca;) Pisałem dobrze, ale zainspirowało mnie to do przejścia na układ klawiatury programisty Dvorak en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard (ale zmieniłem „” i -_ klawisze z Microsoft Keyboard Layout Creator) i jestem pewien, że wkrótce będę pisać dużo szybciej :) Zobacz także: typematrix.com/dvorak
Roman Boiko


12

Ćwicz i ciężka praca.

Musisz poświęcić czas i wysiłek. Gdy poczujesz się bardziej komfortowo i pewnie, niezależnie od narzędzi, których używasz, szybkość i kreatywność.

Jeśli chcesz poprawić jakąś konkretną umiejętność, może również pomóc zaprojektować ćwiczenia, które pozwolą ci pracować nad tym konkretnie. Jeśli Twoja powolność jest w fazie projektowania, spróbuj znaleźć problemy projektowe, nad którymi można pracować online. Ponowne wykonanie tego samego ćwiczenia pozwoli ci ukończyć je szybciej i ćwiczyć szybkość. Osobiście lubię ćwiczenia algorytmów TopCodera do ćwiczenia czystej prędkości programowania. Mają też wyzwania projektowe, ale ich nie próbowałem.


Praktyka jest często niedoceniana w programowaniu. To powinna być jedna z 5 najlepszych odpowiedzi.

Łał. Nie jestem pewien, dlaczego też nie jest wyższy. Tak naprawdę nigdy tego nie próbowałem. Spróbuję!
David

11

Dowiedz się o Strefie, dowiedz się, jak się do niej dostać, i naucz się rozpoznawać, kiedy jej nie ma.

Kiedy jestem już w strefie, jestem niezwykle produktywny i kod po prostu wypływa ze mnie, często mogę otrzymać kodowanie 2 lub 3 dni w ciągu 1 dnia. Ale często trudno mi dostać się do tego miejsca, dlatego zwlekam, rozpraszają mnie inne rzeczy (na przykład Przepełnienie stosu).

Cytat z tego, co-sztuczki-zrób-wykorzystaj-aby-dostać-się-w-strefie


I opuść lunch, jeśli jesteś w strefie ... lub spóźnij się ... MMMmm Strefa. rozpływać

10

Dobra znajomość IDE i frameworka. Konieczność zwrócenia się do Google w każdej drobiazgu wymaga czasu.


Ważne jest również zdawanie sobie sprawy z tego, kiedy potrzebujesz Google i szybkie robienie tego.

9

1
Przeprowadź edycję tego, aby móc go głosować, ponieważ jest on obecnie „za stary”.
kmarsh

1
Jednak silnie zależy od tego, do czego musisz go użyć.

8

Zanim zaczniesz opracowywać:

  • Wyloguj się ze swojej skrzynki pocztowej
  • Wyłącz wszystkich klientów czatu
  • Uprzejmie poproś rówieśników, aby dać ci czas na koncentrację
  • Oczywiście przestań surfować po Internecie

Za każdym razem, gdy przeszkadzasz, zwolnisz, ponieważ myślenie zajmuje trochę czasu. Słyszałem liczby, że dla każdej przerwy ludzki umysł potrzebuje 5-10 minut, aby powrócić do procesu myślowego, który miał przed przerwą. Przy takiej ilości czasu na przerwę nie trzeba wiele tracić przez cały dzień.

Pracownicy naszej firmy zaczęli blokować czas w swoich kalendarzach, a następnie przeprowadzali się do pustej sali konferencyjnej na kilka godzin każdego dnia.


7

Dowiedz się o swoim IDE rozwoju i na zewnątrz. Naucz się klawiszy skrótu. Naucz się używać myszy mniej. Uważam, że to oszczędza mi dużo czasu.


7

Czy jesteś wolniejszy niż koledzy, czy może twoje szacunki są bardziej optymistyczne?


7

Aby szybciej tworzyć oprogramowanie, odkryłem, że najlepiej jest nauczyć się interfejsu API środowiska wykonawczego najlepiej, jak to możliwe. Nie wpisuj logiki listy, kiedy zadziała rozszerzenie LINQ; nie buduj grupy detektorów zdarzeń, gdy powiązanie będzie działać itp.

Jeśli chodzi o szacunki, pochodzi to z doświadczeniem. Możesz skorzystać z dostępnego oprogramowania do szacowania, które pomoże Ci znaleźć lepsze oszacowania.

Osobiście znalazłem z młodszymi programistami, weźcie cokolwiek ich początkowe oszacowanie i pomnóż to przez 2, a następnie podwoj to. Uwzględni to całą naukę, spotkania, zmarnowany czas itp. Deweloperzy wyższego poziomu mają tendencję do pracy o współczynnik 2 w stosunku do swoich szacunków.

Często pytanie nie brzmi, czy twoje oszacowanie było błędne. Czy to twoje szacunkowe konto na wszystkie właściwe rzeczy? Czy podajesz swoje prognozy i terminy w zakresie nakładów na kodowanie lub czasu kalendarzowego? Pomyśl o tym przez cały dzień i ile to w rzeczywistości, produktywne kodowanie a spotkania, uczenie się, debugowanie itp.


3
„... pomnóż to przez 2, a następnie dwukrotnie.” Ponieważ interesuje Cię oszczędność czasu, mam dla ciebie wskazówkę matematyczną, z której możesz skorzystać ...

LOL - Wiem co mówisz. Będziesz jednak zaskoczony, że często tego nie zauważasz, w przeciwieństwie do powiedzenia „pomnóż przez 4”.

7

Dwie rzeczy, które mogą być dorozumiane, ale nie znalazłem jeszcze wśród odpowiedzi tutaj, które zwiększają wydajność, to:

  • Użyj jakiegoś skryptu kompilacji i wdrożenia. Kompilowanie, wdrażanie, restartowanie serwera aplikacji i takie nie musi pochłaniać ani czasu, ani skupienia, powinno być czymś jednym kliknięciem.

  • Mieć kontrolę wersji. Konieczność kodowania bez możliwości cofnięcia zmiany jest jak chodzenie po jajach


7

Przychodzi mi na myśl kilka pomysłów:

  1. Uzyskaj inne opinie na temat swoich szacunków - Czy są inni programiści, którzy mogliby zapytać coś takiego: „Hej, czy myślisz, że możesz uzyskać tego rodzaju funkcje w tym czasie?” Chodzi o to, że wkład innych osób może pomóc w dokładności w niektórych przypadkach, ponieważ ktoś może zauważyć wiele rzeczy, które przeoczyłeś podczas dokonywania oszacowania.

  2. Doskonal swoje umiejętności szacowania - zacznij śledzić, jak się masz szacunki i dlaczego jesteś nieobecny: czy inne elementy pracy powodują, że terminy nie są dotrzymywane? Czy konsekwentnie nie doceniasz, jak skomplikowane jest coś? Czy podajesz całą oś czasu, gdy jest to niepraktyczne, np. Pytanie jest na tyle niejasne, że samo przygotowanie prototypu zajmie tygodnie, a następnie należy dokonać ponownej oceny tego, co jeszcze należy zrobić? Takie postępowanie może najbardziej pomóc w budowaniu tej umiejętności, więc jeśli powiesz, że zajmie to x godzin, możesz mieć do tego pewność, ponieważ robiłeś to w kółko. Alternatywnym sposobem stwierdzenia tego jest po prostu praktyka, praktyka, praktyka.

To prawda, że ​​prawdopodobnie już je rozważałeś, ale pomyślałem, że warto to powiedzieć innym osobom, które mogły nie wziąć pod uwagę tych pomysłów.


7
  1. Poznaj technologię wewnątrz i na zewnątrz.
  2. Zatrzymać! Myśleć! Iść!
  3. Architekt dla wszystkiego, co może się pojawić, ale wdrażaj tylko to, o co tak naprawdę prosi.
  4. KISS - Keep It Simple Stupid
  5. Jeśli staje się zbyt skomplikowany, prawdopodobnie nie jest dobrze przemyślany. (Wróć do 2 i 4)
  6. Nie utknąć w 5. Często opłaca się zacząć od zera (wróć do 2 i 4)
  7. Wróć do 1.

7

Myślę, że ich kluczowym słowem jest „aktualność”. Nie powiedzieli, że jesteś zbyt wolny, a raczej, że nie byłeś na czas.

W zarządzaniu projektami ważne jest, aby kierownik mógł oszacować, kiedy elementy pracy zostaną wykonane z dokładnością. Podejrzewam, że głównym powodem, dla którego twoje wysiłki nie zostały uznane za terminowe, jest to, że często miałeś przedmioty, które nie zostały dostarczone zgodnie z harmonogramem i zostały dostarczone znacznie później niż zaplanowano.

Aby poprawić terminowość, możesz poświęcić więcej czasu na zrozumienie, ile czasu zajmie ci wykonanie określonego elementu pracy, biorąc pod uwagę twoje umiejętności, doświadczenie i domenę. Pozwoli ci to podać lepsze szacunki swojemu kierownikowi projektu. Kluczem jest tutaj „lepszy” ... możesz dostarczać częściej na czas, wypełniając wszystko kroczkiem, ale tak naprawdę chcesz dążyć do dokładniejszej oceny.

Omówiłbym to ze swoim przełożonym, aby sprawdzić, czy to w rzeczywistości problem. W przeciwnym razie możesz skończyć programować dwa razy szybciej, obiecując rzeczy w połowie czasu, w którym kiedyś to robiłeś, i wciąż krytykujesz się za terminowość, ponieważ twoje prognozy będą nadal miały ten sam współczynnik błędu.


„... Poświęć więcej czasu na zrozumienie, ile czasu zajmie ci wykonanie określonego elementu pracy, biorąc pod uwagę twoje umiejętności, doświadczenie i domenę.” -> Racja, a to również pomoże ci przyciąć zakres i zaoszczędzić jeszcze więcej czasu.
Jim G.

Pomoże również twojemu menedżerowi dobrze wyglądać dla otaczających go osób - pozwala także na uzupełnianie materiałów pomocniczych, takich jak marketing, w synchronizacji z twoim projektem.
Tom leys

7

Bądź stabilny, pozostań stabilny.

Zbuduj coś, co implementuje niewielką część funkcjonalności i upewnij się, że działa od początku do końca. Następnie pracuj dalej, dodając nowe funkcje. Tak, jest to częściowo praktyka TDD, ale ma sens, nawet jeśli nie robisz TDD.

Uzasadnieniem jest to, że za każdym razem widziałem kogoś z 2 tygodni od kodu, który nigdy nie był stabilny, to zawsze trwa kolejne 2 tygodnie, aby dostać to stabilne.

Jeśli pozostaniesz stabilny, usuniesz tę niepewność, a także w razie potrzeby zapewnisz sobie możliwość ograniczenia zasięgu w wyznaczonym terminie.

Oczywistym kontrargumentem jest to, że zrobienie tego zajmie więcej czasu niż napisanie go tylko raz, ponieważ wykonasz dodatkową pracę, stabilizując nie-końcowy kod. Nie kupuję tego przez sekundę. Kiedy masz kod, który działa , zmieniasz 5 wierszy i coś się psuje, wiesz dokładnie, gdzie musiało się to stać.

Jeśli masz 10 000 wierszy kodu, które nigdy nie działały i musisz znaleźć przerwę, masz mnóstwo kodu do przeszukania.

Małe, przyrostowe zmiany w systemie, który jest niezmiennie stabilny FTW. Idź powoli, aby iść szybko.


7

Dla mnie uzyskanie dobrej produktywności to jasny obraz tego, co próbujesz osiągnąć i jak to osiągnąć.


1
Moja 30-minutowa przejażdżka rowerem po Norwegii jest całkiem niezła w oczyszczaniu umysłu i uruchamianiu procesów twórczych.

6

Prawie wszystkie odpowiedzi zostały powiedziane na śmierć w wielu miejscach tutaj i gdzie indziej. A przynajmniej słyszałem to na śmierć. Naucz się swojego IDE, naucz się pisać szybciej, używać frameworków, generowania kodu itp. Tak. Oczywiście te rzeczy pomogą i wątpię, że jest wielu programistów, którzy są mistrzami ich wszystkich. Ale będąc programistą, który zadaje te pytania i odwiedza witryny takie jak Stack Overflow , już o tym wiedziałeś . Czy po prostu chciałeś je tutaj powtórzyć, czy po prostu chciałeś trochę odpowiedzieć?

Ale co, jeśli uda nam się dojść do tego stanu? Mam na myśli opanowanie tych wszystkich sugestii? Co by się wtedy stało? Dobrze. Sądzę, że linie czasu zostaną jeszcze bardziej skrócone. I znowu powrócimy do postrzegania jakości. Chodzi o to, że nasze rzemiosło zdecydowanie się rozwijało i stawało się coraz bardziej produktywne w ciągu dziesięcioleci. Ale czy w tym czasie wzrosła jakość (oczywiście z wyłączeniem bardzo wczesnych lat)?

Moja odpowiedź jest prosta: oprogramowanie wysokiej jakości wymaga czasu ! Możesz handlować tylko jeden za drugim (jakość / szybkość). Ale tak, wszyscy wiemy, że jednak nie jesteśmy uczciwi w kwestii tego, w jakim stopniu ta kompromis często kończy się na końcu skali prędkości. I jesteśmy jeszcze większymi kłamcami na wczesnych etapach projektów!

Mówię, że nie jesteś tutaj winny. Problemem jest postrzeganie , jak długo powinno trwać oprogramowanie wysokiej jakości. Oszukujemy samych siebie, wierząc, że jesteśmy w stanie stworzyć oprogramowanie wysokiej jakości z typami linii czasowych naszych menedżerów, a nawet zgadujemy. Nie produkujemy wysokiej jakości oprogramowania . Piszemy oprogramowanie, które działa, ale czasami z błyskami jakości w niektórych rogach aplikacji.

Co więc możemy z tym zrobić? Nie możemy po prostu przekonać naszych szefów, że musimy podwoić lub potroić inwestycje w każdy z naszych projektów. Mówię dawać przykład. Stwórz naprawdę świetne oprogramowanie jako projekt poboczny. Poświęć na to swój czas i nie idź na kompromis. Przez cały czas zwracaj uwagę na swoje postępy. Zanotuj pozornie niezwiązane zadania, na które musiałeś poświęcić nieoczekiwany czas i sprawdź, czy możesz to uzasadnić. Porównaj to ze wszystkimi innymi projektami, które pracowałeś. Bądź brutalnie szczeryze sobą i wszystkimi aspektami tej analizy. Czy dodatkowe rzeczy, które zrobiłeś ze swoim wysokiej jakości oprogramowaniem, można pominąć w „prawdziwych” projektach w pracy? Ale może twoja próba się nie powiodła. Co było powodem? Znudziło ci się i po prostu spieszyłeś, aby wykonać podstawowe funkcje? Sam jeszcze nie zrobiłem czegoś takiego i dlatego kończę tę myśl z pewnymi wątpliwościami - ale zamierzam spróbować. Będę was informować :).

Wreszcie, myślę, że większość (jeśli nie wszystkie) oceny wydajności są pokręcone i wyjątkowo manipulacyjne. Nie można dusić jakości i prędkości na 100%. Twój szef powinien oceniać cię w stosunku do standardu ustalonego przez organizację. Standard organizacji dotyczący kompromisu między jakością a szybkością. Wyobraźmy sobie, że OrangeSoft Inc. oczekuje 33% jakości i 66% prędkości. Więc jeśli piszesz kod, który może ma jedną trzecią testów jednostkowych, powinien, ale nadrabiając go szybkością i skróconym czasem dostawy, powinieneś uzyskać wynik blisko 100% na swojej recenzji! (Są to dość szorstkie analogie, ale masz rację). Ale zamiast tego dzieje się tak, że Bob pisze kod bardzo szybko, ale notorycznie jest on błędny. Na podstawie swojej oceny wyników zdobędzie 3/5 za jakość i 5/5 za szybkość. Z drugiej strony Carol pisze kod znacznie wolniej, ale powoduje znacznie mniej błędów. Uzyskuje 5/5 za jakość, ale 3/5 za szybkość. Tak czy inaczej Bob i Carol zostają zadokowani na swojej podwyżce. Czy każdy pracownik może uzyskać doskonały wynik? Czy to jest sprawiedliwe?


5

Techniką, której używam, jest ewolucyjne prototypowanie

Możesz znaleźć w Google więcej informacji - ale jeśli potrzebujesz szybko wyprodukować coś, jest to jedyna droga. Plus ma tę zaletę, że kiedy użytkownicy mówią, że mu się to podoba, robisz to (... i możesz zacząć robić dokumentację).

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.