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

144

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.

popiołów999
źródło
4
Czy inni kodują szybciej niż ty przy tej samej jakości? Jeśli nie, wskaż dokumentację utrzymania i raporty błędów, aby wskazać, że prędkość nie stanowi problemu.
Michael K
3
Możliwe duplikaty: programmers.stackexchange.com/questions/55692/…
Corbin March
1
Aby spróbować wygrać wyścig, niektórzy wybiorą swoje najszybsze konie i pokonają je, aby jechać szybciej. Jakieś pytania?
Paul,
24
Nie mam dla ciebie odpowiedzi, ale mam coś, co może sprawić, że poczujesz się lepiej. Bez względu na to, jak powolny jesteś jako programista, jakkolwiek możesz wydawać się nieefektywny, Twój menedżer jest o wiele, znacznie gorszy. Co za idiota mówi: „Hej, Bob, jesteś za wolny”, nie pomagając ci się poprawić? Równie dobrze może ci powiedzieć, że jesteś za niski. To nie jest przywództwo, to tylko cholerstwo. Wydaje mi się, że mam sugestię: znajdź pracę u kompetentnego kierownika, który będzie pracował z tobą w celu przezwyciężenia twoich braków.
Malvolio
1
Wszystkie odpowiedzi sprawiają, że jestem nieszczęśliwy. Jeśli chcesz tylko krok noob-> mierny, to może zrobienie jednej rzeczy jest w porządku. Jednak przeciętny ekspert zawsze musi się wszystkiego nauczyć. Musisz pogłębić swoją wiedzę na temat VCS, edytora, języka programowania i ram. Musisz powtórzyć trudne i interesujące kroki, które możesz wykonać bez zastanowienia. A potem musisz znaleźć sposób na zastosowanie kontekstu, na przykład różnicę między potrzebami klienta a potrzebami współpracownika, jak twój codzienny nastrój wpływa na twoją umiejętność pisania kodu / projektowania / dyskusji. Jeśli chcesz 1, zrób to: naucz się wszystkiego.
erikbwork

Odpowiedzi:

158

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.

Chris
źródło
12
Czy ta analogia nie sugeruje jednak, że garncarze wyprodukowali stos garnek śmieci przed wyprodukowaniem tych wysokiej jakości? Czy możesz to zrobić w profesjonalnym środowisku, z czystym sumieniem? A co z tymi, którzy studiowali i teoretykowali, a następnie wykonali pracę przed upływem terminu?
pdr
4
Nie mam nic przeciwko 20 pojemnikom na śmieci do programowania w hobby. Pomaga mi to również w profesjonalnym doświadczeniu programistycznym; poza tym muszę gdzieś zacząć.
ashes999
23
Po prostu postanowiłem spojrzeć na to pod kątem wartości powierzchni, „praktyka czyni mistrza”. Nie patrz w to zbyt głęboko;)
Chris
6
Nie podoba mi się ta odpowiedź, ponieważ może być zbyt łatwo odebrana w niewłaściwy sposób, tak jak „wyrzucane prototypy” nigdy nie wydają się być wyrzucane.
Rudolf Olah,
2
Dziwi mnie to, że tak wiele osób ma z tym problem. To prawie idealna analogia do iteracyjnego procesu rozwoju. Budujesz coś szybko, aby spełnić wymagania, naprawiasz błędy i refaktoryzujesz, aż będzie to poprawne i wystarczająco dobre. Jeśli nie budujesz oprogramowania w ten sposób, naprawdę musisz go wypróbować. Przeżuwanie i patrzenie w pępek są o wiele mniej skuteczne niż robienie czegoś i pozwalanie ludziom się z tym bić.
JimmyJames
72

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

pdr
źródło
1
To prawdopodobnie duża część problemu. Patrząc z perspektywy czasu, wydaje się to zbyt przypadkowe, że zawsze jestem porównywany do ludzi, którzy pracują w mojej firmie o wiele dłużej niż ja. Hmm ...
ashes999
Jeśli tak jest, radzę zadać dwa pierwsze pytania bezpośrednio i zobaczyć, jaką odpowiedź uzyskasz, stamtąd
pdr
16
jak bardzo to prawda, tak często napotykałem menedżerów, którzy stwierdzili, że jestem niekompetentny, gdy projekty, które produkuję w produkcji, systematycznie generują o jeden lub dwa rzędy mniej zgłoszeń wsparcia niż równoważna praca z innych zespołów. Wielu po prostu nie widzi większego obrazu. Dane pomagają w takim samym stopniu, jak uciążliwe. Zwykle taki menedżer będzie próbował grać w system tak, aby jego statystyki wyglądały dobrze.
Newtopian,
To bardziej komentarz niż odpowiedź. Osobiście zawsze chcę być szybszy i wydajniejszy jako programista, niezależnie od tego, co myślą inni. Na pewno jest wiele do omówienia na ten temat.
Andres Canella,
@AndresCanella Każda odpowiedź w tym pytaniu jest w zasadzie długim komentarzem. Masz rację, jest wiele do omówienia. To naprawdę nie jest dobry format do dyskusji (ani nie jest przeznaczony). Ale to było dobre pytanie na początek, dlatego zostało zamknięte i oznaczone jako Wiki Wiki - za które nikt nie otrzymuje punktów reputacji - zamiast go usunąć.
pdr
39

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/

Rein Henrichs
źródło
Czy możesz zasugerować Google inne witryny / warunki? Myślę, że zmierzenie się z jednym dziwnym wyzwaniem w tygodniu może spowodować, że mój mózg będzie się poruszał w różnych wymiarach.
ashes999
Moim
Rein Henrichs
1
Ta część na samym początku nie ma sensu. Wszystko, co przyspiesza, przyspiesza. Jeśli poświęcisz przynajmniej trochę czasu na pisanie, poprawienie szybkości pisania przyspieszy. Jeśli przynajmniej część czasu spędzasz na oczekiwaniu na komputer, to szybszy komputer sprawi, że będziesz szybszy. Kiedy dążysz do jak najszybszego osiągnięcia ciągłej poprawy, nic nie powinno zostać przeoczone.
still_dreaming_1
12
Małe rzeczy, takie jak pisanie na klawiaturze i szybkość komputera, mają duże znaczenie. Wynika to z nieoczekiwanych efektów ubocznych. Kiedy trzeba czekać na komputer, większość ludzi jest sfrustrowana, a niektórzy nawet rozpraszają się. Połączenie frustracji i rozproszenia jest ogromnym zabójcą produktywności. Coś podobnego dotyczy pisania. Jeśli jesteś szybki w pisaniu, to prawdopodobnie oznacza, że ​​naprawdę dobrze się posługujesz w pisaniu dotykowym i prawdopodobnie nie myślisz zbyt dużo o pisaniu. To uwalnia oczy i mózg, pozwalając skupić się na wykonywanym zadaniu - ogromnym zwiększeniu wydajności.
still_dreaming_1
@INTPnerd Zgadzam się. Jeśli spędzasz czas, zastanawiając się, jak na ekranie pojawia się słowo „rzut” („Muszę tam przesunąć mysz, a następnie kliknąć, a następnie muszę znaleźć literę„ na ”na klawiaturze)), twój mózg również nie ma czasu na rozważ faktyczne decyzje.
erikbwork
25

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

Jens Bannmann
źródło
5
Tak wyciągnąłem z moich wczesnych prac - inni pisali znacznie niższą jakość, kosztem dużej szybkości. To moja pięta achillesowa; Bardzo trudno jest mi napisać zły kod, który, jak wiem, ugryzie mnie później.
ashes999
To łatwy problem do rozwiązania. musisz zmienić środowisko oprogramowania. Musisz pracować w środowisku, w którym prawidłowe wykonanie jest cenione bardziej niż szybkie wykonanie. Tam są miejsca pracy, gdzie ma to znaczenie.
Michael Shaw,
Pracując w środowiskach, w których oba są równie cenione, wśród wszystkich tych, którzy dobrze to robią - ci, którzy szybciej to robią, biją tych, którzy robią to dobrze. I myślę, że jestem w tej drugiej grupie.
ashes999
2
okej, w takim przypadku prawdopodobnie chodzi o strategie, których używasz do pisania, testowania i debugowania kodu. zapytaj, czy możesz sparować program z „szybkim” programistą i zobacz, jak organizują swoje procesy myślowe?
Michael Shaw,
1
@ ashes999: Dzięki praktyce, doświadczeniu i cierpliwości przejdziesz z drugiej grupy do poprzedniej grupy. Nie ma żadnej magicznej pigułki, która przeniesie cię z dnia na dzień.
FrustratedWithFormsDesigner
12

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

Stephen Bailey
źródło
8

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

Buhake Sindi
źródło
Naprawdę mam nadzieję, że to nie jest właściwa odpowiedź; Już spędzam dużo wolnego czasu na kodowaniu i mam nadzieję, że brakuje mi czegoś jeszcze, co da mi znaczącą przewagę.
ashes999
@ ashes999, ok! z kodowaniem w czasie wolnym, czy oceniasz swoją pracę? Chodzi mi o to, że musi być czas na pracę nad optymalizacją kodu i zrozumienie go. Wszyscy możemy kodować, ale ile razy poświęcamy czas na optymalizację?
Buhake Sindi
@TEG Sprawdzam to między projektami; na przykład. jeśli w jakiś sposób zakodowałem coś w projekcie nr 1, w podobnym projekcie nr 2, mógłbym zastanowić się nad wadami projektowymi i dużo przerobić.
ashes999
@ashash - „dużo refaktoryzacji” oznacza, że ​​masz do tego czas, ponieważ początkowy projekt nie był optymalny. Jeśli twój szef nie wie, masz problem z wyjaśnieniem, gdzie minęły godziny. Jeśli szef wie, masz problem z wyjaśnieniem, dlaczego projekt nie został sprawdzony przez doświadczonego współpracownika.
@TRA przepraszam, powinienem był sprecyzować - w projektach hobbystycznych dużo refaktoryzuję. W pracy lekko refaktoryzuję lub tworzę widoczne zadania, aby mój kierownik wiedział, że refaktoryzuję.
ashes999
8

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

użytkownik1249
źródło
8

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.

INTPnerd
źródło
5

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

Christopher Mahan
źródło
3
Testowanie czyni mnie szybszym, a nie wolniejszym. Mniej testów oznacza, że ​​więcej regresji pozostanie niezauważonych na dłużej i będzie trudniejszych do naprawienia, ponieważ nie można wykonać dużych skoków w kodzie z obawy, że „coś może się złamać”.
ashes999
automatyczne testowanie jest dla mnie zapachem kodu. Oznacza to, że kod nie był wystarczająco prosty.
Christopher Mahan
6
Jeśli twój kod jest tak prosty, że nie wymaga testów, nie robi nic interesującego.
Rein Henrichs
Skąd dokładnie to wiesz? Och, zakładając jeszcze raz ... Odniosę się do Reguły modułowości: Napisz proste części połączone czystymi interfejsami. (z The Art of Unix Programming)
Christopher Mahan
Myślę, że możesz coś tam mieć, Christopher. To tutaj ashes99 spędza dużo czasu, np. „Zabijanie”. Zbyt dużo wszystkiego jest złą rzeczą. W takim przypadku, chyba że poprawiasz kod dla systemów sterowania lotem, możesz przemyśleć ilość przeprowadzanych testów. Lub przejdź do tego rodzaju pola.
user21007
5

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.

Bill K.
źródło
3

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

DKnight
źródło
3

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)

Tim Williscroft
źródło
Wiele świetnych punktów tutaj. Potrzebuję bibliotek, ponieważ potrzebuję funkcji dla gry X (np. Pamięci Silverlight w wielu sesjach mojej gry) i mogę powiedzieć, że będą one potrzebne później - lub są to po prostu abstrakcyjny kod (jak wyszukiwanie ścieżki), który nie mam nic wspólnego z moją grą. Mam wykształcenie comp-sci, więc zrobiłem procedury, OO, funkcjonalne i inne (Prolog). Teoria grafów, tak; rekursja pierwszego wykresu głębokości, którego używałem bardzo często, dość dziwnie.
ashes999
3

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.

Nico
źródło
2

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.

mpenrow
źródło
Mam równe szanse z moimi współpracownikami w zakresie tych rzeczy (być może mam przewagę w szybkości pisania); w jakiś sposób są jeszcze szybsze. Może doświadczenie?
ashes999
1
Powyżej pewnego minimalnego minimum „polowania i dziobania” szybkość pisania nie jest czynnikiem ograniczającym.
2
Możesz być na równi z nimi, mając narzędzia (np. Resharper), ale czy wiesz, jak je skutecznie wykorzystywać? Widziałem wiele osób instalujących Resharper, a następnie nie nauczyłem się korzystać z 80% funkcji. W tym przypadku upewnij się, że rozumiesz wszystkie funkcje refaktoryzacji i skróty programu Visual Studio. Dostaję 2-3% lepszą przewagę nad kimkolwiek w moim biurze po prostu przez cały dzień trzymanie klawiatury. Myszy są wolne :)
EZ Hart
@EZ Hart: Bardzo dobra uwaga. Niektóre współczesne IDE (myślę o Eclipse, z góry mojej głowy) mają bardzo potężne narzędzia do refaktoryzacji, wyszukiwania odwołań do kodu (takich jak gdzie jest odwołanie do klasy lub metody, a nie tylko gdzie pojawia się tekst „myMethod” ). W przypadku niektórych z tych „zaawansowanych” funkcji warto poświęcić 5 minut, aby nauczyć się, jak znacznie efektywniej zarządzać bazą kodu.
FrustratedWithFormsDesigner
Wszyscy jesteśmy na poziomie. Nikt z nas nie ma narzędzi :)
ashes999
2

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!

FrustratedWithFormsDesigner
źródło
To nie są osie czasu; inni współpracownicy mogą wykonywać tę samą pracę szybciej. Może to doświadczenie. +1 za szybkość pisania; Mogę wpisać około 100WPM, więc to nie wszystko.
ashes999
@ ashes999: a jeśli ludzie, którzy mogą wykonywać tę samą pracę szybciej, są bardziej doświadczeni, to prawdopodobnie skorzystalibyście najwięcej z większego doświadczenia z danymi systemami. Doświadczenie wymaga czasu ...
FrustratedWithFormsDesigner
generatory kodu to mieszane błogosławieństwo. Mogą zaoszczędzić czas, ale jeśli będziesz musiał spędzać zbyt dużo czasu na wygenerowanym kodzie, oszczędzanie może zmienić się w niemożliwą do zarządzania stratę.
2

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.

9dan
źródło
2

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

Newtopian
źródło
Więc mówisz, że sam siebie profilowałeś? Ciekawy. :)
sum1stolemyname
właściwie to był efekt uboczny metody śledzenia czasu, którą próbowałem przez jakiś czas ( davidseah.com/tools/ett/alpha ). Okazało się kilka interesujących i nieoczekiwanych trendów danych, kiedy zacząłem patrzeć na to poza częścią dotyczącą śledzenia czasu. To jest po tym, jak dowiedziałem się o pomodoro, GTD i tym podobnych.
Newtopian,
0

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.

użytkownik22340
źródło