Czy danie programistom wolniejszej maszyny programistycznej powoduje szybszy / bardziej wydajny kod? [Zamknięte]

Załóżmy, że daję moim programistom krzyczącą szybką maszynę. VS2010 oparty na WPF ładuje się bardzo szybko. Następnie programista tworzy aplikację WPF lub WPF / e, która działa dobrze na jego urządzeniu, ale w rzeczywistości jest znacznie wolniejsza.

To pytanie składa się z dwóch części ...

1) Jeśli dam programistom wolniejszą maszynę, czy to oznacza, że ​​wynikowy kod może być szybszy lub bardziej wydajny?

2) Co mogę zrobić, aby zapewnić moim programistom szybkie środowisko IDE, zapewniając jednocześnie „typowe” środowisko wykonawcze?

Aktualizacja:

Dla przypomnienia przygotowuję moją bezstronną reakcję na zarządzanie. To nie jest mój pomysł, a wy pomagacie mi poprawić błędne żądania mojego klienta. Dziękuję, że dałeś mi więcej amunicji oraz odniesienia do tego, gdzie i kiedy mam się do tego zbliżyć. Dałem +1 poprawnym przypadkom użycia, takim jak:
- konkretne optymalizacje programowania po stronie serwera
- laboratoria testowe
- możliwe, że kupię lepszy serwer zamiast najlepszych kart graficznych

Absolutnie

Prawdą jest również, że menedżerowie powinni prowadzić wszystkie spotkania w języku łacińskim. Ogólnie poprawia to ich umiejętności komunikacyjne, ponieważ są w niekorzystnej sytuacji, gdy wypowiadają proste zdania. Będą musieli polegać w większym stopniu na mimice twarzy i mowie ciała, aby osiągnąć swój cel, a wszyscy wiemy, że i tak stanowi to co najmniej 70% całej komunikacji.

Dyrektorzy finansowi powinni używać wyłącznie liczydła i kredy. W przeciwnym razie zbytnio polegają na „surowych danych”, a zbyt mało na „odczuciu jelita”.

Wiceprezydenci i wyżsi powinni być zobowiązani do organizowania wszystkich ważnych spotkań biznesowych w rozpraszających uwagę miejscach, takich jak pola golfowe, gdy są częściowo odurzeni. O rany ...

Odpowiedź brzmi (będę śmiała i powiem) zawsze

NO .

Rozwijaj się w najlepszy sposób, jaki możesz uzyskać ze swojego budżetu i testuj na minimalnym i maksymalnym zakresie specyfikacji sprzętu, na którym będziesz wdrażać.

Istnieją emulatory, maszyny wirtualne, rzeczywiste maszyny z testerami, które mogą przetestować wydajność, aby sprawdzić, czy to czynnik.

1) Bardzo, bardzo mało prawdopodobne. Nie, a Twoi programiści mogą zasugerować coś paskudnego w kawie. Czas, który programiści spędzają na oczekiwaniu na kompilację kodu lub na wykonanie przez IDE wszystkiego, co robi, lub czasu, który nie spędzają na ulepszaniu kodu. Zakłóca także ich przepływ mentalny. Utrzymuj zdanie na temat problemu, a oni będą znacznie skuteczniej rozwiązywać ten problem.

2) Daj im co drugi komputer reprezentujący najniższe parametry, które mają w rzeczywistości obsługiwać, z przełącznikiem KVM przechodzącym między tym a ich prawdziwą stacją roboczą.

Lubię długie czasy kompilacji. Daje mi to więcej czasu na pracę nad moim CV.

To okropny pomysł. Chcesz, aby Twoi programiści byli jak najbardziej produktywni, co oznacza, że ​​dają im tak szybką maszynę, jak to możliwe, aby nie siedzieli cały dzień, czekając na kompilację. (Nieco OT, ale pomaga również nie blokować ich dostępu do potencjalnie pomocnych stron za pomocą WebSense i tym podobnych.) Jeśli ograniczają Cię użytkownicy, którzy nadal korzystają z technologii epoki kamienia, musisz mieć maszynę testową z podobnymi specyfikacjami i koniecznie przetestuj wcześnie i często upewnij się, że nie wybierasz niewłaściwej drogi pod względem wyboru technologii.

Rozwój powinien odbywać się w najlepszym możliwym środowisku. Testy powinny być wykonywane w najgorszym możliwym środowisku.

Gdybym otrzymał powolną maszynę, spędziłbym dzień na optymalizacji procesu programowania, a nie na optymalizacji dostarczonego kodu. Więc nie!

Programiści systemów wbudowanych wpadają na to cały czas! I jest dwuczęściowe rozwiązanie:

1. Twoje wymagania muszą określać wydajność X na sprzęcie Y.
2. Testuj na sprzęcie Y, a gdy nie uzyskasz wydajności X, błędy plików.

Wtedy nie będzie miało znaczenia, na jakim sprzęcie pracują twoi programiści.

Gdy to zrobisz, powiedzmy, że szybszy sprzęt może zaoszczędzić programistom pół godziny dziennie lub 125 godzin rocznie. Powiedzmy, że kosztują 100 000 USD rocznie z korzyściami i kosztami ogólnymi (absurdalnie niski w Dolinie Krzemowej), czyli 50 USD za godzinę. To 125 godzin * 50 USD za godzinę to 6250 USD. Więc jeśli wydajesz mniej niż 6250 USD rocznie na rockowy sprzęt programistyczny na programistę, oszczędzasz pieniądze.

To powinieneś powiedzieć swojemu zarządowi.

Tim Williscroft prawie powiedział pierwszą połowę tego w komentarzu, a w sprawiedliwym świecie otrzymałby połowę punktów, które otrzyma ta odpowiedź.

Dodano 24 października:

Mój były pracodawca miał tę teorię, która pomogła im wkurzyć około 100 milionów dolarów.

To konglomerat mający siedzibę w Japonii, przyzwyczajony do zatrudniania programistów w Japonii, Korei i Chinach. Ludzie są fajni w używaniu kiepskiego sprzętu programistycznego, 13-godzinnych dni pracy, śpią przy biurkach i nie mają życia. Doszli do wniosku, że kiedy nabyli znaną firmę z Doliny Krzemowej, aby stworzyć system operacyjny telefonu komórkowego oparty na Linuksie, ci głupi Kalifornijczycy, którzy chcieli nowoczesnego sprzętu, byli po prostu marudnymi prima-donnami i tak naprawdę nie mieli dobrego powodu (jak produktywność).

Cztery lata później system operacyjny działał jak bzdura, wszystkie harmonogramy zostały wysadzone, a klienci byli wkurzeni i rozwiązując umowy na prawo i na lewo. Wreszcie projekt systemu operacyjnego został anulowany, a znaczny odsetek światowej siły roboczej konglomeratu został zwolniony w ciągu ostatniego roku. I szczerze mówiąc, nie chciałbym być jednym z kierowników, którzy musieliby wyjaśniać akcjonariuszom, gdzie przeznaczono tyle pieniędzy i wysiłku.

To fiasko spowodowało nie tylko powolne tworzenie maszyn. Było wiele innych strategicznych i taktycznych błędów - ale były to te same rzeczy, w których ludzie pracujący w okopach widzieli zbliżający się wrak pociągu i zastanawiali się, dlaczego decydenci nie mogli.

Powolny bieg był z pewnością czynnikiem. W końcu, jeśli jesteś pod bronią, aby dotrzymać terminów, czy naprawdę mądrze jest celowo spowolnić pracę?

W programowaniu jest stare powiedzenie, że „ przedwczesna optymalizacja jest źródłem wszelkiego zła ”. Myślę, że udało ci się stworzyć kolejny „korzeń” (lub przynajmniej pierwszą gałąź) wszelkiego zła. Odtąd możemy powiedzieć, że „przedwczesna deoptimizacja programistów jest źródłem wszelkiego zła”.

Krótko mówiąc, odpowiedź jest taka, że ​​spowolni to czas programowania i utrudni dalszą konserwację. Czas kompilacji potrwa dłużej, wyszukiwanie kodu na dysku będzie wolniejsze, znajdowanie odpowiedzi w Internecie potrwa dłużej, a NAJWAŻNIEJSZE, programiści zaczną używać przedwcześnie optymalizować swój kod, aby móc nawet przetestować wymaganą funkcjonalność.

Ten ostatni punkt jest najważniejszym problemem i nie pojawia się w wielu innych odpowiedziach. Możesz uzyskać pierwszą wersję w porządku, ale kiedy będziesz chciał zaktualizować kod w przyszłości, przekonasz się, że przedwczesna optymalizacja deweloperów odwróciła uwagę twojego kodu od dobrego projektu i przesunęła go bliżej do „muszę to zrobić na „najmniej pracy, aby utrzymać moją pracę” w stylu kodu. Dodanie dodatkowych funkcji stanie się trudniejsze, ponieważ wybrane wówczas optymalizacje mogą być niepotrzebne i zablokować kod na ścieżce częściowo zoptymalizowanych hacków na tle innych częściowo zoptymalizowanych hacków.

Jako przykład tego, wyobraź sobie, że minimalne wymagania systemowe twojej aktualnej wersji to maszyna z jednym procesorem o nieco wolniejszej prędkości. Umieszczasz programistów na tym pudełku, a oni wymyślają skomplikowane rozwiązanie jednowątkowe, które polega na wielu włamaniach, ponieważ chcieli szybko opracować produkt. Teraz, 5 lat później, masz nową wersję produktu, która ma minimalne wymagania dotyczące komputera z dwoma procesorami. Chcesz mieć możliwość oddzielnego wydzielenia części programu, które możesz uruchamiać równolegle, ale decyzja podjęta 5 lat temu, która zmusiła programistów do stworzenia zhakowanego oprogramowania, uniemożliwia Ci wykorzystanie pełnej mocy nowego minimalnego wymagania .

To, co powinieneś zrobić, to dodać fazę pod koniec cyklu programowania, w której przeprowadzasz testy akceptacyjne w dolnych dolnych ramkach. Z pewnością część kodu będzie zbyt wolna z powodu szybszej maszyny dewelopera, ale możesz wyizolować tę część i tam ją zoptymalizować. Reszta kodu pozostaje czysta i łatwa w utrzymaniu.

Widzę, że twoje pytanie brzmi: „Czy mogę zmusić programistów do wczesnej optymalizacji, dając im kiepskie maszyny programistyczne, ale wciąż otrzymując dobry kod?” Odpowiedź brzmi: nie.

Ciekawa lektura, wszystkie te odpowiedzi.

Ale myślę, że większość ludzi, którzy tu odpowiadają, nie rozumie tego. Pytanie, które czytam, nie polega (przynajmniej) na tym, aby naprawdę dać programistom P1, aby tworzyło szybszy kod.

Chodzi o to, że wiele dzisiejszych programów jest tak samo powolnych lub nawet wolniejszych niż programy, z których korzystaliśmy w ostatnim tysiącleciu, pomimo znacznie potężniejszych komputerów. Sądząc po odpowiedziach tutaj, większość programistów nie otrzymuje takiej wskazówki. Jest to bardzo oczywiste w aplikacjach internetowych. Ta strona jest bardzo dobrym wyjątkiem, ale wiele witryn ma stronę główną w 1 MB. Co dostaję za czekanie na pobranie? Nie wiem Myślę, że wydaje się, że chodzi o ignorancję ze strony dewelopera, która nie szanuje czasu, jaki użytkownik musi na nią poświęcić, lub nawet gorzej, jeśli płacisz za MB. Chodzi o to, że wszystkie te strony internetowe nie zawierają nawet zdjęć w wysokiej rozdzielczości. Często jest to tylko jakiś bzdurny kod dostarczony z jakiegoś środowiska programistycznego. Oczywiście nie jest to bzdura, ale jako użytkownik nie daje mi żadnej korzyści.

Ogólnie rzecz biorąc, nie chodzi tylko o optymalizację kodu, ale również o to, aby nie uwzględniać rzeczy spowalniających więcej, niż daje.

Kilka tygodni temu uruchomiłem laptopa od 1995 roku. Windows 3.x był gotowy do działania w mgnieniu oka. Baza danych powinienem pobrać niektóre dane przed uruchomieniem, zanim klawisz Enter został w pełni zwolniony (prawie przynajmniej).

Wiem, że dzisiaj uzyskujemy znacznie więcej z naszego oprogramowania, ale mamy też komputery wiele razy szybsze. Dlaczego branża programistyczna nie decyduje się na utrzymanie szybkości oprogramowania od 1995 roku i zmuszanie ludzi do kupowania nowego sprzętu, ponieważ chcą nowej funkcjonalności. Dzisiaj bardziej przypomina to, że codzienne programy i strony internetowe zmuszają ludzi do kupowania nowego sprzętu, aby robić dokładnie to samo, co wcześniej. Ale oczywiście w bardziej wyszukany sposób.

Muszę powiedzieć, że wydaje mi się, że rozwój Linuksa radzi sobie z tym lepiej. Dystrybucje Linuksa od wielu lat są daleko w tyle za oknami, nawet w szaleństwie z wieloma atrakcyjnymi dla oka elementami, takimi jak animowane okna. Chodzi o to, że pomimo tego pracowali na komputerach dzisiaj, a nawet wczoraj. Nie tylko na najnowocześniejszym sprzęcie.

Do tej pory myślę, że wielu programistów ma niezdrowy poziom adrenaliny. Tak, znalazłem sposób na
odwrócenie frustracji od wszystkich oczekujących przed: serwerem Office sql (uruchamianie konsoli zarządzania) arcgis (uruchamianie i używanie) czytnik acrobat (uruchamianie) agresso (używanie, przynajmniej jako aplikacja internetowa) Windows (gaping i używanie, no cóż, jeszcze nie próbowałem 7). strony internetowe (pobieranie)

i tak dalej

Czuję się dobrze :-)

Pozdrawiam
Nicklas

1) Jeśli dam programistom wolniejszą maszynę, czy to oznacza, że ​​wynikowy kod może być szybszy lub bardziej wydajny?

Budujemy oprogramowanie przez ostatnie 6 dekad i nadal otrzymujemy podobne pytania? Wydaje się bardziej kolejną próbą skrętu. Bez obrazy, ale dalej, czy uważasz, że pytanie jest nawet logiczne? Pomyśl o tym w tych kategoriach (jeśli możesz): chcesz zbudować pojazd 4x4, który będzie działał w trudnych warunkach, deszczu, błocie, cokolwiek. Czy umieścisz swoich inżynierów i linię montażową pod elementami, aby upewnić się, że powstały pojazd będzie mógł na nich działać?

Mam na myśli Jezusa Chrystusa! Jest rozwój i są testy. Testowanie odbywa się w innym, trudniejszym środowisku, lub programista wie, jak złożyć stanowisko testowe we własnym środowisku programistycznym w sposób odpowiedni do testów warunków skrajnych. Jeśli nie może, zastąp go lepszym programistą.

2) Co mogę zrobić, aby zapewnić moim programistom szybkie środowisko IDE, zapewniając jednocześnie „typowe” środowisko wykonawcze?

Powinieneś o to poprosić swoich programistów. A jeśli nie mogą dać obiektywnej i prawidłowej odpowiedzi, musisz zastąpić ich prawdziwymi programistami.

Ale aby odpowiedzieć na pytanie, daj swoim programistom (zakładając, że masz dobrych programistów), dobre narzędzia i dobry sprzęt, na co możesz sobie pozwolić. Następnie skonfiguruj najniższe wspólne środowisko podstawowe, w którym oprogramowanie musi działać. Właśnie tam powinny wystąpić testy. O wiele lepszą praktyką inżynierską jest posiadanie środowiska testowego, które różni się od środowiska programistycznego (najlepiej takiego, które pozwala wykonać testy warunków skrajnych).

Jeśli twoi programiści są dobrzy, powinni ci to przekazać (zakładając, że o to poprosiłeś).

Powoduje to garść dziwnych programistów. Te rzeczy są wystarczająco trudne, nie pogarszajmy tego doświadczenia.

Zachęcam do posiadania sprzętu podobnego do użytkowników w środowisku testowym lub kontroli jakości, aby jednak wyeliminować wszelkie problemy z wydajnością. To jest dobry pomysł.

Zniszczę normę i powiem tak, JEŚLI I TYLKO, jeśli piszą oprogramowanie serwera. Śmiej się, ile chcesz, ale najskuteczniejszym zespołem, jaki kiedykolwiek widziałem, była grupa ludzi Perla z terminalami Wyse. To był koniec lat 90., był uniwersyteckim sklepem poza sesjami i pisali oprogramowanie do tworzenia siatki przestrzennej (które w zasadzie tylko oblicza). Rozmawiali jednak z niektórymi stosunkowo potężnymi późnymi modelami RS / 6000.

Aby dodać zainteresowanie wydarzeniem, był tam niewidomy programista. Byłem pod wielkim wrażeniem.

To nie jest zły pomysł - ale chcesz, aby Twoi programiści mieli szybkie środowisko programistyczne.

Możesz to zaimplementować, dając programistom dwie maszyny - szybką skrzynkę deweloperską i wolniejszą skrzynkę towaru (prawdopodobnie wirtualną) do testowania.

Niektóre poprawki w procesie kompilacji VS mogą sprawić, że wdrożenie do pola testowego stanie się normą, ze zdalnym debugowaniem.

Istnieją inne sposoby rozważenia zmuszenia programistów do opracowania bardziej wydajnego kodu - możesz na przykład uwzględnić cele w zakresie wydajności i wykorzystania pamięci w testach jednostkowych. Wyznaczanie budżetów na wykorzystanie pamięci jest również doskonałym celem. Również ustawianie budżetów wagi strony dla kodu HTML.

Problem nie polega na tym, że deweloper buduje nieefektywny kod na szybkiej maszynie, problem polega na tym, że nie zdefiniowałeś wskaźników wydajności, z którymi należy się zmierzyć.

W ramach wymagań dotyczących produktu należy określić konkretny cel, który można zmierzyć na wszystkich komputerach na podstawie wymaganej obsługi klienta. Istnieje wiele witryn internetowych (Check SpecInt), które umożliwiają powiązanie komputera z innymi typami komputerów.

Jest to dobre z wielu powodów. Pozwala łatwiej zdefiniować minimalny obsługiwany sprzęt, dzięki czemu można ograniczyć liczbę skarg klientów - wszyscy wiemy, że większość programów działa na większości komputerów, to tylko kwestia wydajności - jeśli ustawimy nasze specyfikacje, aby ludzie mieli minimalny zakres wymagań ma racjonalnie akceptowalną wydajność, ograniczasz reklamacje klientów - a następnie, gdy klient dzwoni, możesz użyć testów porównawczych, aby ustalić, czy naprawdę istnieje problem lub czy klient nie jest zadowolony z tego, jak produkt powinien działać.

Jestem przekonany, że wolniejszy komputer do programowania powoduje szybszy kod, ale ma to swoją cenę. Uzasadnieniem jest to, że doświadczyłem tego z pierwszej ręki: mając długi czas dojazdów, kupiłem netbooka do pracy w pociągu, netbook, który jest wolniejszy niż jakikolwiek komputer, który kupiłem w ciągu ostatnich 5 lat. Ponieważ wszystko jest tak wolne, widzę bardzo szybko, gdy coś jest nie do zniesienia na tym netbooku i zdaję sobie sprawę z wolnych miejsc znacznie szybciej (nie trzeba cały czas testować). Praca nad netbookiem naprawdę zmieniła mój rozwój.

Biorąc to pod uwagę, nie opowiadam się za tym, szczególnie w środowisku zawodowym. Po pierwsze, jest to demoralizujące. Sam fakt, że prawie wszyscy mówili, że pomysł nie miał nawet sensu, pokazuje, że programiści źle reagują na ten pomysł.

Po drugie, wolniejsze wszystko oznacza, że ​​rzeczy, które możesz chcieć zrobić na szybkiej maszynie (zajmuje powiedzmy 1 minutę), nie są już tak naprawdę wykonalne na wolnej maszynie, z powodu lenistwa itp. To kwestia zachęty.

Wreszcie: wygenerowany kod może być szybszy, ale prawie na pewno zajmuje więcej czasu.

Punkt 1, NIE! Studio ma być uruchamiane na przyzwoitych komputerach, a wymaganie to stało się mocniejsze z każdą wersją. Możesz zablokować niektóre wersje studia, jeśli włączysz intellisense i użyjesz pojedynczego rdzenia bez HT.

Aby wskazać punkt 2, w projektach testowych jest kilka funkcji, które pozwalają na ograniczenie zasobów. Nie są idealne, ale są tam. Obrazy VPC lub maszyn wirtualnych o niskiej specyfikacji, a także dość dobre zadanie ograniczenia. Kazałem użytkownikom siadać przy złych maszynach, aby od czasu do czasu testowali, aby mogli zobaczyć implikacje żądanych funkcji.

Nie - w rzeczywistości spowodowałoby to więcej błędów, ponieważ nie przeprowadzałyby tyle testów i nie używałyby dodatkowych narzędzi, takich jak profile. Daj im najlepsze maszyny, na jakie możesz sobie pozwolić (w tym sprzęt do akceleracji grafiki, jeśli jesteś programistą gier lub sklepem graficznym) i pozwól im przetestować je w maszynach wirtualnych. Specyfikacje maszyn wirtualnych można w razie potrzeby skalować w górę lub w dół.

Myślę, że to interesujące pytanie i nie zdecydowałbym się na „nie” tak szybko. Moim zdaniem: zależy to od tego, o jakim zespole programistycznym mówimy. Przykład: jeśli prowadzisz grupę, która bierze udział w corocznym konkursie programistycznym ICFP, być może uzyskanie dobrych wyników po krótkim czasie opracowywania klastra HPC niekoniecznie oznacza, że ​​znalezione rozwiązanie jest dobre. To samo można powiedzieć, jeśli piszesz jakiś algorytm naukowy lub numeryczny: na starym AMD Duron 600 MHz z 64 MB pamięci musisz być ostrożny, jak sobie radzisz, a to może wpłynąć nawet na niektóre projekty wybory

Z drugiej strony inteligentny programista / naukowiec / cokolwiek, co i tak powinno być ostrożne. Ale znalazłem, że zapisuję niektóre z moich najlepszych kodów, kiedy w ogóle NIE miałem komputera i musiałem robić notatki na papierze. Może to nie dotyczyć dużych projektów z dużymi ramami, gdy IDE jest absolutnie konieczne.

Jedno jest pewne: szybkie maszyny i dobre natychmiastowe wyniki powodują, że (złe) programiści psują się i mogą być jedną z przyczyn niektórych badziewów, które możemy znaleźć na komputerach.

Pracuję nad pakietem, który zajmuje około godziny, aby zbudować na mojej 8-rdzeniowej maszynie 8G (pełna czysta kompilacja). Mam też stosunkowo niski laptop, na którym testuję. Niski laptop nie obsługuje dwóch pełnych wersji w ciągu jednego dnia roboczego.

Czy jestem bardziej produktywny na szybkiej maszynie z celowymi testami przeprowadzonymi na laptopie, czy powinienem wykonywać wszystkie wersje na laptopie?

Pamiętaj, że to nie są liczby.

Jest to wersja demo, w której zwykle nie muszę codziennie robić czystej kompilacji (mogę wykonać wiele testów na pojedynczych modułach), ale nawet częściowe kompilacje wykazują z grubsza rząd różnicy wielkości w czasie kompilacji / połączenia .

Tak więc prawdziwy problem dotyczy mojej wolniejszej maszyny, typowa wersja jest wystarczająco długa, abym mógł dostać filiżankę kawy, podczas gdy na mojej szybszej maszynie mogę wypić tylko odrobinę kawy.

Z punktu widzenia wykonywania pracy wolę programować na szybkiej maszynie. Mogę znacznie bardziej rzetelnie dotrzymywać terminów. Z drugiej strony wyobrażam sobie, że gdyby zarządzanie zmusiło mnie do programowania na mojej wolnej maszynie, przeglądanie stron internetowych byłoby znacznie większe, a przynajmniej czytanie książek.

Co ciekawe, pracowałem w startupie, w którym to zrobiliśmy. Myślę, że faktycznie działało całkiem nieźle, ale tylko z powodu konkretnej sytuacji, w jakiej się znaleźliśmy. Był to sklep mod_perl, w którym automatyczne przeładowywanie klas faktycznie działało poprawnie. Wszyscy programiści używali vim jako swojego IDE (lub używali oprogramowania do edycji zdalnej). Efektem końcowym było to, że stracono bardzo mało (jeśli w ogóle) czasu na oczekiwanie na kompilację / przeładowanie kodu itp.

Zasadniczo podoba mi się ten pomysł IFF, który ma znikomy wpływ na cykl programowania dla wszystkich programistów i wpływa tylko na działanie twojego kodu w czasie wykonywania. Jeśli Twój kod jest w każdym razie skompilowany, wstępnie przetworzony itp., Dodajesz czas na „naprawę błędu; przetestuj; następną” pętlę, w której pracują programiści.

Od strony interpersonalnej ludzie nigdy nie byli zmuszani do korzystania z wolnych serwerów, ale jeśli korzystaliście z wolnych serwerów, nie musieliście wykonywać żadnej własnej konserwacji ani konfiguracji. Poza tym taka konfiguracja istniała od samego początku, nie wyobrażam sobie próby sprzedaży jej uznanemu zespołowi programistów.

Po ponownym przeczytaniu twojego pierwotnego pytania, przychodzi mi do głowy, że wiecznie mnie przerażają środowiska programistyczne, które różnią się od środowisk produkcyjnych. Dlaczego nie skorzystać z maszyny wirtualnej do wykonania kodu, którą można sparaliżować w czasie wykonywania bez wpływu na stację roboczą dewelopera? Ostatnio używam / kocham VirtualBox.

Tutaj też zamierzam przełamać ten trend.

Anegdota: Pracowałem dla holenderskiej firmy programistycznej, która uaktualniła 286 komputerów do 486-es (tak, jestem taka stara). W ciągu kilku tygodni wydajność wszystkich naszych bibliotek wewnętrznych spadła o 50%, a błędy wzrosły ... Trochę badań wykazało, że ludzie nie zastanawiali się już nad samym kodem podczas procesu debugowania, ale uciekali się do „szybkiego” kolejnego kodu -> kompilacja -> test -> naprawa (kod) itd. cykli.

Powiązane: kiedy założyłem filię dla tej samej firmy w USA, ostatecznie zatrudniłem rosyjskich programistów, ponieważ byli przyzwyczajeni do komputerów z mniejszą liczbą funkcji / mniejszą mocą i byli znacznie wydajniejszymi programistami.

Zdaję sobie sprawę, że były to różne czasy, a zasoby były o wiele mniej dostępne niż dzisiaj, ale nigdy nie przestaje mnie zadziwiać, że przy całym postępie poczynionym w dziedzinie sprzętu wydaje się, że każdy krok naprzód jest negowane przez programowanie sloppier wymagające wyższych specyfikacji minimalnych ...

Stąd ... Uważam, że programiści powinni być zmuszeni do testowania swoich aplikacji na komputerach, które nie przekraczają mocy obliczeniowej i specyfikacji sprzętowej „przeciętnego Joe”.

Sprzęt jest tańszy niż czas opracowywania.

Większość wąskich gardeł znajduje się w bazie danych, a nie na komputerze klienckim, ale nie usprawiedliwia to testowania na wolniejszych komputerach niż programista. Użyj narzędzi testowych do testowania optymalizacji.

Absolutnie nie. Daj swoim programistom najlepsze pieniądze na laptopa, jakie mogą kupić, klawiaturę do wyboru, wiele wspaniałych dużych ekranów, prywatne biuro, brak telefonu, darmowe napoje bezalkoholowe, wszystkie potrzebne książki (które są relevent), coroczne wycieczki na najważniejsze konferencje technologiczne i uzyskasz świetne wyniki. Następnie przetestuj kombinacje sprzęt / oprogramowanie / przeglądarka / przepustowość górnej i dolnej granicy.

To interesująca myśl (danie deweloperom powolnej maszyny może doprowadzić ich do dalszej optymalizacji).

Rozwiązanie to jest jednak lepiej sformułowane - umieść czas reakcji w wymaganiach dotyczących programów i przygotuj maszynę do testowania.

Ponadto, jeśli masz naprawdę kompilator / język whiz-bang, może być w stanie wymyślić różne sposoby generowania kodu i wybrać najlepszy. Pomógłby temu jedynie szybszy komputer.

Inni odpowiedzieli, że generalnie chcesz, aby programiści mieli szybkie maszyny. Zgadzam się. Nie pomijaj pamięci RAM - potrzebujesz tyle pamięci, ile możesz - niektóre procesy kompilacji są bardzo obciążające na dysku.

Rzeczy, które warto rozważyć pozbyć się to program antywirusowy na dyskach kompilacji! To tylko spowalnia i może być niezwykle silnym czynnikiem spowalniającym.

Jeśli to możliwe, możesz pozwolić programistom rozwijać się w systemie Linux. Dostępne narzędzia są znacznie lepsze do wszelkiego rodzaju dodatkowych zadań (po prostu grep dla czegoś w pliku itp.). Pozbywa się to również antywirusa.

Mój Macbook Pro w pracy ma kilka lat. Między Linuxem a Windows (aby przetestować dziwactwa IE) oraz kilkoma przeglądarkami internetowymi i otwartymi terminalami, wirujące koło OSX pokazuje się bardzo często. Zgadnij, co robię, gdy się kręci, siedzę i czekam. W takim przypadku powolna maszyna zmniejsza wydajność.

W przypadku wielu aplikacji problemem jest zmuszenie programistów do testowania zestawów danych w świecie rzeczywistym, zanim zostaną one „wykonane”. W przypadku aplikacji interaktywnych wymagana byłaby podstawowa maszyna testowa / VM.

Pracuję na powolnej maszynie Windows95, co pozwala mi skutecznie pisać sztuczną inteligencję MindForth w Forth i JavaScript.

Zapytanie programistów, czy programiści powinni uzyskać dobry sprzęt, jest jak zapytanie grubasa, czy lubi jedzenie. Wiem, że to subiektywna wymiana, ale nadal ... czy warto zadać nam pytanie? : P

To powiedziawszy, oczywiście zgadzam się z większością: NIE .