it-swarm-eu.dev

Má vývojář pomalejší vývojový stroj za následek rychlejší / efektivnější kód?

Předpokládejme, že dávám svým vývojářům křičící rychlý stroj. Našim VS2010 na bázi WPF se načítá velmi rychle. Vývojář poté vytvoří aplikaci WPF nebo WPF/e, která běží dobře v jeho krabici, ale v reálném světě je mnohem pomalejší.

Tato otázka má dvě části ...

1) Pokud dám vývojáři pomalejší stroj, znamená to, že výsledný kód může být rychlejší nebo efektivnější?

2) Co mohu udělat, abych svým vývojářům poskytl rychlý IDE) zážitek a zároveň poskytoval „typické“ runtime zkušenosti?

Aktualizace:

Pro záznam připravuji svou rovnoměrnou odpověď na řízení. To není můj nápad a vy mi lidé pomáháte opravovat zavádějící požadavky mého klienta. Děkuji, že mi dal více munice a odkazy na to, kde a kdy se k tomu přiblížit. Dal jsem +1 platné případy použití, jako například:
- specifické optimalizace programování na straně serveru
- testovací laboratoře
- možná nákup lepšího serveru místo horních řad grafických karet

130
goodguys_activate

Absolutně

Je také pravda, že manažeři by měli vést všechna setkání v prasečí latině. Celkově zlepšuje jejich komunikační schopnosti, aby byli znevýhodněni, když mluví jednoduchými větami. Budou se muset více spoléhat na výrazy obličeje a řeč těla, aby se dostali k věci a všichni víme, že je to alespoň 70% veškeré komunikace.

Finanční ředitelé by měli používat pouze počítadlo a křídu. V opačném případě se příliš spoléhají na „surová data“ a ne dost na jejich „střevní pocit“.

A viceprezidenti a vyšší by měli být povinni uspořádat všechna důležitá obchodní jednání v rušivých prostředích, jako jsou golfová hřiště, zatímco jsou částečně pod vlivem alkoholu. Kruci...

234
Jay Beavers

Odpověď zní (Budu tučně a řeknu) vždy

NO .

Vyvíjejte to nejlepší, co můžete díky svému rozpočtu, a vyzkoušejte nejmenší rozsah zařízení, do kterého nasadíte.

Existují emulátory, virtuální stroje, skutečné stroje s testery, které mohou všichni testovat výkon a zjistit, zda je to faktor.

376
Steven Evers

1) Velmi, velmi nepravděpodobné.Ne, a vaši vývojáři mohou do vaší kávy vložit něco ošklivého, aby to navrhli. Čas, který vývojáři tráví čekáním na kompilaci kódu nebo na IDE), ať udělají cokoli, nebo cokoli je čas, ne výdaje na vylepšování kódu. Také narušuje jejich duševní tok. Zaměřte se na problém a oni budou mnohem efektivnější řešení tohoto problému.

2) Každému počítači dejte druhé PC představující nejnižší specifikace, které chcete, aby je skutečně podporovali, s přepínačem KVM) mezi tím a jejich skutečnou pracovní stanicí.

70
BlairHippo

Mám rád dlouhé kompilační časy. Dává mi to více času na práci na mém životopisu.

43
Wonko the Sane

To je hrozný nápad. Chcete, aby vaši vývojáři byli co nejproduktivnější, což znamená, že jim dáte co nejrychlejší stroj, takže nebudou sedět celý den a čekat na kompilaci. (Mírně OT, ale také pomáhá nebránit jejich přístupu k potenciálně užitečným webům pomocí WebSense a podobně.) Pokud jste omezeni tím, že uživatelé, kteří stále používají technologii Stone-Age, budete muset mít zkušební stroj s podobnými specifikacemi, a ujistěte se, že testujete brzy a často, abyste se ujistili, že nejdete dolů špatnou cestou, pokud jde o technologické volby.

33
o. nate

Vývoj by měl být prováděn v nejlepším proveditelném prostředí. Testování by se mělo provádět v nejhorším možném prostředí.

32
Yevgeniy Brikman

Pokud mi bude dán pomalý stroj, trávím svůj den optimalizací procesu vývoje a ne optimalizací dodaného kódu. Takže ne!

27
user6015

Programátoři vestavěných systémů se do toho neustále zapojují! A existuje dvě části řešení:

  1. Vaše požadavky musí specifikovat výkon X na hardwaru Y.
  2. Otestujte hardware Y a pokud nedosáhnete výkonu X, buďte souborovými chybami.

Pak nezáleží na tom, na jakém hardwaru vaši vývojáři pracují.

Jakmile to uděláte, řekněme, že rychlejší vybavení může vašim programátorům ušetřit půl hodiny denně nebo 125 hodin ročně. A řekněme, že stojí 100 000 dolarů ročně s výhodami a režijními náklady (směšně nízká pro Silicon Valley), nebo 50 USD za hodinu. Že 125 hodin * 50 $/hodinu je 6250 $. Pokud tedy na hardwarový vývojový hardware na programátora utratíte méně než 6250 $ ročně, šetříte peníze.

To je to, co byste měli říct svému vedení.

Tim Williscroft téměř řekl první polovinu tohoto komentáře a v spravedlivém světě by dostal polovinu bodů, které tato odpověď získá.


Přidáno 24. října:

Můj bývalý zaměstnavatel měl tuto teorii a pomohlo jim to vyrazit asi 100 milionů dolarů.

Jedná se o japonský konglomerát, který byl zvyklý na najímání programátorů v Japonsku, Koreji a Číně. Lidé jsou v pohodě s použitím mizerného vývojového hardwaru, 13 hodin pracovních dnů, spaní ve svých stolech a bez života. Takže přišli na to, když získali významnou společnost Silicon Valley, která by měla operační systém pro mobilní telefony založené na Linuxu, ti hloupí Kaliforňané, kteří chtěli moderní výbavu, byli jen primitivní donna a ve skutečnosti k tomu neměli dobrý důvod (jako je produktivita).

O čtyři roky později OS fungoval jako svinstvo, všechny plány byly vyfouknuty a zákazníci byli naštvaní a ukončili smlouvy vpravo a vlevo. Nakonec byl projekt OS zrušen a v loňském roce bylo propuštěno velké procento světové pracovní síly konglomerátu. A upřímně řečeno, nechtěl bych být jedním z vedoucích pracovníků, kteří museli akcionářům vysvětlit, kam všechny ty peníze a úsilí šly.

Toto fiasko nezpůsobily jen pomalé vývojové stroje. Bylo tam spousta dalších strategických a taktických omylů - ale byly to stejné věci, kde lidé pracující v zákopech mohli vidět vrak vlaku přicházet, a přemýšleli, proč to rozhodující činitelé nemohou.

A pomalé zařízení bylo rozhodně faktorem. Nakonec, pokud jste pod puškou, abyste doručili včas, je opravdu chytrá věc úmyslně zpomalit práci?

26
Bob Murphy

V programování existuje staré přísloví, že „ předčasná optimalizace je kořenem všeho zla “. Myslím, že se vám podařilo úspěšně vytvořit další „kořen“ (nebo alespoň první větev) všeho zla. Od nynějška můžeme říci, že „předčasná deoptimalizace vývojářů je kořenem všeho zla“.

Stručně řečeno, odpověď je, že to jen zpomalí váš vývojový čas a ztěžuje další údržbu. Kompilační časy budou trvat déle, vyhledávání kódu na disku půjde pomaleji, hledání odpovědí online bude trvat déle a nejdůležitější je, že vývojáři začnou předčasně optimalizovat svůj kód, aby mohli dokonce otestovat potřebnou funkčnost.

Tento poslední bod je nejkritičtější otázkou a v mnoha dalších odpovědích se nevyskytuje. Můžete dostat svou první verzi v pořádku, ale pak, když chcete v budoucnu aktualizovat kód, zjistíte, že předčasná optimalizace vývojářů soustředila váš kód na dobrý design a posunula ho blíže k „musí to udělat na nejméně práce, aby moje práce "styl kódu. Přidání dalších funkcí bude obtížnější, protože optimalizace zvolená v té době nemusí být nutná a zamkne váš kód do cesty polooptimalizovaných hacků nad ostatními polooptimalizovanými hacky.

Jako příklad toho si představte, že minimální systémový požadavek vaší aktuální verze je jediný procesor s poněkud pomalou rychlostí. Na tuto krabici umístíte vývojáře a přijdou se složitým řešením s jedním vláknem, které se spoléhá na spoustu hacků, protože chtěli produkt rychle vyvinout. Nyní o 5 let později máte novou verzi produktu, která vyžaduje minimální požadavek na stroj s dvěma procesory. Chtěli byste být schopni čistě oddělit části programu, které můžete spustit paralelně, ale rozhodnutí, které jste učinili před 5 lety a které donutilo vaše vývojáře, aby vytvořili hackerský software, vám nyní brání v plném využití vašeho nového minimálního požadavku. .

Co byste měli udělat, je přidat fázi na konci vývojového cyklu, kde provedete akceptační testy na dolních mezích. Určitě bude nějaký kód příliš pomalý kvůli rychlejšímu stroji vývojáře, ale můžete tu část izolovat a optimalizovat tam. Zbytek kódu zůstane čistý a udržovatelný.

Vidím vaši otázku, jak říká: „Mohu své vývojáře donutit, aby se co nejdříve optimalizovali tím, že jim dodají špatné vývojářské stroje, ale přesto dostanou dobrý kód?“ A odpověď zní ne.

20
EntropyFails

Zajímavé čtení, všechny tyto odpovědi.

Ale myslím si, že většina lidí, kteří zde odpoví, chybí. Otázka, jak jsem četl, není (jen přinejmenším) o tom, jak vývojářům dát P1, aby vytvořili rychlejší kód.

Jde o to, že spousta softwaru je dnes stejně pomalá nebo dokonce pomalejší než seftware, který jsme v minulém tisíciletí používali navzdory velmi výkonnějším počítačům. Soudě podle odpovědí zde většina vývojářů tuto nápovědu nedostane. To je velmi zřejmé ve webových aplikacích. Tento web je velmi dobrá výjimka, ale mnoho webů má přední stránku v 1 mb. Co čekám na stažení? Nevím. Myslím, že se zdá, že jde o nevědomost od vývojáře, která nerespektuje čas, který na něj uživatel musí strávit, nebo dokonce horší platbu, pokud platíte za mb. Jde o to, že všechny tyto webové stránky neobsahují ani obrázky ve vysokém rozlišení. Často je to jen nějaký blbost kód dodávaný z nějakého vývojového prostředí. Myslím, že to samozřejmě není svinstvo, ale jako uživatel mě nezíská.

Obecně se nejedná pouze o optimalizaci kódu, ale také o to, že se nezahrnou věci zpomalující více, než dává.

Před několika týdny jsem spustil notebook od roku 1995. Windows 3.x byl v provozu a v žádném okamžiku. Databáze, ze které bych měla získat data, byla spuštěna ještě před úplným uvolněním klávesy Enter (přinejmenším).

Vím, že z našeho softwaru dnes dostáváme mnohem více, ale také máme počítače mnohokrát rychlejší. Proč se vývojové odvětví nerozhodlo udržet rychlost softwaru od roku 1995 a přimět lidi, aby kupovali nový hardware, protože chtějí novou funkčnost. Dnes je to spíš jako každodenní programy a webové stránky nutí lidi kupovat nový hardware, aby dělali přesně to samé jako dříve. Ale samozřejmě mnohem lepší.

Musím říct, že si myslím, že vývoj Linuxu to zvládne lépe. Distribuce Linuxu byla po mnoho let docela daleko před okny, dokonce i ve fantazii s mnoha věcmi oční bonbóny, jako jsou animovaná okna. Jde o to, že přesto fungují na počítačích dneška i včera. Nejen na řezání hardwaru Edge.

Teď myslím, že mnoho vývojářů má nezdravou hladinu adrenalinu. Ano, našel jsem způsob, jak vrátit nějaké frustrace ze všech čekání před:
office sql server (spouštěcí konzola pro správu) arcgis (spouštění a používání) acrobat reader (spouštění) agresso (používající, přinejmenším jako webová aplikace) okna (zíral a používal, dobře jsem nezkusil 7 zatím) .net webové stránky (stahování)

a tak dále

Cítím se dobře :-)

Na zdraví
Nicklas

15
Nicklas Avén

1) Pokud dám vývojáři pomalejší stroj, znamená to, že výsledný kód může být rychlejší nebo efektivnější?

Stavíme software za posledních 6 desetiletí a stále dostáváme takové otázky? Vypadá to jako další pokus o řezání rohů. Bez urážky, ale no tak, myslíš si, že otázka je dokonce logická? Přemýšlejte o tom v těchto termínech (pokud můžete): chcete postavit vozidlo 4x4, které bude fungovat v drsných podmínkách, dešti, blátě, cokoli. Chystáte se umístit své inženýry a montážní linku pod prvky, abyste se ujistili, že výsledné vozidlo na nich může pracovat?

Myslím, Ježíši Kriste! Existuje vývoj a testování. Testování se provádí v jiném, drsnějším prostředí, nebo vývojář ví, jak sestavit testovací lože ve svém vlastním prostředí dev, způsobem vhodným pro stresové testování. Pokud nemůže, nahraďte ho lepším vývojářem.

2) Co mohu udělat, abych svým vývojářům poskytl rychlý IDE) zážitek a zároveň poskytoval „typické“ runtime zkušenosti?

Měli byste o to požádat své vývojáře. A pokud vám nemohou poskytnout objektivní a platnou odpověď, musíte je nahradit skutečnými vývojáři.

Chcete-li však tuto otázku pobavit, dejte svým vývojářům (za předpokladu, že máte dobré vývojáře), dobré nástroje a dobrý hardware, to nejlepší, co si můžete dovolit. Poté nastavte nejnižší běžné základní prostředí, ve kterém musí váš software pracovat. To je kde by mělo dojít k testování. Je mnohem lepší inženýrskou praxí mít zkušební prostředí , které je odlišné od vývojového prostředí (nejlépe takové, které vám umožní na zátěžové testování.)

Pokud jsou vaši vývojáři dobří, měli vám to sdělit (za předpokladu, že jste je požádali).

10
luis.espinal

Výsledkem je banda vývojářů bitchinů. Tohle je dost tvrdé, jak to je, nedělejme to ještě horší.

Doporučujeme, abyste měli podobný hardware jako uživatelé v prostředí Test nebo QA, abyste však vyřešili jakékoli problémy s výkonem. To je dobrý nápad.

6
bigtang

Vyhodím normu a řeknu ano, POKUD A POUZE, pokud píšou serverový software. Smějte se, co chcete, ale nejúčinnějším týmem, který jsem kdy viděl, byla skupina Perlů s Wyse terminály. Bylo to na konci 90. let, byl to univerzitní obchod se střílením a psali software pro prostorové vytváření sítí (což v podstatě jen spočítá). Mluvili však o některých relativně silných modelech RS/6000s.

Pro větší zájem o akci tam byl slepý programátor. Byl jsem ohromen.

alt text

6
Jé Queue

To není špatný nápad - ale chcete, aby vývojáři měli rychlé programovací prostředí.

Můžete to implementovat tím, že svým programátorům poskytnete dva stroje - rychlý dev box a pomalejší komoditní box (možná virtuální) pro testování.

Nějaké vylepšení procesu sestavení VS by mohlo způsobit, že nasazení do testovacího boxu bude standardem se vzdáleným laděním.

Existují i ​​jiné způsoby, jak zvážit nutení kodérů k vývoji účinnějšího kódu - do testů jednotek můžete zahrnout například cíle týkající se výkonu a využití paměti. Vynikajícím cílem je rovněž nastavení rozpočtů pro využití paměti. Také nastavení rozpočtu hmotnosti stránky pro html kód.

5
damien

Problém není v tom, že vývojář staví neefektivní kód na rychlém stroji, problém je v tom, že jste nedefinovali metriky výkonu, proti kterým je třeba měřit.

Jako součást požadavků na produkt by měl být definován konkrétní cíl, který lze měřit na všech počítačích na základě požadované zkušenosti zákazníka. Existuje mnoho webových stránek (Check SpecInt), které vám umožňují propojit váš počítač s jinými typy počítačů.

To je dobré z mnoha důvodů. Umožňuje snadněji definovat minimální podporovaný hardware, takže můžete omezit počet stížností zákazníků - všichni víme, že většina softwaru běží na většině počítačů, je to jen otázka výkonu - pokud nastavíme naše specifikace tak, aby lidé v rozsahu minimálních požadavků má rozumně přijatelný výkon, omezujete stížnosti zákazníků - a poté, když zákazník zavolá, můžete pomocí benchmarků určit, zda skutečně existuje problém, nebo zda zákazník prostě není spokojený s tím, jak má produkt fungovat.

5
Mike Glasspool

Jsem přesvědčen, že pomalejší počítač pro vývoj má za následek rychlejší kód, ale to stojí za cenu. Důvodem je, že jsem zažil tuto první ruku: po dlouhé době dojíždění jsem si koupil netbook pro práci ve vlaku, netbook, který je pomalejší než jakýkoli počítač, který jsem si koupil za posledních 5 let. Protože je vše tak pomalé, vidím velmi rychle, když je na tomto netbooku něco nesnesitelně pomalého a vím, že pomalá místa jsou mnohem rychlejší (není třeba neustále porovnávat). Práce na netbooku opravdu změnila, jak jsem se vyvíjel.

Jak již bylo řečeno, neobhajuji to, zejména v profesionálním prostředí. Za prvé, je to demoralizační. Samotná skutečnost, že téměř všichni uvedli, že myšlenka ani nedává smysl, ukazuje, že programátoři na ni špatně reagují.

Zadruhé, mít všechno pomalejší znamená, že věci, které byste mohli chtít dělat na rychlém stroji (trvá asi 1 minutu), se na pomalém stroji už nedají opravdu realizovat, kvůli lenivosti atd. Je to otázka pobídky.

Konečně: vytvořený kód může být rychlejší, ale téměř jistě to trvá déle.

5
David Cournapeau

Bod 1, NE! Studio je určeno pro provoz na slušných strojích a tento požadavek se s každou verzí stal silnějším. Některé verze studia můžete ve skutečnosti zamknout, pokud zapnete inteligentní režim a použijete jeden základní box bez HT.

K bodu č. 2 existují v testovacích projektech některé funkce, které vám umožňují omezit některé zdroje. Nejsou dokonalí, ale jsou tam. VPC nebo obrázky s nízkou spec VM obrázky na docela dobrou práci, že jsou také omezeni. Nechal jsem uživatele, aby si sedli u špatných strojů, aby příležitostně testovali, aby mohli vidět důsledky funkcí, které používají požádal.

4
Bill

Ne - ve skutečnosti by to mělo za následek více chyb, protože nebudou provádět tolik testování a nebudou používat další nástroje, jako jsou profilové nástroje. Poskytněte jim ty nejlepší stroje, které si můžete dovolit (včetně hardwaru pro akceleraci grafiky, pokud jste vývoj hry nebo grafický obchod), a nechte je otestovat uvnitř virtuálních počítačů. Specifikace VM) lze podle potřeby škálovat nahoru nebo dolů.

4
JohnL

Myslím, že je to zajímavá otázka, a já bych tak rychle nešlo o „ne“. Můj názor je: záleží na tom, o jakém vývojovém týmu mluvíme. Příklad: Pokud vedete skupinu, která běží pro každoroční soutěž programování ICFP, možná mít dobré výsledky po malém množství času vývoje v klastru HPC nemusí nutně znamenat, že řešení, které jste našli, je dobré. Totéž lze říci, pokud píšete nějaký vědecký nebo numerický algoritmus: na vašem starém AMD Duron 600 MHz s 64 MB paměti jste nuceni dávat pozor na to, jak se věci dělají, a to může ovlivnit i nějaký design volby.

Na druhou stranu by měl být chytrý programátor/vědec/cokoli opatrný. Ale zjistil jsem, že si zapisuji některé z mých nejlepších kódů, když nemám ŽÁDNÝ počítač AT VŠECHNY a musím si dělat poznámky na papír. To nemusí platit pro velké projekty zahrnující obrovské rámce, je-li IDE je nezbytně nutné.

Jedna věc je jistá: rychlé stroje a dobré okamžité výsledky způsobují, že (špatní) programátoři se kazí a mohou být jedním z důvodů některých keců, které najdeme na počítačích.

4
Lorenzo Stella

Pracuji na balíčku, který trvá asi hodinu, než budu stavět na mém 8jádrovém 8G stroji (plně čisté sestavení). Mám také relativně low-end notebook, který testuji. Notebook typu low-end nezvládá dvě úplné sestavení během jednoho pracovního dne.

Jsem produktivnější na rychlém stroji s nějakým záměrným testováním na notebooku, nebo bych měl dělat všechny své sestavení na notebooku?

Mějte na paměti, že se nejedná o čísla.

Je to opravené demo v tom, že za normálních okolností nemusím dělat čistou sestavu každý den (mohu dělat spoustu testů na jednotlivých modulech), ale i částečné sestavení ukazují zhruba řádový rozdíl v době kompilace/odkazu .

Skutečným problémem je proto, že na mém pomalejším stroji je typická sestava dost dlouhá na to, abych si mohl dát šálek kávy, zatímco na svém rychlejším stroji můžu jen popíjet trochu kávy.

Z hlediska provedení práce dávám přednost vývoji na rychlém stroji. Dokážu mnohem spolehlivěji dodržet termíny. Na druhé straně si představuji, že kdyby mě management přinutil vyvíjet na svém pomalém stroji, nechal bych udělat mnohem víc prohlížení webu, nebo alespoň čtení knih.

4
Stripes

Zajímavé je, že jsem pracoval na startu, kde jsme to nakonec udělali. Myslím, že to vlastně fungovalo docela dobře, ale pouze kvůli specifické situaci, ve které jsme byli. Byl to obchod mod_Perl, kde auto-reloading třídy skutečně fungoval správně. Všichni vývojáři použili vim jako své volby IDE = (nebo použili nějaký software pro vzdálenou editaci).) Konečným výsledkem bylo, že velmi málo (pokud vůbec) času bylo ztraceno čekáním na kompilaci/opětovné načtení/atd.

V zásadě se mi líbí tato myšlenka IFF, že má zanedbatelný dopad na vývojový cyklus pro všechny vývojáře a má dopad pouze na běhový provoz vašeho kódu. Pokud je váš kód přesto kompilován, předzpracován atd., Přidáváte čas na smyčku „opravit chybu; test; další“, na které vývojáři pracují.

Z interpersonální strany lidé nikdy nuceni nepoužívali pomalé servery, ale pokud jste použili pomalé servery, nemuseli jste provádět žádnou vlastní údržbu nebo nastavení. Také toto nastavení existovalo od samého začátku, neumím si představit, že bych se ho pokusil prodat zavedenému vývojovému týmu.

Po přečtení původní otázky se mi zdá, že jedna věc, která mě neustále děsí, jsou vývojová prostředí, která se liší od produkčních prostředí. Proč nepoužívat VM) pro provádění kódu, který můžete ochromit za běhu bez ovlivnění pracovní stanice dev? V poslední době jsem používal/miloval VirtualBox.

3
user6041

Tohle budu vytrhávat trend.

Anecdote: Pracoval jsem pro nizozemskou softwarovou vývojovou firmu, která upgradovala 286 počítačů na 486 es (ano, jsem tak stará). Během několika týdnů se výkon všech našich interních knihoven snížil o 50% a chyby se zvýšily ... Malý průzkum ukázal, že lidé již během procesu ladění nepřemýšleli o samotném kódu, ale uchýlili se k „rychlému“ následnému kódu -> kompilace -> test -> oprava (kód) atd. cyklů.

Související: Když jsem založil dceřinou společnost pro stejnou společnost v USA, skončil jsem najímáním ruských programátorů, protože byli zvyklí na PC s menším počtem funkcí/méně energie a byli mnohem účinnějšími kodéry.

Uvědomuji si, že to byly jiné časy a zdroje byly mnohem vzácnější, než jsou dnes, ale nikdy mě nepřestává udivovat, jak se s veškerým pokrokem, který byl učiněn na hardwarové frontě, zdá se, že výsledkem je, že každý krok vpřed je negováno programováním sloppier vyžadujícím vyšší minimální specifikace ...

Proto ... mám pocit, že by programátoři měli být nuceni testovat své aplikace na počítačích, které nepřekračují výpočetní výkon a technické parametry hardwaru „Joe“.

3
John SMythe

Hardware je méně nákladný než čas vývoje.

Většina úzkých míst je v databázi, nikoli v klientském počítači, ale to neomlouvá testování na pomalejších strojích než vývojář. K testování optimalizace použijte testovací nástroje.

3
Brian

Rozhodně ne. Dejte svým programátorům to nejlepší notebookové peníze, které si můžete koupit, klávesnici dle vlastního výběru, několik velkých velkých obrazovek, soukromou kancelář, žádný telefon, nealkoholické nápoje zdarma, všechny knihy, které chtějí (jsou relevantní), každoroční výlety na klíčové technické konference a získáte skvělé výsledky. Poté otestujte kombinace hardwaru/softwaru/prohlížeče/šířky pásma na horní a dolní hranici.

3
addictedtoswdev

Pro mnoho aplikací je problém přimět vývojáře, aby testovali s datovými soubory ve skutečném světě dříve, než budou hotovi. Pro interaktivní aplikace by byl vyžadován základní testovací stroj/VM.

2
user6043

Pracuji na pomalém počítači se systémem Windows95 a umožňuje mi efektivně psát umělou inteligenci MindForth ve Forthu a v JavaScriptu.

2
Mentifex

To je zajímavá myšlenka (pomalý stroj devs může vést k další optimalizaci).

Řešení je však orámováno lepším způsobem - dejte dobu odezvy do požadavků na programy a pro testování je k dispozici nízko-koncový stroj.

Také, pokud máte opravdu kompilátor/jazyk, který může být schopen určit, může navrhnout různé způsoby, jak vygenerovat kód a vybrat ten nejlepší. Tomu by pomohl pouze rychlejší počítač.

2
Paul Nathan

Jiní odpověděli, že obecně chcete, aby vývojáři měli rychlé stroje. Souhlasím. Nepoužívejte přeskočit na RAM - chcete tolik v paměti, jak můžete - některé procesy sestavení jsou velmi náročné na využití disku.

Věci, které byste mohli zvážit, jak se zbavit, je antivirus na budovacích jednotkách! To jen zpomaluje a může to být extrémně silný faktor zpomalení.

Možná budete chtít nechat vývoj vyvíjet na Linuxu, pokud je to možné. Nástroje, které existují, jsou mnohem lepší pro všechny druhy dalších úkolů (jen grep na něco v souboru atd.). Tím se také zbaví antiviru.

2
user1249

Zeptat se programátorů, zda by programátoři měli získat dobrý hardware, je jako ptát se tlustého muže, zda má rád jídlo. Vím, že se jedná o subjektivní výměnu, ale stále ... stojí za to se nás na to zeptat? : P

To znamená, že samozřejmě souhlasím s většinou: NO .

2
Matthew Read

Jsem v pokušení říci „ne“ kategoricky, ale dovolte mi podělit se o poslední zkušenost: Někdo v našem projektu pracoval na nějakém kódu pro import dat do databáze. V té době měl nejstarší počítač v naší skupině, možná i celou organizaci. S VS 2008 to fungovalo dobře, ale rychlejší stroj by samozřejmě zážitek vylepšil. V každém okamžiku proces, který psal, byl během testování bombardován (a to ještě předtím, než byl plně funkční). Došel mu paměť. Tento proces také trvalo několik hodin, než došlo k jeho bombardování. Pokud jsme věděli, mějte na paměti, že by to uživatelé museli používat.

Požádal o další RAM. Odmítli, protože za 3-4 týdny dostal novější stroj a ten starý byl vyřazen.

Nezapomeňte, že filozofie tohoto chlapce v oblasti optimalizace je: „Máme rychlé stroje se spoustou paměti RAM“ (stejně tak jeho a několik počítačů vyloučeno), tak proč ztrácet čas tím, že optimalizujete čas potřebný pro programátory? Situace ho však přinutila změnit algoritmus tak, aby byl efektivnější z hlediska paměti, takže by mohl běžet na jeho 2 GB počítači (běží na XP). Vedlejším účinkem přepisování je, že proces také běžel mnohem, mnohem rychleji než předtím. . Také původní verze by nakonec bombardovala i 4Gb, když bylo importováno více dat - byl to pamětní prase, prostý a jednoduchý.

Soooo ... I když obecně říkám „Ne“, jedná se o případ, kdy vývojář s méně výkonným počítačem vyústil v lépe optimalizovaný modul a uživatelé budou mít z toho užitek (protože to není proces, který potřebuje běžet velmi často, zpočátku neměl v úmyslu jej optimalizovat v obou směrech, takže by byli uvízli s původní verzí, kdyby měl stroj dost RAM k provedení několika velkých testů .. .) Vidím jeho názor, ale osobně se mi nelíbí myšlenka, že uživatelé budou muset čekat 8 hodin, než bude proces dokončen, když může běžet za zlomek té doby.

Vzhledem k tomu by programátoři měli obecně mít výkonné stroje, protože většina vývoje je poměrně intenzivní. Je však třeba věnovat velkou pozornost tomu, aby bylo zajištěno, že testování bude prováděno na strojích s „nejmenším společným jmenovatelem“, aby bylo zajištěno, že tento proces nebude bombardovat a že uživatelé nebudou po celý den sledovat lak na sucho. Ale to už bylo řečeno. :)

2
MetalMikester

Při čtení otázky a odpovědí jsem docela ohromen rychlostí případu NE.

Již 25 let pracuji na vývoji softwaru a mohu bez váhání říci, že programátoři potřebují spoustu věcí, aby mohli vyvinout dobrý kód:

  • ZNAMENATELNÉ vývojové prostředí. Ne dinosaurus. Ani to nemusí být krvácení Edge. Dost dobrý, aby to nebylo frustrující.

  • Dobrá specifikace (kolik se dělá s NO písemnou specifikací?)

  • Dobré a podpůrné řízení.

  • Rozumný rozvrh rozvoje.

  • Dobré porozumění uživatelům a prostředí, které budou mít uživatelé.

Dále, v tomto posledním bodě, vývojáři potřebují myslet na to, co uživatelé budou používat. Pokud mají uživatelé superpočítače a dělají simulace štěpení atomů nebo něco, kde výkon stojí spoustu peněz a výpočty probíhají mnoho hodin, pak se výkon myšlení počítá.

Pokud mají uživatelé 286 Steam notebooků, pak vývoj a vývojáři provádějí vývojový test na nejnovějším 47 GHz Core i9000, povede to k některým problémům.

Ti, kteří říkají „dávají vývojářům to nejlepší a testují to“, mají částečně pravdu, ale pro vývojáře to má velký MENTÁLNÍ problém. Nemají uznání uživatelské zkušenosti, dokud není příliš pozdě - v případě selhání testování.

Když testování selže - architektury byly odhodlány, vedení dostalo sliby, utratilo se spoustu peněz a pak se to stalo katastrofou.

Vývojáři musí od prvního dne myslet, chápat a být v oblasti uživatelské zkušenosti.

Ti, kteří křičí „ne, to takhle nefunguje“, mluví o tom, co je. Viděl jsem to mnohokrát. Obvyklá reakce vývojářů je jedním z „dobře řekněte ZÁKAZNÍKŮM, aby si koupili lepší počítač“, což fakticky obviňuje zákazníka. Není dost dobrý.

To znamená, že máte několik problémů:

  • Mějte devs šťastný a piss vedení, zvýšit šance na neúspěch projektu.

  • Pro vývoj používejte pomalejší stroje s rizikem rozrušení devs, ale udržujte je zaměřené na to, na čem opravdu záleží.

  • Umístěte na devs stůl 2 stroje a NUTNĚTE je K TESTU NA KLUNKERU (což neudělají, protože je pod opovržením ... ale alespoň je to zcela jasné, pokud se při testu vyskytnou problémy s výkonem).

Pamatujete si dávkové systémy a děrné karty? Lidé čekali hodinu nebo den na obrat. Věci skončili.

Pamatujete si staré unixové systémy s 5 MHz procesory? Věci jsou hotové.

Techo-geekové milují honění krvácejícího okraje. To podporuje drotání, nemyslení. O něčem, o čem jsem v průběhu let hádal s více vývojáři juniourů ... když je vyzývám, aby si nechali prsty od klávesnice a trávili více času čtením kódu a přemýšlením.

Při vývoji kódu neexistuje náhrada myšlení.

V tomto případě můj pocit je - přijít na to, co je opravdu záležitostí. Úspěch projektu? Je to společnost, která dělá/zabíjí cvičení? Pokud ano, nemůžete si dovolit selhat. Nemůžete si dovolit vyhodit peníze na věci, které v testu selhaly. Protože test je příliš pozdě ve vývojovém cyklu, dopady selhání jsou zjištěny příliš pozdě.

[Chyba nalezená v testech stojí asi 10x tolik, kolik je třeba opravit, jako chyba nalezená vývojářem během vývoje.

A chyba nalezená v testech stojí asi 100x tolik, kolik je třeba opravit, jako ta chyba, která byla navržena během fáze architektonického návrhu.]

Pokud se nejedná o řešení problémů a máte čas a peníze na vypálení, použijte vývojové prostředí krvácejícího okraje a trpíte pekelnými selháními testu. Jinak najděte jinou cestu. Dolní konec h/w nebo 2 stroje na každém stole.

2
quickly_now

Můj Macbook Pro v práci je několik let starý. Mezi Linuxem a Windows (k testování IE vtipů) vms, stejně jako několika otevřených webových prohlížečů a terminálů, se otočné kolo OSX hodně objeví. Hádej, co dělám, když se točí, sedím V tomto případě pomalý stroj zpomaluje produktivitu.

2
Thierry Lam

Říkám, že vývojáři potřebují nejlepší dostupný vývojový systém - ale to nemusí nutně znamenat nejrychlejší. Může to znamenat například moderní, ale relativně pomalý systém s pasivním chlazením, který například udržuje hluk na minimu.

Jedna věc - vývojový systém by měl být přiměřeně nový a měl by absolutně mít více jader.

Starý počítač může znít atraktivně způsobem předváděním výkonu, ale například Pentium 4 může být ve skutečnosti rychlejší (na jádro) než některé současné čipy. To znamená, že omezením vývojáře na používání systému P4 (ve skutečnosti to, co teď používám - i když to je můj osobní problém s rozpočtováním) ...

  1. Podporujete vývoj nesouběžného softwaru, který nebude těžit ze současných běžných vícejádrových systémů.
  2. I když je vyvíjen vícevláknový software, chyby nemusí být zaznamenány (nebo alespoň nevšimnuty brzy), protože problémy související se souběžností se nemusí objevit při testování na jednojádrovém systému.
  3. Vícevláknový software může způsobit vážné problémy s výkonem, které se u víceprocesorových procesorů mohou zhoršit. Jeden by způsobil mlácení hlavy disku (což může mít za následek mnoho tisíckrát pomalejší přístup k datům), kde jednotlivá vlákna dělají sekvenční přístup, ale každý do jiné části disku. To může dokonce zmizet na starších pomalejších počítačích, např. s dvěma starými 160GB jednotkami namísto jedné 1TB jednotky, nemusí tato vlákna již navzájem bojovat o přístup ke stejnému disku.

Existují také problémy s počítači, které jsou příliš omezeny na dobrou podporu virtuálních strojů - např. pro testování na více platformách.

1
Steve314

Odpověď leží uprostřed.

Mít jeden rychlý box pro spuštění dev prostředí (např. Eclipse)

A další pomalé pole pro testování výstupu. To je zvláště důležité pro webové aplikace.

Obrazovky vedle sebe, jedna pro každou krabici.

Pokud je kód přijatelný ve výstupním poli, bude pro většinu uživatelů více než přijatelný.

Rychlé dev boxy činí programátory línými. Například hledání prvku v DOM pokaždé, když je to potřeba. Najděte jej jednou a výsledek uložte do mezipaměti.

Opravdu si všimnete rozdílu na pomalém boxu, který běží IE 6 ....

1
David Semeria

Tato teorie je jednoduchá a zastaralá. Byla to pravda za těch dnů.

Pamatuji si, že trávím více času mikrooptimalizací svých věcí Turbo Pascal v mém počítači před Pentiem. Dávalo to smysl před Y2K, od té doby mnohem méně. V dnešní době nemáte optimalizaci na 10 let starý hardware. Stačí najít testovací software pro nalezení úzkých míst. Ale jak tu všichni pronikají, neznamená to, že vývojářská (a tím i optimalizační) produktivita koreluje s tím, že jim poskytuje zastaralý hardware pro vývoj.

1
mario

1) Pokud dám vývojáři pomalejší stroj, znamená to, že výsledný kód může být rychlejší nebo efektivnější?

Ne. Dobrý vývojáři jsou rozmazlení. Pokud uvidí, že ve vaší společnosti dostanou špatné nástroje, půjdou pracovat někam jinam. (Dobrý vývojáři mají obvykle na výběr někde jinde)

1
Sean Patrick Floyd

Není odpověď na tuto otázku nezvyklým „NE“ nezávisle na tom, na koho se ptáte?

Zeptejte se svých grafiků, zda by měli mít pomalejší stroj.

Zeptejte se svých autorů, zda by si vybrali pomalejší stroj než rychlejší.

Zeptejte se administrativních asistentů, zda by dávali přednost pomalejšímu nebo rychlejšímu počítači.

Všichni řeknou, že budou produktivnější s rychlejším strojem.

1
Barry Brown

Dokážu si představit zážitek z profilu, když používám pomalý stroj. Yikes.

Ve zkratce. Sakra ne.

Také máte alespoň 4 GB RAM, takže můžete mít 2 GB na vašem hlavním stroji, 1 pro a VM a další 1 pro přídavnou paměť VM potřeby) a abyste měli volnou paměť.

Také dva procesory jsou nutností, takže pokud aplikace zamkne/sní CPU, vývojář nemusí bolestivě způsob, jak něco ctrl-alt-del.

0
user2528

Pojďme proti proudu: ANO. Nebo alespoň to byla obecná moudrost v oboru po celá desetiletí (s výjimkou samozřejmě mezi vývojáři, kteří se vždycky rozzlobí, když se s nimi nezachází jako s licenčními odměnami a nedostanou nejnovější gadgety a počítače).

Samozřejmě existuje bod, ve kterém se zmenší stroj vývojáře na újmu jeho pracovnímu výkonu, protože spuštění aplikací, které potřebuje ke spuštění své práce, je příliš pomalé. Tento bod je však daleko od řádku od počítače s 1 000 $ + s 6 GB RAM, 2 4 GB grafickými kartami, špičkovou zvukovou kartou, 4 obrazovkami atd.

V práci jsem nikdy neměl špičkový stroj a nikdy mě to výrazně nezpomalilo, dokud to bylo slušné (a několik skutečných strojů nevyhovujících standardům bylo rychle vyměněno, když jsem ukazoval, jak mě zpomalily).

0
jwenting

Rychlost běhu na vývojářském počítači je tak irelevantní, pokud nechcete svého vývojáře pomstít nebo potrestat za psaní pomalého kódu a za ignorování cílového prostředí nasazení.

Jako manažer byste se měli ujistit, že vývojáři znají cíl projektu a vždy se ujistit, že jsou na dobré cestě. O problému cílového stroje, o kterém diskutujeme, tomu lze zabránit včasným a častým testováním na pomalém stroji, nikoli tím, že by jim pomalý stroj používal a trpěl.

Pomalá rychlost běhu také zpomaluje vývoj, protože většina programátorů používá metodu kódování a testování. Pokud je doba běhu pomalá, jejich úloha bude také pomalá.

0
tia