Jak kodować szybciej (bez poświęcania jakości) [zamknięte]

Od kilku lat jestem profesjonalnym programistą. Komentarze do mojego kodu były zasadniczo takie same: pisze świetny kod, dobrze przetestowany, ale może być szybszy .

Jak więc stać się szybszym programistą bez utraty jakości? Ze względu na to pytanie ograniczę zakres do C #, ponieważ to przede wszystkim to, co koduję (dla zabawy) - lub Java, która jest wystarczająco podobna na wiele sposobów, które mają znaczenie.

Rzeczy, które już robię:

• Napisz minimalne rozwiązanie, które wykona zadanie
• Napisz mnóstwo automatycznych testów (zapobiega regresjom)
• Pisz (i używaj) bibliotek wielokrotnego użytku do wszelkiego rodzaju rzeczy
• Używaj dobrze znanych technologii, w których działają dobrze (np. Hibernacja)
• Używaj wzorów projektowych tam, gdzie pasują do siebie (np. Singleton)

Wszystkie są świetne, ale nie sądzę, że moja prędkość z czasem rośnie. I zrobić ostrożność, ponieważ jeśli mogę coś zrobić, aby zwiększyć swoją wydajność (nawet o 10%), to 10% szybciej niż moi konkurenci. (Nie to, że mam.)

Poza tym konsekwentnie otrzymywałem ten problem od moich menedżerów - niezależnie od tego, czy był to rozwój Flash na małą skalę, czy rozwój Java / C ++ dla przedsiębiorstw.

Edycja: Wydaje się, że jest wiele pytań o to, co rozumiem przez szybki i skąd wiem, że jestem wolny. Pozwól, że wyjaśnię więcej szczegółów.

Pracowałem w małych i średnich zespołach (5-50 osób) w różnych firmach nad różnymi projektami i różnymi technologiami (Flash, ASP.NET, Java, C ++). Obserwacja moich menedżerów (którzy powiedzieli mi bezpośrednio) jest taka, że ​​jestem „wolny”.

Częściowo dzieje się tak dlatego, że znaczna liczba moich rówieśników poświęciła jakość za szybkość; napisali kod, który był błędny, trudny do odczytania, trudny w utrzymaniu i trudny do napisania zautomatyzowanych testów. Mój kod jest ogólnie dobrze udokumentowany, czytelny i testowalny.

W Oracle konsekwentnie rozwiązywałbym błędy wolniej niż inni członkowie zespołu. Wiem o tym, ponieważ otrzymywałbym komentarze na ten temat; oznacza to, że inni (tak, starsi i bardziej doświadczeni) programiści mogliby wykonać moją pracę w krótszym czasie niż to zajęło, przy prawie takiej samej jakości (czytelność, łatwość konserwacji i testowalność).

Dlaczego? czego mi brakuje? Jak mogę być w tym lepszy?

Mój cel końcowy jest prosty: jeśli mogę dziś stworzyć produkt X w 40 godzin i jakoś się ulepszyć, aby móc stworzyć ten sam produkt o 20, 30, a nawet 38 godzinach jutro, właśnie to chcę wiedzieć - jak się tam dostanę? Jakiego procesu mogę użyć do ciągłego doskonalenia? Myślałem, że chodzi o ponowne użycie kodu, ale to chyba nie wystarczy.

Podoba mi się podejście Jeffa Atwooda do tego, które można znaleźć tutaj http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Zasadniczo w artykule odwołuje się do fragmentu książki Art & Fear Davida Baylesa i Teda Orlanda. Fragment brzmi:

Nauczyciel ceramiki ogłosił w dniu otwarcia, że ​​dzieli klasę na dwie grupy. Powiedział, że wszyscy po lewej stronie studia będą oceniani wyłącznie na podstawie ilości wykonanej przez nich pracy, wszyscy po prawej tylko na podstawie jakości. Jego procedura była prosta: w ostatnim dniu zajęć przynosił wagi łazienkowe i ważył pracę grupy „ilościowej”: pięćdziesiąt funtów garnków oznaczonych „A”, czterdzieści funtów „B” i tak dalej. Ci, którzy zostali oceniani na „jakość”, musieli jednak wyprodukować tylko jedną doniczkę - choć idealną - aby uzyskać „A”. Cóż, nadszedł czas oceniania i pojawił się ciekawy fakt: wszystkie prace najwyższej jakości zostały wyprodukowane przez grupę ocenianą pod względem ilości. Wydaje się, że podczas gdy „ilość”

Zasadniczo szybciej brudzisz ręce i częściej poprawiasz swoje umiejętności, zamiast spędzać czas na studiowaniu i teorii na temat „idealnego” sposobu na zrobienie tego. Moja rada, ćwicz dalej, nadążaj za technologią i studiuj projektowanie.

Jedną z możliwości, o której nikt inny nie wspomniał, jest to, że dobrze sobie radzisz, a menedżerowie nie są zbyt dobrzy. Jak mierzą produktywność? Czy mogą dać ci konkretne przykłady, czy to tylko ogólna percepcja? Czy wzięli pod uwagę czas spędzony na naprawianiu pracy innych ludzi w porównaniu do twojej?

Widziałem, jak wielu ludzi zdobywa uznanie za robienie rzeczy, podczas gdy reszta ich zespołu naprawia bałagan, który zostawili za sobą.

Większość tego, co ludzie uważają za ważne, nie jest ważne. Szybkość pisania nie jest ważna. Szybsze maszyny lub narzędzia nie są ważne. Nie jesteśmy maszynistkami ani operatorami maszyn. Uważamy się za pracowników. Jesteśmy decydentami .

Co jest ważne, za pomocą zwrotnej stale ulepszać swój proces decyzyjny. Jedynym sposobem na osiągnięcie tego, podobnie jak zdobycie innych umiejętności, jest doświadczenie, celowa praktyka i ciągłe informacje zwrotne.

• Pracuj przy projektach pobocznych.
• Praca nad projektami typu open source.
• Współpracuj z programistami lepszymi od Ciebie. Program parowania!
• Wystaw się na nowe narzędzia i techniki. Zachowaj to, co działa.
• Wykonuj ćwiczenia programistyczne przeznaczone do szkolenia aparatu decyzyjnego *.
• Monitoruj swoje postępy w oparciu o obiektywne wskaźniki, takie jak częstotliwość i prędkość defektów, oraz subiektywne wskaźniki, takie jak jakość kodu i przydatność.

Wreszcie: pamiętaj, że prędkość bez jakości jest bezużyteczna i odwrotnie. Aby zmaksymalizować użyteczność, znajdź równowagę między tymi napięciami.

* http://codekata.pragprog.com/

Jest całkiem możliwe, że w rzeczywistości jesteś proszony o poświęcenie pewnej jakości dla większej prędkości.

W niektórych środowiskach programistycznych ¹ po prostu nie warto poświęcać dodatkowego czasu na tworzenie czegoś dopracowanego, gdy wystarczy „wystarczająco dobre”.

^{1 - Mam na myśli w szczególności „wewnętrznego narzędzia”, ale prawdopodobnie są też inne.}

Wygląda na to, że robisz wszystkie dobre rzeczy - że w perspektywie średnioterminowej sprawisz, że będziesz szybszy, więc nie jest oczywiste, czy jesteś naprawdę wolny. Tylko ty naprawdę to wiesz. (ale jest to bardzo realna możliwość - PeopleWare twierdzi nawet 10-krotną różnicę produktywności między twórcami tego samego zadania).

Mam dla ciebie kilka sugestii:

1. Czas jest rzeczą względną, więc być może problemem nie jest twoja rzeczywista prędkość, ale raczej postrzeganie czasu, który dajesz. Możesz sugerować, że zajmie to tydzień, ale w końcu spędzisz dwa tygodnie, podczas gdy inni mogą spędzić 3 tygodnie ... ale wyglądasz tylko tydzień wolniej.

2. Ponieważ często otrzymujesz tę opinię, być może czas porozmawiać ze swoim przełożonym i współpracownikami, aby zobaczyć, co mówią - trzeba się od nich wiele nauczyć.

3. Wykonaj kilka par programowania z programistą „szybkiej jakości”, aby zobaczyć, czy zauważysz różnicę.

W rzeczywistości sprowadza się to do doświadczenia . Aby być szybszym w tym, co robisz, to jak jazda samochodem, początkowo boisz się, ponieważ inni są szybkimi (lub pijanymi) kierowcami (lub jednym i drugim) i chcesz bezpiecznie dotrzeć do domu (pod względem oprogramowania, chcesz upewnić się, że Twój kod działa zgodnie z opracowaniem i działa dobrze).

Z biegiem lat / miesięcy, kiedy poznasz zasady jazdy i autostrad, nauczysz się kilku sztuczek, które sprawią, że jazda będzie przyjemnością. Tak nazywamy doświadczenie. Pomagają te „sztuczki” (które nazywam cechami).

W moim przypadku nauczyłem się prawdziwego wykorzystania wzorców projektowych, kodując (nawet @ home) i ucząc się ich zastosowania. Tak więc, gdy napotykam problem, który wymaga wzorca projektowego, wykorzystuję wcześniejsze doświadczenia, aby zobaczyć, które z nich zadziałały i dlaczego miałoby działać / nie działać w mojej sytuacji.

W podsumowaniu:

• Doświadczenie tworzy cechy, które zwiększają pewność siebie i lepsze oprogramowanie.

PS: Doświadczenie pochodzi również z uczenia się od innych. Np. Pomoc SO, programowanie par, recenzje użytkowników itp. Nie możesz mieć doświadczenia, jeśli nie możesz spojrzeć wstecz i uczyć się na błędach (lub jeśli ktoś nigdy nie kwestionuje twojego wysiłku).

Pytanie brzmi, czy jesteś tańszy, patrząc na długoterminowy całkowity koszt.

Innymi słowy, czy twoje starannie spreparowane poprawki błędów są tak wysokiej jakości (w tym przypadki testowe i dokumentacja), że przewyższają koszty utrzymania poprawek przez szybszych współpracowników?

Jeśli tak, musisz poinformować o tym swoich przełożonych. Trudno argumentować, jeśli nie dokonują pomiaru i nie posiadają danych niezbędnych do potwierdzenia oceny.

Jeśli nie, zdecydowanie zastanów się, dlaczego tak jest:

• Czy jesteś zbyt niedoświadczony?
• Czy spędzasz dużo czasu na robieniu rzeczy, o które nie prosiłeś?
• Czy masz trudności z ustaleniem, kiedy poprawka jest zakończona?
• Czy mimo wszystko Twój kod jest gorszej jakości niż myślisz?
• Czy powinieneś podejść do programowania kodu w inny sposób, ponieważ zajmuje Ci to zbyt dużo czasu, aby przyspieszyć sposób, w jaki teraz to robisz?
• Czy spędzasz zbyt dużo czasu na takich rzeczach jak ta strona?

Przemyśl to i edytuj swoje pytanie za pomocą swoich ustaleń.

Wszystkie pytania, czy ludzie naprawdę są powolni, są głupie. Stanie się szybszym programistą bez poświęcania jakości jest zawsze dobrym celem, bez względu na to, jak powolny lub szybki jesteś. To jest mój pierwszy cel jako programista i nigdy nie będę skończony. Zawsze staram się być szybszy bez poświęcania jakości, mam obsesję na tym punkcie. Oto, co do tej pory działało dla mnie w kolejności pomocności, wraz z kilkoma eksperymentalnymi pomysłami na końcu:

1) Nigdy nie przestawaj się uczyć: dowiedz się wszystkiego, co możesz na temat programowania i korzystania z komputerów w ogóle. Znajdź obszary, w których jesteś słaby i naucz się ich. Nawet jeśli wydaje się to całkowicie niezwiązane z twoją pracą i językiem C #, gwarantuję, że jeśli jej szukasz, często znajdziesz sposoby na zastosowanie jej do tego, co robisz. Nauka dotyczy również doświadczenia, więc nie tylko czytaj rzeczy, ale wypróbuj je i poszerz swoje umiejętności. Jeśli jesteś przyzwyczajony do korzystania z systemu Windows, wypróbuj system Unix lub odwrotnie. Jeśli zwykle lubisz korzystać z IDE, wypróbuj narzędzia wiersza poleceń i edytory tekstu lub odwrotnie. Jeśli słyszysz o narzędziu lub technologii, o której wcześniej nie słyszałeś lub o którym niewiele wiesz, nie poddawaj się pokusie, aby przejść dalej. Sprawdź to! Nie bój się myśleć nieszablonowo i uczyć się nowych eksperymentalnych technologii, które według innych są niepraktyczne;

2) Rozbij projekty: Spróbuj rozbić swoje projekty na mini projekty. Staraj się robić nowe wydanie codziennie lub co najwyżej raz na kilka dni. Zadaj sobie pytanie: „Jaką minimalną ilość funkcji mogę wydać, i nadal wydać coś, co jest przydatne dla użytkownika”. Jest to umiejętność, której nauczysz się, robiąc to. Być może będziesz musiał przekonać swoich menedżerów, aby ci to zrobili, ale zwykle będą zadowoleni z wyników dość szybko. W ten sposób zaczniesz zauważać, że rzeczy, które Twoim zdaniem były niezbędne dla Twojej funkcji, są w rzeczywistości dodatkowymi funkcjami, które można później opracować. Pozwala to Tobie i Twoim menedżerom na ustalenie priorytetów tylko najważniejszych funkcji zamiast wszystkich funkcji związanych z tą, nad którą pracujesz. To pozwala myśleć szybciej, utrzymując umysł w czystości i skupieniu. Z kolei programujesz szybciej zgodnie z prawem. Twoi menedżerowie, a przynajmniej menedżerowie menedżera, mogą również zauważyć, że programujesz teraz nawet szybciej niż w rzeczywistości, ponieważ dostajesz więcej wydań. Inną ogromną zaletą tego jest to, że będziesz znacznie lepiej oceniać, ile czasu zajmie ukończenie wydań, a Twoi menedżerowie pokochają cię za to. Ponieważ już przeprowadzasz wiele automatycznych testów, nie powinieneś mieć problemów z częstymi wydaniami, które są stabilne. Może być jednak konieczne udoskonalenie automatycznego systemu kompilacji. Bardzo polecam przeczytanie książki Continuous Delivery z serii Martin Fowler. Jest to trudna lektura, ponieważ jest niezwykle powtarzalna, ale nadal bardzo pomocna. Menedżerowie mogą również zauważyć, że programujesz teraz nawet szybciej niż w rzeczywistości, ponieważ dostajesz więcej wydań. Inną ogromną zaletą tego jest to, że będziesz znacznie lepiej oceniać, ile czasu zajmie ukończenie wydań, a Twoi menedżerowie pokochają cię za to. Ponieważ już przeprowadzasz wiele automatycznych testów, nie powinieneś mieć problemów z częstymi wydaniami, które są stabilne. Może być jednak konieczne udoskonalenie automatycznego systemu kompilacji. Bardzo polecam przeczytanie książki Continuous Delivery z serii Martin Fowler. Jest to trudna lektura, ponieważ jest niezwykle powtarzalna, ale nadal bardzo pomocna. Menedżerowie mogą również zauważyć, że programujesz teraz nawet szybciej niż w rzeczywistości, ponieważ dostajesz więcej wydań. Inną ogromną zaletą tego jest to, że będziesz znacznie lepiej oceniać, ile czasu zajmie ukończenie wydań, a Twoi menedżerowie pokochają cię za to. Ponieważ już przeprowadzasz wiele automatycznych testów, nie powinieneś mieć problemów z częstymi wydaniami, które są stabilne. Może być jednak konieczne udoskonalenie automatycznego systemu kompilacji. Bardzo polecam przeczytanie książki Continuous Delivery z serii Martin Fowler. Jest to trudna lektura, ponieważ jest niezwykle powtarzalna, ale nadal bardzo pomocna. a twoi menedżerowie pokochają cię za to. Ponieważ już przeprowadzasz wiele automatycznych testów, nie powinieneś mieć problemów z częstymi wydaniami, które są stabilne. Może być jednak konieczne udoskonalenie automatycznego systemu kompilacji. Bardzo polecam przeczytanie książki Continuous Delivery z serii Martin Fowler. Jest to trudna lektura, ponieważ jest niezwykle powtarzalna, ale nadal bardzo pomocna. a twoi menedżerowie pokochają cię za to. Ponieważ już przeprowadzasz wiele automatycznych testów, nie powinieneś mieć problemów z częstymi wydaniami, które są stabilne. Może być jednak konieczne udoskonalenie automatycznego systemu kompilacji. Bardzo polecam przeczytanie książki Continuous Delivery z serii Martin Fowler. Jest to trudna lektura, ponieważ jest niezwykle powtarzalna, ale nadal bardzo pomocna.

3) Użyj techniki pomodoro i dostosuj / zmień to, co nie działa dla Ciebie. Jeśli połączysz to z numerem 2 na tej liście, otrzymasz OGROMNY wzrost wydajności.

4) Naucz się Vima. Nawet jeśli skończysz używać tych poleceń w Visual Studio za pośrednictwem ViEmu lub z Eclipse za pośrednictwem wtyczki lub z Emacsa, zwiększysz produktywność. Najlepszym sposobem, aby nauczyć się Vima, jest zacząć go używać i zmusić się, aby nigdy (nie wyłączać go / wracać do starych narzędzi), dopóki go nie opanujesz. Na początku jest to bolesne, ale nigdy nie będziesz chciał się wycofać, a nawet skulić, gdy będziesz musiał bez niego pracować. Niektórzy twierdzą, że nie zwiększy to znacznie prędkości. Ale szybsze jest szybsze, szczególnie gdy czytanie i modyfikowanie kodu jest tym, CO ROBIMY, i okazało się, że oszczędzam przy tym mnóstwo czasu.

5) Ten ostatni niekoniecznie jest zalecany, ponieważ nie jestem pewien, czy to dobry pomysł i może faktycznie zmniejszyć twoją wydajność, ale i tak to zrobię. Możesz spróbować wykonać więcej testów akceptacyjnych i mniej testów jednostkowych, a może przynajmniej upewnij się, że wykonałeś testy akceptacyjne. Miałem sukces z SpecFlow, ale podejrzewam, że jest coś lepszego. Nawet napisanie specyfikacji może być dość techniczne, więc możesz po prostu poprosić swojego menedżera / klienta, aby najpierw napisał wstępną wersję roboczą, którą znacząco zmienisz, lub możesz napisać całą rzecz samodzielnie i po prostu przeczytać i OK. Pomoże ci to z numerem 2 z tej listy. Również testy akceptacyjne mogą być bardziej praktyczne i wymagać mniej kodu niż testy jednostkowe. Nie oznacza to, że zastępują je, różne narzędzia do różnych rzeczy.

6) Ten jest jeszcze bardziej eksperymentalny i kontrowersyjny. Nie zrobiłem tego sam, więc nie mogę tego dokładnie polecić. Naucz się i korzystaj z Meta Programming System od JetBrains. Skorzystaj z niego, aby stworzyć narzędzia, których użyje Twój menedżer / klient, aby samodzielnie stworzyć pożądane oprogramowanie. Możesz nawet przestać przeprowadzać testy jednostkowe i akceptacyjne, jeśli możesz użyć tego do stworzenia narzędzi, których używa twój menedżer / klient, aby określić zachowanie w bardzo prosty i niezbyt skomplikowany sposób. Chodzi o to, aby nie pozbyć się programisty. Programiści nadal musieliby dodawać nowe funkcje do tych narzędzi używanych przez klienta / kierownika, ilekroć (ludzie, a nie narzędzia) nie mogą łatwo stworzyć pożądanej funkcjonalności. Wierzę, że MPS lub inne podobne narzędzia to droga przyszłości.

Używaj więcej mózgu i wykonuj mniej testów. Szczerze mówiąc, testy mają swoje miejsce, ale są drogie.

Przeczytaj także The Art of Unix Programming (bezpłatny online, książka warta swojej ceny)

Wreszcie możesz nie być we właściwym miejscu. Okrągły kołek w kwadratowym zadaniu itp.

Ostatecznie przypomina to szkołę: „Wyjście, czego chce nauczyciel”, staje się „wyjściem, o które kierownictwo prosi i za co płaci”.

Jeśli weźmiesz duży, ukończony projekt i uzyskasz liczbę „końcowych” wierszy kodu na roboczogodzinę, zauważysz, że programiści kodują DUŻO wolniej, niż możesz sobie wyobrazić.

Mówimy tylko kilka linii kodu dziennie. Resztę czasu spędzasz na debugowaniu, przepisywaniu i robieniu ogólnych rzeczy dla programistów.

Być może słyszałeś stare powiedzenie - jeśli złapiesz błąd podczas pisania, zaoszczędzi ci 10 razy więcej czasu, jeśli złapiesz go w czasie kompilacji, co jest 10 razy lepsze niż złapanie go podczas kontroli jakości, co jest 10 razy lepsze niż łapanie go po wydaniu ...

Jak to przyspieszyć? Nie koncentrowałbym się na żadnej formie pisania - redukowanie błędów i poprawianie innych „przyszłych interakcji” z twoim kodem powinno być znacznie lepszą inwestycją twojego czasu.

Czytelny, czytelny kod ma kluczowe znaczenie. Kod piszesz jeden raz, ale będzie on czytany dziesiątki razy. Pisanie pod kątem czytelności pozwoli zaoszczędzić MNIE DUŻO kłopotów (co również zaoszczędzi dużo czasu). Jeśli NIGDY nie wrócisz i nie przeczytasz kodu i nie zastanowisz się przez chwilę, to robisz to źle.

Programowanie w parach może skrócić czas QA, a jeśli weźmiesz pod uwagę, że jeden programista produkuje tylko kilka wierszy dziennie, jeśli dwa mogą kodować z taką samą szybkością jak jeden, ale z mniejszą liczbą błędów, jesteś DROGA.

Kodowanie defensywne (na przykład sprawdzanie parametrów) może zmniejszyć problemy ... Jeśli masz naprawdę dobrego analityka / architekta w zespole, możesz zaoszczędzić trochę czasu dzięki dobremu projektowi początkowemu.

W przeciwnym razie po prostu doskonal swoje umiejętności projektowe. W miarę zdobywania doświadczenia będziesz w stanie lepiej rozpoznawać wzorce, które nie będą działać, i unikając ich, będziesz mógł wcześniej zidentyfikować ograniczenia czasowe itp.

Czy rozważałeś przeprowadzenie szczegółowego audytu siebie podczas pracy? Śledź długopis i papier, jak spędzasz czas, lub użyj czegoś takiego jak Rescue Time, aby śledzić siebie.

Gdy będziesz już bardziej świadomy tego, JAK dokładnie spędzasz czas, możesz lepiej zrozumieć, co wymaga poprawy, i skoncentrować na nim swoje wysiłki.

Idealnie możesz rzucić wyzwanie niektórym współpracownikom, aby to zrobili, porównać swoje wyniki i uzyskać od siebie pomysły. Prawdopodobnie masz mocne strony, z których mogliby skorzystać.

Być może dowiadujesz się, że spędzasz zbyt dużo czasu na części procesu, którą można zautomatyzować lub po prostu masz wiele rozproszeń w ciągu określonej części dnia, a inna część dnia jest spokojna, a następnie możesz zaplanować swoje zadania wokół to itp.

A może odkryjesz, że testowanie zajmuje więcej czasu, niż ci się wydawało, i musisz przemyśleć swoje przekonanie, że przyspiesza.

Jeśli nic więcej nie daje ci punktów odniesienia, z którymi możesz pracować.

Z twojej listy masz się dobrze.

Jeśli Twoi koledzy tworzą kod o wyższym numerze CRAP, będą działać szybciej. CRAP to komicznie nazwana metryka łącząca złożoność cykliczną i zasięg testu.

Nie pisz kodu, który jest bardziej CRAP niż musisz. ;)

Moją jedyną zmianą, którą mogę zaproponować, jest używanie bibliotek, nie pisz ich, chyba że:

1. Twoja firma sprzedaje biblioteki
2. Refaktoryzowałeś cykliczny kod do biblioteki

Czytasz i robisz i to świetnie. Ale możesz utknąć myśląc o kodzie procueduralnym lub OO. Czy naraziłeś się na programowanie funkcjonalne (powiedzmy Haskell?) I Prolog?

Czy chcesz wyostrzyć technikę programowania OO, czy grałeś w Smalltalk / Squeak?

I wreszcie teoria. Czy masz przynajmniej podstawowe zrozumienie teorii grafów? (Niektóre programy działają w pewnym momencie z drzewami, DAG lub zwykłymi wykresami. Sieci są wykresami)

Cytuję wuja Boba :

Jedynym sposobem na szybkie jest pójście dobrze.

Za każdym razem, gdy pokusisz się o zamianę jakości na szybkość, zwalniasz. Każdego razu.

- „Vehement Mediocrity”, Robert C. Martin

O ile wiem to:

1. dobry
2. szybki
3. tani

Jako menedżer możesz wybrać dowolne 2.

Nie martw się o komentarze, które otrzymujesz na bieżąco. Jako inny programista wolałbym zachować dobrze przemyślany i dobrze napisany kod niż coś, co było splatane.

Główne rzeczy, o których mogę myśleć, są następujące

• Zwiększ szybkość pisania.
• Używaj narzędzi zapewniających wzrost wydajności. Na przykład ReSharper.
• Szybsze maszyny lub narzędzia. Jak więcej pamięci RAM lub dysk SSD.

Jestem pewien, że są pewne rzeczy, które możesz zrobić w dziedzinie umiejętności kodowania, ale wygląda na to, że masz podobne rzeczy. Rzeczy wymienione powyżej są zazwyczaj pomijane przez programistów.

Możesz wziąć udział w kursie szybkiego pisania. Nie wiem, czy szybsze pisanie jest problemem, ale „zbyt wolne pisanie” może być spowodowane po prostu małą szybkością pisania.

Co z generatorami kodów? Czasami kod staje się powtarzalny. Refaktoryzacja może usunąć niektóre z nich, ale nawet wtedy możesz mieć powtarzalne wywołania tej samej refaktoryzowanej funkcji. W zależności od danych i kodu, z którym pracujesz, generatory kodu (napisane w Excelu, Perlu, Javie itp.) Mogą zaoszczędzić dużo czasu. Korzystanie z narzędzi do generowania kodu w celu tworzenia interfejsu użytkownika jest zwykle łatwe.

I wreszcie, być może wskaźniki są błędne. Czy zastanawiałeś się, czy kodujesz z możliwie najszybszą szybkością, biorąc pod uwagę wszystko inne, i że terminy są zbyt krótkie, przez co wydajesz się być powolnym programistą?

Na podstawie zmian wprowadzonych w twoim pytaniu wydaje się, że możesz albo obrać drogę niektórych współpracowników i zhakować razem najszybsze rozwiązanie, które zadziała - a dokumentacja i kontrola jakości będą przeklęte!

Lub ... zdobądź więcej doświadczenia i przećwicz w konkretnej dziedzinie, abyś tak dobrze znał bazę kodu i API, abyś mógł kodować rozwiązania we śnie. Można to zrobić, ale wymaga więcej czasu. Jeśli inni deweloperzy, które są szybsze niż znane są bardziej starszy i bardziej doświadczony to istnieje tylko jedna rzecz do zrobienia - Państwo musi stać się bardziej starszy i doświadczony!

Mam sprzeciw wobec poglądu „poświęconej jakości dla szybkości” OP.

Profesjonalni koderzy (programiści) muszą spełniać 3 obiekty:
1) Kod powinien działać zgodnie z przeznaczeniem
2) Dostawa powinna być na czas
3) Mieć dobrą jakość, dokumentację itp.
4) Inne itp.

Myślę, że OP zostało obwinione tak wolno, ponieważ OP nie zrobiło tego na czas.

Jest to haczyk 22, który trudno obejść. Chociaż wciąż możesz nie mieć doświadczenia i pewna wiedza pod wieloma względami jest już szybsza niż większość, trudność polega na tym, że trudniej jest ją zmierzyć .

Osobiście najlepsze, co możesz zrobić w tym momencie, to zmierzyć się. Podziel się swoją opinią o tym, jak pracujesz, być może proste zmiany w nawykach pracy mogą zwiększyć produktywność.

Odkryłem, że maile zjadają o wiele więcej niż myślałem po prostu z powodu przerwy. Teraz odpowiadam na e-maile tylko dwa razy dziennie, a zyskałem prawie 1 godzinę wydajności. Wypróbuj metody takie jak pomodoro , użyłem go jako środka. W regularnych odstępach czasu (15 minut) zapisywałem, co robiłem w tym czasie. To pozwoliło mi zobaczyć, jak zorganizowane były moje dni i co mogłem zrobić, aby zmaksymalizować wydajność.

Przewaga Squeaka w zakresie szybkiego kodowania wykracza daleko poza „doskonalenie umiejętności obsługi komputera”. Jest powód, dla którego nowoczesne GUI, a także IDE, zostały wynalezione na Smalltalk, nie wspominając już, że JUNIT był portem SUNIT na Javę, termin „OOP” został wymyślony, aby opisać Smalltalk itp. Itp.

Zawsze należy używać języka i środowiska najlepiej pasującego do wszystkiego, co się chce osiągnąć, ale w przypadku ogólnego prototypowania przynajmniej dopasowałbym pisk do wszystkiego, z możliwym wyjątkiem HyperCard, a nawet to wymagałoby analizy porównawczej, aby zobaczyć, która była w rzeczywistości szybsze, biorąc pod uwagę, że w Squeak są wbudowane funkcje przypominające karty hipertekstowe.