it-swarm-eu.dev

Jak se stát "rychlejším" programátorem?

Moje poslední hodnocení práce zahrnovalo pouze jednu slabinu: včasnost. Už vím o některých věcech, které mohu udělat, abych to vylepšil, ale to, co hledám, je víc.

Má někdo tipy nebo rady, co dělá, aby zvýšil rychlost svého výstupu, aniž by obětoval jeho kvalitu?

Jak odhadujete časové osy a dodržujete je? Co děláte, abyste v kratších časových obdobích dosáhli více?

Jakákoli zpětná vazba je velmi oceňována, díky,

142
Nick Gotch

Vypnout počítač. Popadněte tužku a nějaký papír. Načrtněte svůj design. Projděte si to se svými vrstevníky. Pak napište kód.

190
gatorfax

Nějaké nápady ...

  • Vyhněte se pokovování - udělejte pouze to, co se od vás žádá (z hlediska požadavků)
  • Pochopte obchodní požadavky a udělejte to hned poprvé
  • Důkladně pochopte své prostředí a nástroje
  • Staňte se fantastickým pisatelem, místo myši použijte klávesové zkratky
  • Vezměte iterativní přístup a zabudujte do zdravých kontrol, abyste se ujistili, že jste na správné cestě
  • Neotevírejte kolo, zvažte opakované použití minulé práce a práce ostatních
  • Odstraňte rozptýlení, nekontrolujte e-mail, nehledejte venku, nemluvte se spolupracovníky atd.
  • Nepřeceňujte se - rozpoznejte, kdy potřebujete přestávky
149
Mayo

Vaše touha stát se „rychlejším“ programátorem je chvályhodná. Avšak nedodání včas neznamená, že jste pomalí, to znamená, že projekt byl plánován špatně. Být „rychlejším“ programátorem nepomůže; to jen znamená, že budete rychle překonávat termín.

Vy (a váš tým) děláte jednu z následujících chyb (nebo všechny z nich):

  • podceňování práce, kterou je třeba udělat;
  • chybějící velký požadavek nebo kousek architektury během plánování;
  • matoucí pracovní odhady s kalendářními odhady a neúčtování věcí, jako jsou schůzky/telefon/jiné režijní náklady;

Existuje několik způsobů, jak oslovit kteroukoli ze tří výše. Než se však u některého z nich můžete zlepšit, musíte vědět, proč se věci vyvíjejí tak, jak jsou. Proveďte posmrtně odhady posledních dvou nebo tří projektů vs. skutečný čas, který jste získali, a zjistěte, kam šel čas navíc.

Budu to opakovat znovu - pomalé psaní kódu nezpůsobí zmeškání termín, pokud jste to naplánovali správně, abyste tuto skutečnost zohlednili.

132
Franci Penov

Opravdu, opravdu se naučte svého editora. Pokud používáte IDE), ujistěte se, že používáte všechny funkce, které nabízí. Získejte podváděcí list a naučte se klávesové zkratky pro svého editora volby. Pokud používáte Shell set up zkratky pro běžně používané adresáře

89
slashnick

"Má někdo tipy nebo rady ohledně toho, co dělá, aby zvýšil rychlost svého výstupu, aniž by obětoval jeho kvalitu?"

Mnoho lidí usiluje o „konečnou“ kvalitu na úkor něčeho, co je (a) jednoduché, (b) spolehlivé a (c) správné.

Nejdůležitější způsob, jak urychlit vývoj, je zjednodušit to, co děláte, takže je absolutně co nejjednodušší.

Většina lidí, kteří mají problémy s doručováním včas, přináší způsob, příliš mnoho. A důvody jsou často hloupé. Často jsou to jen vnímané požadavky, nikoli skutečné požadavky.

Slyšel jsem, že mnoho lidí mi říká, co zákazník „očekává“. Toto je špatná politika.

Postavte nejjednodušší možnou věc. Pokud zákazník vyžaduje více, budujte více. Nejdříve ale postavte co nejjednodušší věc.

38
S.Lott

Vyvarujte se vyleštění kódu k dokonalosti, jen aby to fungovalo. To firma očekává.

Zvýšení rychlosti však často znamená obětování kvality.

32
user8685

Opětovné použití - Snažím se vytěžit chytré kousky z předchozích projektů, takže je mohu znovu použít v budoucích projektech. Vždy stojí za to se zeptat: „Mohl bych to někdy znovu použít?“

29
Phil Jenkins

Nech to být jednoduché.

Pokud používáte TDD, měli byste následovat „červená, zelená, refaktor“:

  1. Napište neúspěšný test (červený). (Často pro funkčnost váš kód ještě nemá.)
  2. Dopustěte se strašlivých zločinů v kódování, aby vaše testy proběhly (zelená). V případě potřeby pevný kód.
  3. Refaktor, pravděpodobně krátkodobé testy, ale celkově vylepšují design.
24
bryanbcook

Stáhněte si veškerou dokumentaci k vašim jazykům/knihovnám místně do svého počítače a odpojte síťový kabel/vypněte Wi-Fi .

Nesnažím se být vtipný. To mi opravdu pomáhá!

22
mcjabberz

Všimněte si, že příliš dlouho čtete přetečení zásobníku. Omluva „Kompilace“ funguje tak dlouho. :)

20
Matthew Jones

Vyhněte se přepínání úkolů příliš často. Rozptylování a přepínání úkolů může zabít den, i když ke správě svých úkolů používáte nástroje jako Mylyn .

Zjistěte granularitu (např. 30 minut) a pracujte pouze na věcech souvisejících s daným úkolem. Cokoli jiného (nové zprávy o chybách, e-maily o jiných otázkách, procedurální záležitosti, které nesouvisí) se zpožďují alespoň do „dalšího kontrolního bodu“. Nezapomeňte zakázat otevírání e-mailových oznámení, abyste se nezasahovali.

Je to zvláště efektivní, pokud ve svém týmu máte kamaráda, který vám dá vědět, zda se věci opravdu rozplynou a vyžadují vaši okamžitou pozornost.

20
Uri

Udělej to správně, nejlepší způsob, poprvé. Pokud to znamená, že se musíte zastavit a přemýšlet o tom, než začnete, pak to udělejte. Funguje 90% času.

14
ck01
14
AJ Johnson

I dělejte to zítra .

Získání věcí hotovo je také nesmírně užitečné.

Přesto mám krátkou pozornost, takže tyto knihy mi pomáhají udržet mé zaměření ... co jsem dělal znovu?

12
Matthew Jones

Praxe a tvrdá práce.

Musíte vložit čas a úsilí. Jakmile se stanete pohodlnějším a sebevědomějším s jakýmkoli nástrojem, který by vaše používání mělo používat, rychlost a kreativita by měla následovat.

Pokud chcete vylepšit jakoukoli konkrétní dovednost, může to také pomoci navrhnout cvičení, která vám umožní konkrétně na tom pracovat. Pokud je vaše pomalost ve fázi návrhu, zkuste najít problémy s návrhem, na kterých můžete pracovat online. Opakování stejného cvičení vám umožní dokončit jej rychleji a trénovat rychlost. Osobně se mi líbí cvičení s algoritmy TopCoder pro procvičení naprosté rychlosti programování. Mají také konstrukční výzvy, ale já jsem je nezkoušel.

12
DisplacedAussie

Dozvíte se více o zóně, naučíte se, jak se do ní dostat, a naučíte se rozpoznat, když v ní nejste.

Jakmile jsem „v zóně“, jsem nesmírně produktivní a kód ze mě jen vytéká, často dokážu udělat 2 nebo 3 dny kódování za 1 den. Ale shledávám, že je často těžké se tam dostat, zjistím, že se otálím a rozptyluji jiné věci (například přetečení zásobníku).

Citace z what-tricks-do-you-use-to-get-yourself-in-the-zone

11
Dustin Getz

Znát vaše IDE a rámec dobře.) Muset se obrátit na Google za každou maličkost vyžaduje čas.

10
Mike Hall
9
ZeroCool

Než začnete vyvíjet:

  • Odhlaste se ze své poštovní schránky
  • Vypněte všechny IM klienty
  • Zdvořile požádejte vrstevníky, aby vám dali čas na soustředění
  • Samozřejmě, přestaňte surfovat po internetu

Pokaždé, když vás přeruší, zpomalíte, protože vám to zabere nějaký čas, než se jeho myšlenkami vrátíte na cestu. Slyšel jsem čísla, že pro každé přerušení trvá lidská mysl 5-10 minut, než se vrátí zpět k myšlenkovému procesu, který měl před přerušením. S takovým časem na přerušení to nezabírá mnoho času celý den.

Lidé v naší společnosti se ve skutečnosti rozhodli zablokovat čas ve svých kalendářích a poté se každý den přesunout na několik hodin do prázdné konferenční místnosti.

8
dhable

Naučte se svůj vývoj IDE dovnitř a ven. Naučte se klávesové zkratky. Naučte se používat myš méně. Zjistil jsem, že mi to ušetří spoustu času.

7
D3vtr0n

Jste pomalejší než vaši kolegové, nebo jsou vaše odhady přehnanější?

7
pjc50

Pro rychlejší produkci softwaru jsem zjistil, že je nejlepší naučit se runtime API co nejlépe. Nevytvářejte logiku seznamu, když bude fungovat rozšíření LINQ; nestavte spoustu posluchačů událostí, když bude fungovat vazba atd.

Pokud jde o odhad, přichází to se zkušeností. Tam můžete využít software pro odhad, který vám pomůže zjistit lepší odhady.

Osobně jsem našel u vývojářů juniorské úrovně, vezměte si jakýkoli jejich počáteční odhad a vynásobte jej 2, pak jej zdvojnásobte. To bude odpovídat za veškeré učení, schůzky, ztrátu času atd. Větší vývojáři na vyšší úrovni mají tendenci pracovat na faktorech 2 nad svými odhady.

Často není otázkou, zda byl váš odhad nesprávný. Byl to váš odhadovaný účet pro všechny správné věci? Dáváte své odhady a časové limity, pokud jde o úsilí o kódování nebo o kalendářní čas? Přemýšlejte o svém čase a o tom, kolik z toho je skutečné, produktivní kódování vs. schůzky, učení, ladění atd.

7
James Schek

Lze předpokládat dvě věci, ale mezi odpověďmi, které ještě zvyšují produktivitu, jsem ještě neviděl:

  • Použijte nějaký skript pro vytváření a nasazení. Kompilace, rozmístění, restartování aplikačního serveru a takovéto nasávání se ani časem ani soustředěním nemělo stát.

  • Mají nějakou kontrolu nad verzí. Nutnost kódovat, aniž by bylo možné vrátit zpět změnu, je jako snažit se chodit po vejcích

7
Buhb

Přichází na mysl několik nápadů:

  1. Získejte další názory na své odhady - Existují další vývojáři, kteří byste se mohli zeptat na něco jako „Hej, myslíte si, že můžete tento druh funkce udělat v tomto časovém rámci?“ Myšlenka je, že vstup jiných lidí může v některých případech pomoci s přesností, protože si někdo může všimnout spoustu věcí, které jste při odhadu vynechali.

  2. Zdokonalte své dovednosti v odhadech - Začněte sledovat, jak jste na odhadu a proč jste pryč: Nedodržují se jiné pracovní položky způsobující termíny? Trvale podceňujete, jak složité je něco? Dáváte celou časovou osu, když to není praktické, např. to, co je položeno, je dost vágní, že pouhé vzestupu prototypu bude trvat týdny a pak by mělo být přehodnoceno, co dalšího je třeba udělat? To může nejvíce pomoci při budování této dovednosti, takže pokud řeknete, že něco bude trvat x hodiny, můžete mít důvěru v to, protože jste to udělali znovu a znovu. Alternativní způsob, jak to vyjádřit, je pouze praxe, praxe, praxe.

Přiznávám, že jste je již pravděpodobně považovali, ale já jsem si myslel, že by bylo užitečné uvést to pro ty ostatní, kteří tyto myšlenky možná neuvažovali.

7
JB King
  1. Znát technologii dovnitř a ven.
  2. Stop! Myslet si! Jít!
  3. Architekt pro cokoli, co může nastat, ale implementovat pouze to, co je skutečně požadováno.
  4. KISS - Keep It Simple Hloupý
  5. Pokud je to příliš složité, pravděpodobně to není dobře promyšlené. (Vraťte se na 2 a 4)
  6. Nenechte se uvíznout v 5. Často se vyplatí začít od nuly (vraťte se na 2 a 4)
  7. Vraťte se k 1.
7
Rui Craveiro

Myslím, že klíčovým slovem je zde „včasnost“. Neřekli, že jste příliš pomalí, spíše že jste nebyli včasní.

V projektovém řízení je důležité, aby manažer dokázal odhadnout, kdy budou vaše pracovní položky s přesností kompletní. Mám podezření, že hlavním důvodem, proč se vaše úsilí nepovažovalo za aktuální, je to, že jste často měli položky, které nebyly dodány podle plánu, a byly dodány mnohem později, než bylo naplánováno.

Chcete-li zlepšit svou aktuálnost, možná budete chtít strávit více času porozuměním tomu, jak dlouho vám bude trvat, než dokončíte konkrétní pracovní položku vzhledem k vašim dovednostem, zkušenostem a doméně. To vám umožní dát lepší odhady svému vedoucímu projektu. Klíčem je zde „lepší“ ... mohli byste doručit včas častěji tím, že vycpáte vše s faktorem chmýří, ale o co se opravdu chcete usilovat, je přesnější odhad.

Diskutoval bych o tom s vaším manažerem, abych zjistil, zda je to skutečně problém. V opačném případě byste mohli naprogramovat dvakrát tak rychle, slibné věci za polovinu času, než jste zvyklí, a přesto byste byli kritizováni za včasnost, protože vaše odhady budou mít stále stejný faktor chyb.

7
Larry Watanabe

Zůstaňte stabilní, zůstaňte stabilní.

Vytvořte něco, co implementuje malou část funkčnosti, a ujistěte se, že funguje, end-to-end. Poté přidávejte nové kousky funkčnosti, aby to fungovalo. Ano, je to částečně praxe TDD, ale to dává smysl, i když TDD neděláte.

Důvodem je, že pokaždé, když jsem viděl někoho s 2 týdny kódu, který nikdy nebyl stabilní, vždy to trvá další 2 týdny, než get stabilní.

Pokud zůstanete stabilní, odstraníte tuto nejistotu a v případě potřeby si také dáte způsob, jak snížit rozsah blízko termínu.

Zjevným protiargumentem je, že provedení tohoto zabere více času, než jen jeho napsání jednou, protože uděláte více práce, abyste stabilizovali nekonečný kód. To na sekundu nekoupím. Když máte kód, který funguje, změníte 5 řádků a něco se zlomí, víte přesně, kde se zlomit muselo stát.

Pokud máte 10 000 řádků kódu, který nikdy nepracoval, a musíte najít přestávku, musíte prohledat tunu kódu.

Malé, přírůstkové změny v systému, který je trvale stabilní FTW. Jděte pomalu a jděte rychle.

7
kyoryu

Pro mě je získání dobré produktivity jasnou představou o tom, čeho se snažíte dosáhnout a jak se tam dostanete.

7
mdma

Téměř všechny odpovědi byly na mnoha místech tady a jinde vyřčeny. Nebo jsem to alespoň slyšel k smrti. Naučte se své IDE, učte se psát rychleji, používejte rámce, používejte generování kódu atd. Atd. Ano, samozřejmě, tyto věci pomohou a pochybuji, že existuje mnoho programátorů, kteří jsou mistry všech. Ale být typem programátora, který klade tyto otázky a navštěvuje weby, jako je Stack Overflow tyto věci jste už věděli. Chtěli jste je jen opakovat, nebo jste se jen chtěli trochu odvzdušnit?

Ale co kdybychom se dostali do tohoto stavu? Mám na mysli všechny tyto návrhy? Co by se potom stalo? Studna. Hádal bych, že se časové limity ještě zkrátí. A opět se vrátíme k vnímání kvality. Myslím, že naše řemeslo v průběhu desetiletí rozhodně pokročilo a stalo se stále produktivnějším. Zvýšila se však v tomto období kvalita (samozřejmě s výjimkou velmi raných let)?

Moje odpověď je jednoduchá: kvalitní software vyžaduje čas! Můžete obchodovat pouze jeden za druhý (kvalita/rychlost). Ano, všichni víme, že nejsme však upřímní, pokud jde o to, do jaké míry tento kompromis často končí na rychlostním konci stupnice. A jsme ještě větší lháři na začátku projektů!

Říkám , že tady nejste na vině. Problémem je vnímání lidé mají, jak dlouho by měl kvalitní software trvat. Klameme sami sebe v přesvědčení, že jsme schopni vytvořit kvalitní software s typy časových linií, které naši manažeři nebo dokonce odhadujeme. Nevyrábíme kvalitní software. Píšeme software, který funguje, ale někdy s záblesky kvality v určitých rozích aplikace.

Co s tím můžeme dělat? Nemůžeme jen přesvědčit naše šéfy, že musíme zdvojnásobit nebo ztrojnásobit investice do každého z našich projektů. Říkám příkladem. Jako vedlejší projekt vytvořte opravdu skvělý kus softwaru. Vložte do něj svůj vlastní čas a nekompromisně. Po celou dobu věnujte pozornost tomu, jak postupujete. Poznamenejte si zjevně nesouvisející úkoly, do kterých jste museli vložit neočekávané množství času, a zjistěte, zda to můžete zdůvodnit. Kontrastujte to se všemi ostatními projekty, které jste pracovali. Buďte brutálně upřímní se sebou a se všemi aspekty této analýzy. Mohou být v práci „skutečných“ projektů zanedbány další věci, které jste udělali pomocí kvalitního softwaru? Ale možná váš pokus selhal. Jaký byl důvod? Znudili jste se a spěchali jste, abyste dokončili základní funkce? Ještě jsem něco takového sám neudělal, a proto jsem s touto myšlenkou s pochybnostmi skončil - ale hodlám to opravdu udělat. Budu vás zveřejňovat :).

Nakonec si myslím, že většina (pokud ne všechna) hodnocení výkonu je zkroucená a mimořádně manipulativní. Nemůžete omezit kvalitu a rychlost na 100%. Váš šéf by vás měl bodovat podle standardu stanoveného organizací. Standard organizace týkající se kompromisu mezi kvalitou a rychlostí. Představme si, že společnost OrangeSoft Inc. očekává kvalitu 33% a rychlost 66%. Pokud tedy píšete kód, který má možná třetinu testů jednotky, měl by to ale s rychlostí a zkrácenou dodací lhůtou dosáhnout skóre 100% při kontrole! (Jedná se o docela drsné analogie, ale dostanete názor). Ale místo toho se stane, že Bob píše kód extrémně rychle, ale který je notoricky buggy. Takže na jeho recenzi výkonu bude skóre 3/5 za kvalitu a 5/5 za rychlost. Carol naproti tomu píše kód mnohem pomaleji, ale produkuje výrazně méně chyb. Skóre 5/5 za kvalitu, 3/5 za rychlost. Ať tak či onak, Bob a Carol se zakotví na jejich zvýšení. Je možné, aby každý zaměstnanec získal dokonalé skóre? Je to fér?

6
Thiru

Technika, kterou používám, je evoluční prototyping

Můžete google pro více informací - ale pokud je potřeba něco rychle vyrobit, je to jediný způsob, jak jít. Navíc má výhodu, že když uživatelé řeknou, že se mu to líbí, udělal (... a může začít dělat dokumentaci).

5
slashmais

Jaké jsou vaše časová omezení? Zjistil jsem, že myšlení je moje obvyklá překážka, takže zlepšení rychlosti psaní (již dobré) by nepřineslo přibližně nic. Na druhou stranu, pokud pro vás psaní není rychlé a přirozené, může vás to zpomalit.

Snažíte se udělat víc, než je nutné? Podnik obvykle od vás bude chtít hodně dobré práce, než méně, ale více leštěnou práci, a přidání funkcí, které nebudou použity, ztrácí čas a peníze bez návratnosti firmy.

Jsi příliš unáhlený? Lidé pod časovým tlakem často skáčou na předním designu a plánování a doufají, že to stejně dopadne. Často to tak není.

Zvládáte čas správně? Vývoj vyžaduje kousky nepřerušeného času na přemýšlení, jinak budete neefektivní, a proto pomalý.

5
David Thornley

Přečtěte si vynikající knihu Neal Fordové Produktivní programátor .

Je to spousta užitečných tipů.


Upravit:

A jak je uvedeno jinde, přečtěte si dokumenty pro své nástroje. Vždy se učím nové věci pro Vima čtením Vim wiki. Stejně tak pouhé čtení stránky man pro bash nebo zsh vždy dává nové triky k použití.

4
Rob Wells

Před dlouhou dobou jsem četl něco o optimalizaci, která se mnou skutečně přilepila. Nepamatuji si zdroj ani přesná slova, ale podstatou toho bylo: „Jediným způsobem, jak zrychlit běh programu, je snížit jeho výkon. Totéž platí pro lidi. Armáda také říká: „Haste dělá plýtvání.“ Totéž, co děláme nyní, ale rychleji, způsobí pouze problémy. Existuje mnoho různých plánů, jak se stát produktivnějšími, a neříkám, že nejsou účinné, ale nebudou přizpůsobeny vašim potřebám. Raději byste se měli dívat na to, co děláte, a najít věci, které děláte, které nejsou produktivní, a vyřezávat je. Jakýkoli jiný plán je jen jeho oslabenou verzí.

4
Imagist

Tady je to, co pro mě funguje:

  1. Rozdělte svou práci na malé úkoly, které jsou (1) definované v rozsahu (2) krátké - např. 2 hodiny.
  2. Začněte den tak, že si je zapíšete na papír v pořádku. Nakreslete některé řádky - věci, u nichž se očekává, že budete hotové před obědem, věci, které budete hotovi do konce dne atd.
  3. Vypracujte si seznam a křížte položky.
  4. Věci s časovým rámečkem - pokud se něco začíná přetahovat, dejte si časový limit na výzkum, než požádáte o pomoc, nebo jej vyřešte jednodušším způsobem.
  5. Pokud je to možné, strukturujte svou práci tak, abyste se veřejně zavázali k těmto časovým rámcům - zadávání odhadů do sledování chyb atd.
  6. Pokud chytíte zabíjení času zkoumání, čtení, atd., Pak invertujte objednávku - například, nechte si odměnu 10 minut, pokud úspěšně dokončíte 1 hodinu úkolu podle plánu.

Viděl jsem několik komentářů, že byste měli strávit méně času na Stack Overflow. Pokud ji používáte správně, Stack Overflow by vás měl zefektivnit, ne méně. Vyhýbejte se diskusím a soustřeďte se na to, abyste mohli práci udělat.

3
Jon Galloway

Neopakujte se

Opětovné použití aktiv starých projektů.

Udělejte si den, abyste se naučili své IDE. Pokud neposkytuje nástroje, jako jsou úryvky, automatické dokončení kódu ... zvažte získání nového.

Vložte zkratky ke všem na klíčových místech, abyste měli přístup k věcem rychleji.

Získejte druhou obrazovku, pokud tomu tak již není.

Nekontrolujte své e-maily příliš často.

Zkuste se soustředit pouze na jeden úkol najednou. Pokud to není možné, pozorně sledujte, co děláte, a neztratíte se mezi 15 nesouvisejícími úkoly.

Použijte papír. Když pracuji, mám vždy tištěnou verzi svých úkolů, na které si mohu dělat poznámky, křížky atd. Je to mnohem rychlejší, než jít na jinou obrazovku, něco číst nebo něco napsat. Na konci dne si zkopíruji vše do systému 10 minut. Uvědomil jsem si, že mi to každý den ušetřilo čas.

3
marcgg
  1. Rozvíjejte se stále více a více jako programátor, každý den ... Naučte se designové vzory!
  2. Použijte TDD, ale správným způsobem, chyby, které můžete mít v kódu, jsou časově nejnáročnější.
  3. Použijte ReSharper :)
3
Denis Biondic

Vzhledem k tomu, že mnoho dalších odpovědí hovoří o vytváření návrhů, rychleji se držím čistě mechanického aspektu kódování. Většina z toho je pravděpodobně zřejmá, ale stejně to řeknu, protože si všimnu, že mnoho z mých spolupracovníků některé z těchto věcí nedělá.

Přeměňte své klávesové zkratky IDE), abyste je mohli udělat většinu z nich levou rukou. Tím se uvolní vaše ruka pro rychlé a zběsilé načtení/refaktorování kódu.

Naučte se, jak navigovat kurzorem a vybírat text pomocí kombinace CtrlShift, šipky, Home a End.

Níže je moje nastavení C++ (Visual Studio s Visual Assist X). Mám norskou klávesnici, prosím mějte se mnou:

Alt-Z: Změna mezi .h a .cpp

Ctrl-Shift- <: Kontextově citlivý skok přes odkazy. (<pro mě je klíč vlevo od Z, vy angličtí kluci nemáte žádnou z nich. Mapujte ji na Ctrl-Shift-Z.)

Alt- | : Metoda implementace. Nejprve zapíšete záhlaví a stisknete Alt- | po celou dobu můžete vytvořit obrys třídy během několika sekund. (Pro mě je klíč pod únikem.) To platí zejména, pokud umístíte soubory cpp a záhlaví vedle sebe do textového editoru tak, aby záhlaví nefungovalo Nezakrývám se pokaždé, když provedete akci.

Alt-R: Přejmenuje symbol pod mým zástupcem.

Alt-D: Přidá šablonu dokumentace pro vybranou funkci.

To umožňuje kromě rychlého doplnění kódu bleskem také možnost refaktoringu levou rukou.

3
Nailer

Útržky kódu, zkušenosti a nikdy nekončící nadšení. Vždy číst věci: blogy programátorů, knihy, literatura, špatný kód jiných lidí. Získáte rychleji, pokud získáte širší pohled na věci. Pokud si dokážete představit všechny možné složité procesy na pozadí a opravdu znáte celou komplexnost cílového systému.

Příručka Pragmatického programátora je docela úžasné: jde o osvědčené postupy a hlavní úskalí mnoha různých aspektů vývoje softwaru. Gumové káčátko a věci zní bezostyšně hloupě a hloupě. Podstatou většiny problémů s programováním je však to, že máme tendenci myslet příliš složitě. Jsem velkým fanouškem jednoduchých a snadných řešení: žádné skvělé triky, žádné super-elegantní hacky: používám nejjednodušší řešení.

Pokud je váš tým dobrý, můžete se pokusit spolupracovat: Bespin a některé další rámce dnes umožňují editaci jednoho souboru společně. To je úžasné, pokud se do toho opravdu zapojíte a uvidíte, jak váš kouzelník dělá kouzlo;).

3
wishi

Zkuste zkontrolovat e-maily s delšími intervaly a přestat používat online sociální nástroje, jako je Twitter, Facebook atd.

Použijte tapeta .

Zkuste pracovat s otevřeným čelním pohledem. Obvykle používám konferenční místnost, když je zdarma, pomáhá mi to soustředit se!

Zkuste spolupracovat s ostatními programátory ve vašem okolí.

3
Adnan Memon

Trikem není psát kód rychleji, ale psát pracovní kód rychleji.

Čím dříve je na místě chyba, tím menší úsilí je napravit - to je primární věc, která ovlivňuje výkon programátoru.

Nejde o to, jak rychle píšete, nebo jak rychle je váš kompilátor, ale o rychlost, s jakou můžete identifikovat chyby a opravit je v průběhu cesty.

Proto bych navrhl párové programování jako způsob, jak být rychlejší - opravdu se vyhýbá chybám. To a testem řízený vývoj. Mít dva páry očí způsobuje, že chyby mohou proklouznout více než dvakrát (myslím stejně).

Další tipy by byly

  • Pokuste se zkrátit dobu potřebnou k provedení testu na minimum - to samozřejmě závisí na vaší platformě a nástrojích. Pokud pracujete na hloupém vestavěném systému s chromými nástroji, může být doba obratu značná (například pokud potřebujete znovu vytvořit bitovou kopii systému a restartovat zařízení), mohou vám pomoci VM nebo simulátory.
  • Pokud ne spárujte programování, občas požádejte ostatní o neformální kontrolu kódu, ale pouze při logických přestávkách ve vašem (a snad i jejich) toku. Udělejte to kromě vašeho formálního procesu kontroly kódu, který bezpochyby máte.
  • Zachovejte to jednoduše - nepřekonávejte technika. Nebudete to potřebovat.
3
MarkR

Napište vlastní nástroje pro produktivitu. Psaní může chvíli trvat, ale výplata může být časem velká.

Některé nástroje, které jsem napsal, které používám neustále:

  • Formátovač SQL.
  • Automatický generátor SQL: stačí vybrat tabulky.
  • Jednoduchý prioritizér úkolů, takže vidím všechny své úkoly najednou.
  • Připomenutí úkolu, který mě pravidelně obtěžuje.
  • Aplikace, která bere ohraničený text a umožňuje vám s ním zacházet jako s tabulkou a jako s textem.
  • Formátovač stránky PHP/Javascript/HTML. Godsend při práci s kódem druhých.

Ve své době jsem napsal spoustu dalších drobných nástrojů, které upadly, ale stálo to za to.

3
Jonathan Swift
  1. Během programování mě opravdu baví poslouchat hudbu, protože se cítím, jako by mě to uvolnilo a já se mohu soustředit.

  2. Pohodlná židle. Nikdy nepoužívám počítačové učebny své školy k programování, protože kancelářské židle jsou neuvěřitelně nepříjemné.

  3. Jíst něco předem, protože nic nezabije moji motivaci, jako je otravný hlad.

3
Matt Phillips

Praxe. To, a dostat své ruce na nástroje produktivity, které vám umožní jít rychleji.

Například (nezmínili jste platformu, na které pracujete), v prostředí .NET je Resharper.

2
Randolph West

Znovu projednat odhady a časové harmonogramy. Ujistěte se, že vy jste ten, kdo říká, jak dlouho něco bude trvat, a nepodlehneme žádnému „dobře, potřebujeme to udělat dříve“ nebo „jak se jedná o návrhy zaměřené na úsek“.

Přečtěte si článek Joela Spolského o odhadech, který v zásadě obhajuje rozdělení práce na malé kousky a každý odhaduje. Pokud se některý z nich počítá ve dnech, rozdělte je dále, dokud nebudete mít vše odhadnuté v hodinách.

2
harriyott

Vy a váš šéf/hodnotitel musíte určit, kolik času skutečně musíte naprogramovat. Vyjměte schůzky, e-maily, dokumentaci, testování a další přerušení od doby, kdy se očekává, že budete pracovat, a podívejte se, co zbylo.

Zkuste sledovat svůj čas a získat měřítko toho, jak dlouho některé úkoly trvají. Budou produktivní časy (pro mě brzy v den nebo jakýkoli časový úsek, kdy se dostanu do práce bez přestávek) a neproduktivní časy. Najděte průměr.

Můžete určit, že daný úkol zabere 8 hodin, ale pochybuji, že to zvládnete za jeden den.

Také bych se pokusil porovnat sebe s ostatními. Firemní kultura může být věnována spoustu hodin.

2
JeffO

No, myslím, že nejsem pomalý, ale práce, kterou dostanu, má tendenci zaplňovat dostupný čas.

Bez ohledu na to často slyším „Gee, udělal jsi to rychle“, ale nejde o rychlý kodér, ale o méně kódování.

Myslím, že hlavní způsob, jak kód méně, je myslet jako DSL. Pokud nemůžete získat kód vygenerovaný preprocesorem, napište generátor kódu. Nemusí to být fantazie. Cílem je, pokud máte jeden samostatný požadavek, minimalizovat počet zdrojových kódových rozdílů potřebných k implementaci tohoto požadavku. V ideálním případě je toto číslo 1. Pokud je můžete snížit v průměru kolem 3-6, je to docela dobré. (Nejde jen o to, že píšete méně. Čím menší je toto číslo, tím menší je počet chyb, které vkládáte, a že opravdu šetří čas.)

Chcete-li to provést, doporučujeme provést ladění výkon , protože pak zjistíte, jaké postupy kódování vedou k největším zpomalením a také vedou k nadýmání kódu. Zejména nadměrná struktura dat a programování ve stylu událostí/oznámení. Tyto věci samy masivně přispívají k objemu kódu.

Mnoho objemu kódu v těchto dnech je způsobeno uživatelským rozhraním, zejména pokud je dynamicky flexibilní. Narazil jsem na způsob, jak tuto část nazvat Dynamic Dialogs , která má tvrdou křivku učení, ale zmenšuje UI kód ​​zhruba o řád.

Obávám se, že v tom budete muset najít svou vlastní cestu, ale hodně štěstí.

2
Mike Dunlavey

Udržujte svůj osobní život v pořádku. Získejte spoustu spánku, jíst zdravě a brát vitamíny - zejména pokud máte nedostatek železa. Drž se dál od "pití" - pokud víte, co tím myslím. A pamatujte si: „Víno i ženy mohou vést moudrého muže na scestí.“

Vytvořte také šablony kódu a „generátor kódu“, který pracuje s použitím vzorů regulárních výrazů. POKUD zjistíte, že kopírujete a vkládáte, poté vyhledáváte a nahrazujete podobné třídy, tento proces automatizujte. Udělal jsem to pro své projekty PHP=, ve kterých mohu vytvořit aplikaci CRUD, kompletní se všemi základními komponentami MVC, založenými na mých tabulkách dat - všechny datové modely vypadají stejně, s výjimkou datové tabulky, které představují, takže se jedná o nastavení v šablonách a slouží k vygenerování mého původního kódu. Šetří hodiny psaní.

Nakonec řekněte všem lidem zapojeným do projektu, že kód bude trvat 1/4 až 1/2 krát déle, než si myslíte. Brzy na sebe sjednejte více dechové místnosti. „Pozdní“ je relativní pojem. Dojde-li ke změnám v projektu, uprostřed proudu, dejte všem dopředu vědět, že bylo přidáno dalších 8 hodin práce. Sledovací systém, jako je například systém nabízený v programu „FogBugz“, může být pro vás a manažery užitečné předvídat, jak dlouho bude trvat, než se něco udělá, na základě předchozích zkušeností. Snažím se využít taktiku: „Nebylo pozdě - využil jsem dostatečné množství času k dokončení této funkce - trvalo jen déle, než jsme čekali.“

Jiný programátor může říci: „No, mohl jsem to udělat rychleji ...“ Možná, možná ne, to není důvod, který by stálo za to diskutovat nebo porazit sami sebe - vždycky bude nějaký „chytrý“ chlap, který se snaží stisknout toto tlačítko. Pokud vás nad tím zamyslí, zpomalí vás! Je to vždy špatná situace, když je to váš šéf. V tom okamžiku bych uvažoval o hledání jiné práce, protože takový šéf je v mé knize arogantní JERK.

2
JasonMichael

Otázka: Co uděláte, abyste v kratších časových obdobích udělali více?

Odpověď: Každý den přicházejte do kanceláře a pište, co všeho byste chtěli dokončit v poznámkách aplikace Outlook. Začněte pracovat na tomto pořadí položek. Věřte mi na konci dne, kdy byste cítili, že jste udělali to, co jste plánovali, a to je skvělý pocit.

2
Cshah

Párový program - to má všechny výhody:

  • vás nutí vyjádřit/vyjasnit své myšlení
  • vám umožní nahlédnout do toho, jak někdo pracuje, mnoho nápadů, které můžete přijmout/vyzkoušet
  • učit se nové technologie přímo od někoho jiného, ​​kdo je zná
  • vyzvedněte si několik tipů na zvýšení produktivity od ostatních. Vždy vidíte, jak někdo používá příkaz nabídky, kterému jste dříve nerozuměli, nebo nějaký užitečný příkaz Unix.
2
ndp

Napište méně kódu.

Zakažte zde neobjevený vynález a dobře využijte existujících knihoven/frameworků/nástrojů k zajištění běžných (a obecně nedefinujících) funkcí, takže stačí jen napsat, co je nového. Pro části, které potřebujete napsat sami, je sestavte s ohledem na opakované použití, abyste je nemuseli psát znovu pro další projekt.

I když nezvýšíte počet řádků pracovního kódu, které denně vytvoříte, můžete udělat více za méně času tím, že každý řádek uděláte více.

2
Dave Sherohman

Jedinou jasnou věcí, kterou jsem zjistil, je, že díla jsou bez rozptýlení. Což je v některých prostředích nemožné. Ale schopnost soustředit se na konkrétní úkol a POUZE na tento úkol pravděpodobně převáží nad čímkoli jiným. Tyto kontextové přepínače jsou opravdu velké časové potopy.

2
Joe

Žonglování při přestávce

Juggling

2
Cornelius

Pití Yerba Mate místo kávy

Yerba Mate

2
Cornelius

Je to vždy stejné rozhodnutí, rychlý vývoj vs. kvalita, čitelnost, rozšiřitelnost. Přetáhněte ovládací prvky a nekonečné soubory kódového pozadí (rychlé a špinavé) nebo modularitu, vzorce a postupy (dlouhodobá investice)?

Podle mého názoru musí každý investovat do dlouhodobého způsobu kódování. Jak plyne čas, rychlý vývoj bude také velmi kvalitní.

Nicméně v případě, že jsem nerozuměl vašemu dotazu a vy hledáte odpovědi z hlediska praktických aspektů rychlého vývoje, jako jsou nástroje, generátory kódu a další věci, můj názor je začít používat sdílení a učit se co nejvíce o vašich = IDE :)

1
Aggelos Biboudis

POUŽÍVEJTE RÁMCE !! Neobtěžujte se tvrdým kódováním!

1
Koosha

Nejprve byste neměli navrhovat systém založený na několika setkáních s koncovými uživateli. Ve skutečnosti byste neměli být zapojeni do fáze požadavků projektu, to je pro obchodní analytiky a konečné uživatele.

Druhou fází by měly být vaše technické požadavky, zde začnete spolupracovat s obchodními analytiky na řešení požadované specifikace.

Nyní je důležitá část. Ujistěte se, že rozumíte jak požadavkům koncového uživatele, tak funkčním požadavkům. Nemá smysl, abyste začínali jen proto, abyste zjistili, že nesplňuje očekávání uživatelů. Pokud něco nerozumíte, promluvte.

Nyní je čas zasáhnout editora. Ale můj přístup je nikdy psát skutečný kód, vždy psát absolutní hromadu komentářů první, udělejte to v pseudo kódu, pokud je to pro vás snadné, ať už na tom nezáleží, pokud je to jasné a snadno čitelné/pochopitelné.

Jakmile zadáte své připomínky, můžete začít buď a) psát své testovací případy b) psát implementaci.

V závislosti na vašem prostředí by bylo nejlepší začít s (a), ale bohužel nejvíce začít s (b) a pak zkuste vynutit testy, aby splnily implementaci. Upřímně řečeno, kdybyste byli součástí velké společnosti, bylo by pro vás oddělení, které by vám psalo testovací případy, ještě než začnete něco dělat.

1
Brett Ryan

Všichni říkají „kontrola e-mailu“, ale zvažte čas, který věnujete psaní vysoce technického e-mailu. Mohu snadno strávit hodinu psaní jediného e-mailu. Abych to vyřešil, mohl bych buď 1) nepsat tolik, nebo 2) odložit technické věci (a věci, které vyžadují, abych četl kód, abych odpověděl), dokud to není absolutně nutné.

1
Shin

Když vlastně píšete kód, CodeRush pomáhá trochu, zvláště když jste zvládli jeho zkratky. Navíc je to zdarma: D

1
GaiusSensei

Každý týden trávím trochu času hledáním nových kreativních způsobů, jak dělat věci, které mohou nebo nemusí přímo souviset s tím, na čem v současné době pracuji. Často najdu nové triky nebo nástroje, o kterých jsem nikdy nevěděl, že to zrychlí můj pracovní postup.

1
fscmj

Důvěrně se seznamte s vaším IDE.

Pokud vaše IDE je Visual Studio, pak vřele doporučuji kniha Sary Fordové .

1
Jim G.
  • učit se návrhové vzory. Pomáhají vám porozumět problémům, učiní vás lepším programátorem -> vám umožní programovat mnohem rychleji, protože již máte řešení pro několik problémů připravených na paměti
  • extrahovat opakující se části ve vašem programu. Pokud existuje logika, která se opakuje v několika programech, které píšete, zvažte jejich zobecnění a rozbalení do nějaké knihovny tříd, kterou pak můžete znovu použít pro nové aplikace, které píšete. Standardizovat Věci: investujte nějaký čas do zjišťování, jak jsou určité opakující se úkoly prováděny nejlépe. Zdokumentujte kroky k dosažení. Až příště budete přesně vědět, jak je vyřešit/aplikovat.
  • Princip KISS
  • Generování kódu bude užitečné (jakmile bude k dispozici užitečný nástroj). Generátory začaly v poslední době získávat popularitu.

Poznámka: Jen to, že věci fungují, je horší !! Jak někteří zmínili jen o hackování ve věcech, dokud nepracují, zrychlí vás momentálně. Chyby však přijdou, které se však nějak počítají také z hlediska toho, jak rychle programujete. Pokud musím napsat nějakou funkci a investovat do jejího psaní, mám dobrý design, možná dobře otestovaný (pomocí Unit testů) a řeknu, že budu potřebovat půl dne. Ale předpokládejme, že to bylo a vaše funkce funguje a nemusíte se jí znovu dotýkat. Jiný programátor, jen se zaměřil na rychlé dosažení svého cíle, bude (možná) špatným designem kvůli chybějícímu testování, které nebude brát v úvahu (být si vědom) hraničních výjimečných případů. Bude potřebovat 2 hodiny (řekněme). Chyby přijdou, bude se muset znovu dotknout kódu, opravit jej, případně prodloužit (hodiny budou znovu investovány). Kód bude těžké udržet atd. Resumé: na konci stráví hodně času rudy a frustrace bude vyšší.

1
Juri

Použijte ergonomicky optimalizované rozložení klávesnice . Některé jsou dokonce zaměřeny na programátory prostřednictvím velmi dostupných speciálních znaků.

1
knittl

Práce z domova. Když mám tvrdý termín a musím se plně soustředit na problém, řeknu svému šéfovi, že pracuji z domova. To mi umožňuje optimálně nastavit prostředí, omezit přerušení a soustředit se na problém jako laserový paprsek.

1
Pedro Estrada

Získáte rychlejší zážitek a zapamatujete si API mnohem více.

Moje dny hledání fragmentů kódu na webu jsou nyní mnohem kratší, když jsem se naučil lépe kódovat.

Oh, možná budete také chtít zkusit použít funkční koncepty programování a Lamda pro snížení kódu :)

1
Vince

Být nadšený z toho, co děláte, je skvělý způsob, jak zvýšit účinnost. Ujistěte se, že je to zábava!

1
Jakob

Myslím, že načrtnutí vašeho nápadu na papíře, pamatujte na ty věci, je skvělý způsob, jak vylepšit některé nápady. Jako programátoři, ať už profesionálové nebo fandové, trávíme soooo tolik času zíráním na obrazovku, že mít jinou zásuvku, na které můžete své nápady vložit, je dobré. Zjistil jsem, že škrábání věcí, nakreslení unáhlených čar spojujících myšlenky, kroužení věcí, podtržení atd. To vše přispívá k důrazu na nápad a může vám opravdu pomoci vyřešit problém mnohem rychleji, než když se ho pokusíte strukturovat hned na netopýru nebo v nějaká forma podporovaná počítačem.

Další věcí, která pomáhá, je prototypování malých dílů. Poslouchali TED audio podcast včera, kde řečník diskutoval o stavbě malých struktur z špagetových tyčinek a Marshmallowe, očividně se jedná o velmi široce používanou studii, která otestuje sociální konstrukční schopnosti malých skupin ... každopádně skupiny, které vždy dělaly lepší, kromě architektů, kteří chápali posilování a stavbu budov, byly děti, protože k dosažení výsledků použili proud neustálé zpětné vazby. Myslím, že to můžete také hodit do programovací myšlenky, kde vidíte, že dělat malé věci a dosahovat výsledků není jen produktivnější, ale mnohem zábavnější a užitečnější než budování obřích konstrukcí a pak strávit dny debugováním ... to je zabito Určitě některé z mých „zábavných“ nápadů v minulosti.

1
dscher

Když jsem v kanceláři a potřebuji se soustředit, zavřu svého e-mailového klienta. Nic mi nezničí efektivitu rychleji než neustálé pokušení „rychle se podívat“ na jakoukoli zprávu, která právě dorazila. Také jsem si pohrával s Pomodoro Technique pro zvládnutí narušení a udržení zaměření.

1
Tim Trout

Používejte generátory kódu, kdykoli je to možné. Někdy se aplikace Microsoft Excel (nebo OpenOffice Calc) ukáže jako výkonný nástroj pro generování kódu.

0
Canavar

Jednoduše řečeno, bílá tabule -> rozdělte se na testovatelné požadavky na úkoly (použil jsem Team Foundation , abych sledoval každý úkol a jak dlouho by to mělo trvat).

Pomocí testování zajistěte, abyste dosáhli toho, co je požadováno, nic víc, nic méně. (Ještě si nedělejte starosti s výkonem.)

Přejděte od požadavku k požadavku a testujte po dokončení každého. Po dokončení každého úkolu byste měli mít přesný odhad zbývajícího času.

Když jsou splněny všechny požadavky, vraťte se a „vyleštěte“.

Práce nohou nejprve nutí člověka, aby vyžehlil všechny požadavky, které šetří čas tím, že dělají věci hned při prvním.

Pokud se to udělá správně, mělo by to poskytnout více času na trávení zásobníku přetečení :)

Hodně štěstí

0
Brad8118

Je zde spousta skvělých nápadů. Abych se dostal do „zóny“, používám časovač nastavený na 27minutové intervaly. Zjistil jsem, že jakmile jsem v pracovním režimu, je snadné pracovat dobře za bzučákem a práce s tokem je bezbolestná. Dostat se tam je těžké.

0
Daver

Jediná věc, kterou jsem si všiml, ovlivňující moji rychlost nejvíce, je motivace a zábava. To se může zdát Fuzzy, ale když jsem motivovaný a dělám něco, co mi připadá zábavné, mohu být velmi efektivní. Na druhou stranu, když nejsem ani to, jak se cítím, jako bych ze mě musel vytlačit každý řádek kódu.

Najděte svá sladká místa, co vás skutečně motivuje a jaké úkoly opravdu děláte? A můžete ovlivnit své plánování, abyste to mohli udělat? Pro mě je to, když se dostanu k řešení problémů a návrhových problémů, a když mám pocit, že mám část projektu.

Před několika měsíci jsme měli malý projekt, ke kterému byl náš malý tým přidělen, a byl to opravdu důležitý a velmi nerealistický termín. Všichni jsme však byli velmi motivovaní a bavili jsme se a dělali to včas, se spokojeným zákazníkem. Důvodem mé motivace bylo, že jsme se do projektu velmi zapojili a museli pro něj přijít s kreativními nápady. Také jsem musel dělat části, které mě opravdu baví.

Nedávno jsem se však zapojil do projektu, kde jsem v podstatě kódová opice, jen dělám znecitlivující a frustrující úkoly, nebo jen rychleji opravující věci nejrychlejším možným způsobem, o kterém vím, že se vrací a někdy mě kousne tvrdě v blízké budoucnosti a bylo to bolestně pomalé.

Jaké jsou vaše sladká místa?

0
Runeborg
  1. Vědět, co chcete dělat, a mít o to zájem
  2. Strávit několik hodin zkoumáním kódu, jak to udělat
  3. Zkopírujte a vložte kód pro dosažení konečného výsledku
  4. Pracujte na základním gui, abyste dokončili svou práci, NENECHÁVEJTE ČAS, abyste si mohli udělat PRÁVO
  5. Test a ladění
  6. Práce na docela gui
0
Matt S.

„Včasnost“ není totéž jako „rychlé“. Pokud by to byl problém, mělo by vaše hodnocení právě říci „pomalé“. Takže než se vydáte cestou, kterou navrhujete, ujistěte se, že víte, co se od vás očekává.

Mohlo by to znamenat cokoli; mohlo by to dokonce znamenat, že se nedostanete do kanceláře až do 20 minut od kolegů, nebo že máte špatnou správu času. To nemusí mít nic společného s vaší „rychlostí programování“.

Pravděpodobně trávím nejvíce času navrhováním a plánováním; je snazší naplánovat úkoly na základě dobré analýzy a návrhu a poté získáte lepší odhady, kterým bude věřit. Kromě toho se z dobrého designu stává kódování mnohem jednodušším a cílenějším procesem. Rovněž umožňuje rozdělit úkol a distribuovat jej mezi další vývojáře.

0
Clifford

Prakticky jsem ztrojnásobil rychlost kódování C s VIM .

0
Liran Orevi

CodeRush! Pochopit to! Miluji to!

0
Bobby Ortiz

Vyberte si rychlý editor, rychlý kompilátor a pište software s rychlým provedením. Tímto způsobem můžete udělat desetkrát tolik chyb než normální programátor a stále se stát lepším než ostatní. To je pravděpodobně jeden z důvodů, proč jsou aplikace Google tak populární. Vývoj webu je plný nepříjemných chyb a psaní dalšího softwaru na platformě buggy je bolest zadek. Ale doba odezvy mezi úpravou kódu a zobrazením výsledku je tak rychlá, že je ještě snazší zajistit, aby ta hora odpadu fungovala, než rozšíření programů c ++. :)

0
AareP

Trávte více času spojováním věcí ve své mysli než před IDE. Když máte plán, již máte většinu práce již hotovou. Implementace je pouze zbývajících 20%. Pokud uvíznete při psaní kódu kvůli problémům specifickým pro platformu, držte se plánu a zbytek provádějte a testujte. Nakonec se vypořádejte se všemi místy, která jste zanechali, a vyřešte je jeden po druhém - je možné, že některé budou souviset, a vyřešení několika může stačit, aby zjistili zbytek. Obvykle používám náhradní řešení takových problémů, přidávám komentáře „// TO CHANGE“ na konkrétní místa v kódu a přepisuji ta, která mají na dopad na kvalitu a výkon největší dopad, pokud nemám čas vyřešit všechny z nich do termínu.

0
luvieere

Vytvořte si vlastní knihovnu kódů

Pokaždé, když kódujete novou funkci, zkuste ji zachovat obecnou, jak je to možné, ale ne příliš obecnou. V krátkodobém horizontu to bude trochu pomalejší, ale v dlouhodobém horizontu, kdy se váš kódový knihovník zvětšuje, bude každý nový projekt dokončen rychleji, protože mnoho obchodních aplikací má podobné potřeby (ne vždy), ale natolik blízko, že mnoho kód lze znovu použít.

0
Darknight

Rychlejší neznamená lépe. Pokud se vám podaří být rychlejším a lepším programátorem. Všechno to spadne do rovnováhy. Jak dlouho to dokážete? Myšlení, trpělivost a plánování se vždy vyplatí. „Rychlý“ vývojový svět někdy může přinést nejhorší výsledky.

0
Ryuken

Rozebrat. Rozdělte, co stavíte, na menší funkce, které můžete implementovat ve fázích. Poté, kdykoli máte hotovou některou z těch menších kusů a otestovali jste, že to nic neporuší, nasaďte ji a ukažte to mocnostem, které jsou.

Používání malých iterací vám často pomůže dokončit větší projekt rychleji a lépe, protože získáváte zpětnou vazbu během cesty a nebudete se muset couvat a opakovat. Ale i když tomu tak není, vykazujete neustálý pokrok, který má solidní psychologický přínos a obnovuje důvěru vašeho manažera nebo klienta.

S tímto přístupem hodně pomáhá vývoj zaměřený na testy. Zpočátku to může vypadat, že psaní testů nejprve zpomalí věci - ale získává ten čas zpět v chybách, kterým se vyhnete, a v závislosti na tom, jak je píšete, mohou být testy samy o sobě výsledkem, který můžete ukázat Powers That Be Be a potvrďte chování aplikace ještě předtím, než to všechno napíšete.

0
SFEley

Pokud programujete v jazyce C, pak se učení bitových hacků musí stát rychlejším programátorem. Přečtěte si také postupy kódování od nejlepších žebříčků na webu Topcoder.com. Jejich kód je velmi malý a účinný.

0
avd

Staňte se rychlejším programátorem zpomalením při navrhování a kódování.

  • Přemýšlejte o tom, co děláte.
  • Zvažte důsledky svého návrhu.
  • Získejte to hned poprvé (důrazně vyzkoušejte svůj vlastní kód).

Může se to cítit pomaleji, ale vaše propustnost bude rychlejší než u kódových žokejů, kteří změní iteraci za 4 hodiny, a pak potřebují 6 kol QA před jejich kód prochází.

0
mmc

Jak odhadnout a držet se ho:

Při odhadu si pamatujte Hofstadterův zákon , stejně jako tento citát: „Všechno trvá déle, než to dělá“. Vezměte přiměřený odhad toho, jak dlouho by něco mělo trvat, a pak to zdvojnásobte nebo ztrojnásobte, než vyjde z vašich úst. Budou zde komplikace, neúspěchy, rozptýlení, věci, na které zapomenete atd. Lepší je podslib a nadměrné plnění, než naopak.

Když se budete držet odhadů, udělejte vše pro to, abyste svou práci efektivně dokončili. Když se objeví problémy, sdělte zpoždění brzy. To dává každému čas na přizpůsobení jejich očekávání. Pokud je vaše vysvětlení rozumné, může vám být poskytnuto více času nebo pomoci nebo vám může být z cesty odstraněno rozptýlení (jako hlučný soused).

0
steamer25

Následující postupy jsou dobře známy, ale často jsou opomíjeny z různých důvodů, často kvůli přísným termínům, takže si zaslouží zmínit se zde (ve skutečnosti se jedná o mechanismus pro trávení času předem, aby se zabránilo utrácení více čas později):

  • Do testem řízený vývoj; pomůže vám napsat pouze tolik kódu, kolik je skutečně potřeba, a pomůže vám vyhnout se zavádění chyb při přidávání funkcí nebo refaktoringu

  • Napište komentáře, ale pouze tam, kde je kód dostatečně komplexní, aby to bylo zaručeno

  • Refaktor a zjednodušit váš kód často

  • Použijte slušný software pro ovládání zdroje (jako Git nebo Mercurial) - pokud váš zaměstnavatel používá něco jiného, ​​použijte svůj vlastní lokálně-

  • Commit změny kódu často: pro každou funkci nebo refactoring proveďte potvrzení, protože návrat bude pro vás méně nákladný, pokud se něco zhorší

  • Nebojte se větev; Git má zejména velmi rychlý a „bezpečný“ mechanismus větvení (například ve srovnání se Subversion)

0
Nick Toumpelis

Osobně si myslím, že je to všechno o opakovaném použití kódu. Pokud neuděláte plně vlastní věci pokaždé, měli byste mít knihovnu funkcí pro běžné použití, na kterou se můžete obrátit. Mám utils.php, ve kterém mám celou "smetiště" funkcí, které jsem použil v předchozích projektech. Ušetří TON času, když musím udělat něco podobného.

Hodně štěstí a nenechte se odradit. Myslím, že jsme se všichni občas cítili pomalu nebo „hloupě“. Vím, že mám!

0
Code Monkey

Použijte nástroje pro statickou analýzu.

Pomáhají vám najít více chyb při kompilaci, které byste jinak museli sledovat za běhu.

Zejména při vytváření vícevláknových aplikací jsou skutečnou pomocí.

0
Oliver Weiler

To vše jsou dobré návrhy. Chtěl bych přidat svou vlastní techniku ​​produktivity, která má vědět, jak udělat věci nejen s minimálním kódem, ale s minimálním redundantním kódem.

Obecně to znamená, že čím méně datových struktur, tím lépe.

Vytvoření kódu s minimální redundancí vyžaduje kreativitu a ochotu dělat věci způsobem, který by mohl uložit křivku učení. To je cena produktivity. Zde je jeden příklad.

0
Mike Dunlavey