Jak zostać „szybszym” programistą?

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,

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

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

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.

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

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

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.

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

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.

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!

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

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.

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.

Naucz się pisać jak najszybciej .

I zrobić to jutro .

Getting Things Done jest również ogromnie pomocny.

I tak mam krótki okres uwagi, więc te książki pomagają mi się skupić ... co znowu robiłem?

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

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

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

Emacs

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.

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.

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

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.

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

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.

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.

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.

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.

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

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?

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