it-swarm-eu.dev

Führt die Bereitstellung einer langsameren Entwicklungsmaschine für Entwickler zu einem schnelleren / effizienteren Code?

Angenommen, ich gebe meinen Entwicklern eine schreiend schnelle Maschine. WPF-basiertes VS2010 wird sehr schnell geladen. Der Entwickler erstellt dann eine WPF- oder WPF/e-Anwendung, die auf seiner Box einwandfrei läuft, in der realen Welt jedoch viel langsamer.

Diese Frage besteht aus zwei Teilen ...

1) Wenn ich einem Entwickler eine langsamere Maschine gebe, bedeutet das, dass der resultierende Code schneller oder effizienter sein kann?

2) Was kann ich tun, um meinen Entwicklern eine schnelle IDE Erfahrung) zu bieten und gleichzeitig "typische" Laufzeiterfahrungen zu ermöglichen?

pdate :

Für die Aufzeichnung bereite ich meine ausgeglichene Antwort an das Management vor. Dies ist nicht meine Idee, und Sie helfen mir, die fehlgeleiteten Anfragen meines Kunden zu korrigieren. Vielen Dank, dass Sie mir mehr Munition gegeben haben und Hinweise darauf, wo und wann ich mich dem nähern soll. Ich habe + 1 gültige Anwendungsfälle wie:
- spezifische serverseitige Programmieroptimierungen
- Testlabors
- der möglicherweise Kauf eines besseren Servers anstelle von erstklassigen Grafikkarten

130

absolut

Es ist auch wahr, dass Manager alle Meetings in Pig-Latin durchführen sollten. Es verbessert ihre Kommunikationsfähigkeiten insgesamt, wenn sie beim Sprechen einfacher Sätze benachteiligt werden. Sie müssen sich mehr auf Mimik und Körpersprache verlassen, um ihren Standpunkt zu verdeutlichen, und wir alle wissen, dass dies sowieso mindestens 70% der gesamten Kommunikation ausmacht.

CFOs sollten nur einen Abakus und Kreide verwenden. Andernfalls verlassen sie sich zu sehr auf "Rohdaten" und nicht genug auf ihr "Bauchgefühl".

Und Vizepräsidenten und höher sollten verpflichtet werden, alle wichtigen Geschäftstreffen in ablenkenden Umgebungen wie Golfplätzen abzuhalten, während sie halb berauscht sind. Oh verdammt...

234
Jay Beavers

Die Antwort lautet (ich werde fett sein und sagen) immer

NEIN .

Entwickeln Sie das Beste, was Sie mit Ihrem Budget erreichen können, und testen Sie die Min-Max-Spezifikation der Geräte, für die Sie bereitstellen werden.

Es gibt Emulatoren, virtuelle Maschinen und tatsächliche Maschinen mit Testern, die alle die Leistung testen können, um festzustellen, ob dies ein Faktor ist.

376
Steven Evers

1) Sehr, sehr unwahrscheinlich.Nein, und Ihre Entwickler können Ihrem Kaffee etwas Böses hinzufügen, um ihn vorzuschlagen. Zeit, die Ihre Entwickler damit verbringen, auf das Kompilieren des Codes oder auf die IDE) zu warten, um zu tun, was immer es tut oder wie spät es ist nicht Ausgaben, um den Code besser zu machen. Stört auch ihren mentalen Fluss. Behalten Sie das Problem im Auge, und sie werden dieses Problem viel effizienter lösen.

2) Geben Sie ihnen jeweils einen zweiten PC mit den niedrigsten Spezifikationen, die sie tatsächlich unterstützen sollen, mit einem Schalter KVM), um zwischen diesem und ihrer realen Workstation zu wechseln.

70
BlairHippo

Ich mag lange Kompilierungszeiten. Es gibt mir mehr Zeit, an meinem Lebenslauf zu arbeiten.

43
Wonko the Sane

Das ist eine schreckliche Idee. Sie möchten, dass Ihre Entwickler so produktiv wie möglich sind, was bedeutet, dass Sie ihnen so schnell wie möglich eine Maschine zur Verfügung stellen, damit sie nicht den ganzen Tag darauf warten, dass die Dinge kompiliert werden. (Etwas OT, aber es hilft auch, den Zugriff auf potenziell hilfreiche Websites mit WebSense und dergleichen nicht zu blockieren.) Wenn Sie durch Benutzer eingeschränkt sind, auf denen noch Stone-Age-Technologie ausgeführt wird, benötigen Sie einen Testcomputer mit ähnlichen Spezifikationen, und stellen Sie sicher, dass Sie früh und häufig testen, um sicherzustellen, dass Sie bei der Auswahl der Technologie nicht den falschen Weg einschlagen.

33
o. nate

Die Entwicklung sollte in der bestmöglichen Umgebung erfolgen. Die Tests sollten in der schlechtesten Umgebung durchgeführt werden, die möglich ist.

32

Wenn ich eine langsame Maschine bekommen würde, würde ich meinen Tag damit verbringen, den Entwicklungsprozess zu optimieren und nicht meinen gelieferten Code zu optimieren. Also: NEIN!

27
user6015

Programmierer für eingebettete Systeme stoßen ständig darauf! Und es gibt eine zweiteilige Lösung:

  1. Ihre Anforderungen müssen die X-Leistung auf Y-Hardware angeben.
  2. Testen Sie auf Y-Hardware, und wenn Sie keine X-Leistung erhalten, Dateifehler.

Dann spielt es keine Rolle, an welcher Hardware Ihre Entwickler arbeiten.

Nehmen wir an, schnellere Geräte können Ihren Programmierern eine halbe Stunde am Tag oder 125 Stunden im Jahr ersparen. Nehmen wir an, sie kosten 100.000 US-Dollar pro Jahr mit Vorteilen und Gemeinkosten (für Silicon Valley lächerlich niedrig) oder 50 US-Dollar pro Stunde. Diese 125 Stunden * $ 50/Stunde sind $ 6250. Wenn Sie also weniger als 6250 US-Dollar pro Jahr für die Entwicklung von Entwicklungshardware pro Programmierer ausgeben, sparen Sie Geld.

Das sollten Sie Ihrem Management mitteilen.

Tim Williscroft hat die erste Hälfte davon in einem Kommentar gesagt, und in einer gerechten Welt würde er die Hälfte aller Punkte bekommen, die diese Antwort bekommt.


Hinzugefügt am 24. Oktober:

Mein Ex-Arbeitgeber hatte diese Theorie und sie half ihnen, ungefähr 100 Millionen Dollar wegzupissen.

Sie sind ein in Japan ansässiges Konglomerat, das es gewohnt war, Programmierer in Japan, Korea und China einzustellen. Die Leute dort sind cool, wenn sie beschissene Entwicklungshardware verwenden, 13-Stunden-Arbeitstage verbringen, an ihren Schreibtischen schlafen und kein Leben haben. Als sie ein bekanntes Unternehmen aus dem Silicon Valley erwarben, um ein Linux-basiertes Handy-Betriebssystem zu entwickeln, waren diese dummen Kalifornier, die moderne Ausrüstung wollten, nur weinerliche Primadonnen und hatten eigentlich keinen guten Grund dafür (wie Produktivität).

Vier Jahre später funktionierte das Betriebssystem wie Mist, alle Zeitpläne waren durchgebrannt, und die Kunden waren sauer und kündigten Verträge rechts und links. Schließlich wurde das OS-Projekt abgebrochen und ein großer Prozentsatz der weltweiten Belegschaft des Konglomerats im letzten Jahr entlassen. Und ehrlich gesagt, ich möchte nicht einer der Führungskräfte gewesen sein, die den Aktionären erklären mussten, wohin all das Geld und die Mühe gingen.

Es waren nicht nur die langsamen Entwicklungsmaschinen, die dieses Fiasko verursachten. Es gab viele andere strategische und taktische Fehler - aber sie waren genau so, wo die Leute, die in den Schützengräben arbeiteten, das Zugunglück kommen sahen und sich fragten, warum die Entscheidungsträger dies nicht konnten.

Und der langsame Gang war sicherlich ein Faktor. Wenn Sie unter der Waffe stehen, um pünktlich zu liefern, ist es dann wirklich eine kluge Sache, die Arbeit absichtlich zu verlangsamen?

26
Bob Murphy

In der Programmierung gibt es ein altes Sprichwort: " vorzeitige Optimierung ist die Wurzel allen Übels ". Ich denke, Sie haben es geschafft, eine weitere "Wurzel" (oder zumindest den ersten Zweig) allen Übels zu schaffen. Von nun an können wir sagen, "vorzeitige Entwickler-Deoptimierung ist die Wurzel allen Übels."

Kurz gesagt, die Antwort lautet, dass dies nur Ihre Entwicklungszeit verlangsamt und die weitere Wartung erschwert. Die Kompilierungszeiten werden länger dauern, die Suche nach Code auf der Festplatte wird langsamer, das Online-Finden von Antworten wird länger dauern, und vor allem werden Entwickler damit beginnen, ihren Code vorzeitig zu optimieren, um überhaupt die erforderlichen Funktionen testen zu können.

Dieser letzte Punkt ist das kritischste Thema und wird in vielen anderen Antworten nicht angesprochen. Möglicherweise wird Ihre erste Version in Ordnung gebracht, aber wenn Sie den Code in Zukunft aktualisieren möchten, werden Sie feststellen, dass die vorzeitige Optimierung der Entwickler den Fokus Ihres Codes vom guten Design weggenommen und ihn näher an "Ich muss das machen" herangeführt hat am wenigsten arbeiten, um meinen Job "Code-Stil zu halten. Das Hinzufügen zusätzlicher Funktionen wird schwieriger, da die zu diesem Zeitpunkt ausgewählten Optimierungen möglicherweise nicht erforderlich sind und Ihr Code zusätzlich zu anderen halboptimierten Hacks in einen Pfad mit halboptimierten Hacks eingeschlossen wird.

Stellen Sie sich als Beispiel vor, dass die Mindestsystemanforderung Ihrer aktuellen Version eine Einzelprozessormaschine mit etwas langsamer Geschwindigkeit ist. Sie platzieren Entwickler auf dieser Box und sie entwickeln eine komplizierte Single-Threaded-Lösung, die auf vielen Hacks beruht, weil sie das Produkt schnell entwickeln wollten. Jetzt, 5 Jahre später, haben Sie eine neue Version des Produkts, für die eine Dual-Prozessor-Maschine mindestens erforderlich ist. Sie möchten in der Lage sein, Teile des Programms, die Sie parallel ausführen können, sauber zu trennen, aber die Entscheidung, die Sie vor 5 Jahren getroffen haben und die Ihre Entwickler gezwungen hat, eine hackige Software zu erstellen, hindert Sie jetzt daran, die volle Leistung Ihrer neuen Mindestanforderung zu nutzen .

Was Sie tun sollten, ist, am Ende Ihres Entwicklungszyklus eine Phase hinzuzufügen, in der Sie Abnahmetests für die unteren Grenzfelder durchführen. Sicherlich ist ein Teil des Codes aufgrund der schnelleren Maschine des Entwicklers zu langsam, aber Sie können diesen Teil isolieren und dort optimieren. Der Rest Ihres Codes bleibt sauber und wartbar.

Ich sehe Ihre Frage wie folgt: "Kann ich meine Entwickler zwingen, frühzeitig zu optimieren, indem ich ihnen schlechte Entwicklermaschinen gebe und trotzdem guten Code erhalte?" Und die Antwort ist nein.

20
EntropyFails

Interessante Lektüre, all diese Antworten.

Aber ich denke, die meisten Leute, die hier antworten, verpassen den Punkt. Die Frage, wie ich es lese, ist nicht (zumindest), den Entwicklern wirklich eine P1 zu geben, um schnelleren Code zu erstellen.

Der Punkt ist, dass eine Menge Software heutzutage genauso langsam oder sogar langsamer ist als die Software, die wir im letzten Jahrtausend verwendet haben, trotz sehr viel leistungsfähigerer Computer. Nach den Antworten hier zu urteilen, verstehen die meisten Entwickler diesen Hinweis nicht. Dies ist in Webanwendungen sehr offensichtlich. Diese Seite ist eine sehr gute Ausnahme, aber viele Seiten haben eine Titelseite in 1 MB. Was bekomme ich, wenn ich darauf warte, dass das heruntergeladen wird? Ich weiß es nicht. Ich denke, es scheint sich um eine Unwissenheit des Entwicklers zu handeln, die die Zeit, die der Benutzer dafür aufwenden muss, nicht respektiert, oder noch schlimmer, wenn Sie pro MB bezahlen. Die Sache ist, dass all diese Webseiten nicht einmal hochauflösende Bilder enthalten. Oft ist es nur ein Mistcode, der aus einer Entwicklungsumgebung geliefert wird. Nun, natürlich ist es kein Mistcode, denke ich, aber es bringt mir als Benutzer keinen Gewinn.

Im Allgemeinen geht es nicht nur darum, den Code zu optimieren, sondern auch darum, keine Dinge einzubeziehen, die langsamer werden als die, die es gibt.

Vor ein paar Wochen habe ich ab 1995 einen Laptop gestartet. Windows 3.x war in kürzester Zeit betriebsbereit. Die Datenbank, von der ich einige Daten erhalten sollte, wurde gestartet, bevor die Eingabetaste vollständig freigegeben wurde (zumindest).

Ich weiß, dass wir heute viel mehr aus unserer Software herausholen, aber wir haben auch Computer, die um ein Vielfaches schneller sind. Warum beschließt die Entwicklungsbranche nicht, die Geschwindigkeit der Software von 1995 beizubehalten und die Leute dazu zu bringen, neue Hardware zu kaufen, weil sie neue Funktionen wollen. Heutzutage ist es eher so, als ob die alltäglichen Programme und Websites die Leute dazu zwingen, neue Hardware zu kaufen, um genau die gleichen Dinge zu tun wie früher. Aber natürlich schicker.

Ich muss sagen, ich denke, die Linux-Entwicklung scheint damit besser umzugehen. Linux-Distributionen sind Windows schon seit vielen Jahren weit voraus, selbst wenn es um viele Augenweiden wie animierte Fenster geht. Die Sache ist, dass sie trotzdem an den Computern von heute und sogar gestern gearbeitet haben. Nicht nur auf modernster Hardware.

Inzwischen haben wohl viele Entwickler einen ungesunden Adrenalinspiegel. Ja, ich habe einen Weg gefunden, etwas Frustration von allen zurückzugeben, die vor:
Office SQL Server (Management Console starten) Arcgis (Starten und Verwenden) Acrobat Reader (Starten) Agresso (zumindest als Webanwendung) Windows (Starren und Verwenden, nun, ich habe es nicht versucht 7 noch) .net Webseiten (Download)

und so weiter

Ich fühle mich gut :-)

Prost
Nicklas

15
Nicklas Avén

1) Wenn ich einem Entwickler einen langsameren Computer gebe, bedeutet das, dass der resultierende Code schneller oder effizienter sein kann?

Wir haben in den letzten 6 Jahrzehnten Software entwickelt und haben immer noch Fragen wie diese? Scheint eher ein weiterer Versuch zu sein, Ecken zu schneiden. Nichts für ungut, aber komm schon, denkst du, die Frage ist sogar logisch? Denken Sie so darüber nach (wenn Sie können): Sie möchten ein 4x4-Fahrzeug bauen, das unter rauen Bedingungen, Regen, Schlamm usw. betrieben werden kann. Werden Sie Ihre Ingenieure und die Montagelinie unter die Elemente stellen, um sicherzustellen, dass das resultierende Fahrzeug mit ihnen arbeiten kann?

Ich meine, Jesus Christus! Es gibt Entwicklung und es gibt Tests. Das Testen wird in einer anderen, härteren Umgebung durchgeführt, oder der Entwickler weiß, wie er einen Prüfstand in seiner eigenen Entwicklungsumgebung auf eine für Stresstests geeignete Weise zusammenbaut. Wenn er nicht kann, ersetzen Sie ihn durch einen besseren Entwickler.

2) Was kann ich tun, um meinen Entwicklern eine schnelle IDE Erfahrung) zu bieten und gleichzeitig "typische" Laufzeiterfahrungen zu ermöglichen?

Das sollten Sie Ihren Entwicklern mitteilen. Und wenn sie Ihnen keine objektive und gültige Antwort geben können, müssen Sie sie durch tatsächliche Entwickler ersetzen.

Aber um die Frage zu beantworten, geben Sie Ihren Entwicklern (vorausgesetzt, Sie haben gute Entwickler), guten Tools und guter Hardware das Beste, was Sie sich leisten können. Richten Sie dann eine niedrigste gemeinsame Basisumgebung ein, in der Ihre Software ausgeführt werden muss. Das ist wo Tests stattfinden sollen. Es ist viel besser, eine Testumgebung zu haben , die sich von der Entwicklungsumgebung unterscheidet (vorzugsweise eine, die dies ermöglicht) zu Stresstests.)

Wenn Ihre Entwickler gut sind, sollten sie Ihnen dies mitteilen (vorausgesetzt, Sie haben sie gefragt).

10
luis.espinal

Das führt zu einer Menge verdammter Entwickler. Dieses Zeug ist schon schwer genug, machen wir die Erfahrung nicht noch schlimmer.

Ich würde Sie ermutigen, ähnliche Hardware wie Ihre Benutzer in einer Test- oder QS-Umgebung zu haben, um jedoch Leistungsprobleme auszuräumen. Das ist eine gute Idee.

6
bigtang

Ich werde mich der Norm widersetzen und ja sagen, WENN UND NUR, wenn sie Serversoftware schreiben. Lachen Sie alles, was Sie wollen, aber das effizienteste Team, das ich je gesehen habe, war eine Gruppe von Perl-Leuten mit Wyse-Terminals. Dies war Ende der 1990er Jahre, war ein Off-Shoot-Laden der Universität und sie schrieben räumliche Rastersoftware (die im Grunde nur berechnet). Sie sprachen jedoch mit einigen relativ leistungsstarken RS/6000-Modellen der neuesten Generation.

Um das Interesse an der Veranstaltung zu erhöhen, gab es dort einen blinden Programmierer. Ich war sehr beeindruckt.

alt text

6
Jé Queue

Dies ist keine schlechte Idee - aber Sie möchten, dass Ihre Entwickler eine schnelle Programmierumgebung haben.

Sie können dies möglicherweise implementieren, indem Sie Ihren Programmierern zwei Maschinen zur Verfügung stellen - eine schnelle Entwicklungsbox und eine langsamere Commodity-Box (möglicherweise virtuell) zum Testen.

Durch einige Optimierungen des VS-Erstellungsprozesses kann die Bereitstellung auf der Testbox mit Remote-Debugging zur Norm werden.

Es gibt andere Möglichkeiten, Ihre Codierer zu zwingen, effizienteren Code zu entwickeln. Sie können beispielsweise die Ziele für Leistung und Speichernutzung in Ihre Komponententests einbeziehen. Das Festlegen von Budgets für die Speichernutzung ist ebenfalls ein hervorragendes Ziel. Festlegen von Seitengewichtsbudgets für HTML-Code.

5
damien

Das Problem ist nicht, dass der Entwickler ineffizienten Code auf einem schnellen Computer erstellt. Das Problem ist, dass Sie keine Leistungsmetriken definiert haben, an denen gemessen werden muss.

Als Teil der Produktanforderungen sollte ein spezifisches Ziel definiert werden, das auf allen Computern basierend auf der erforderlichen Kundenerfahrung gemessen werden kann. Es gibt viele Websites (Check SpecInt), auf denen Sie Ihren Computer mit anderen Computertypen in Verbindung bringen können.

Das ist aus vielen Gründen gut. Auf diese Weise können Sie die minimal unterstützte Hardware einfacher definieren, um die Anzahl der Kundenbeschwerden zu begrenzen. Wir alle wissen, dass die meisten Softwareprogramme auf den meisten Computern ausgeführt werden. Es ist nur eine Frage der Leistung. Wenn wir unsere Spezifikationen so einstellen, dass die Mitarbeiter den Mindestanforderungen entsprechen Wenn die Leistung einigermaßen akzeptabel ist, begrenzen Sie Kundenbeschwerden. Wenn ein Kunde anruft, können Sie anhand der Benchmarks feststellen, ob tatsächlich ein Problem vorliegt oder ob der Kunde mit der Funktionsweise des Produkts einfach nicht zufrieden ist.

5
Mike Glasspool

Ich bin überzeugt, dass ein langsamerer Computer für die Entwicklung zu schnellerem Code führt, aber das hat seinen Preis. Das Grundprinzip ist, dass ich dies aus erster Hand erlebt habe: Nachdem ich lange Pendelzeiten hatte, kaufte ich ein Netbook, um im Zug zu arbeiten, ein Netbook, das langsamer ist als jeder Computer, den ich in den letzten 5 Jahren gekauft habe. Weil alles so langsam ist, sehe ich sehr schnell, wenn etwas auf diesem Netbook unerträglich langsam ist, und ich bin mir langsamer Flecken viel schneller bewusst (es ist nicht notwendig, ständig Benchmarks zu erstellen). Die Arbeit an einem Netbook hat meine Entwicklung wirklich verändert.

Abgesehen davon befürworte ich dies nicht, insbesondere in einem professionellen Umfeld. Erstens ist es demoralisierend. Die Tatsache, dass fast alle sagten, die Idee sei nicht einmal sinnvoll, zeigt, dass Programmierer schlecht auf die Idee reagieren.

Zweitens bedeutet alles langsamer zu sein, dass Dinge, die Sie auf einer schnellen Maschine erledigen möchten (dauert etwa 1 Minute), auf einer langsamen Maschine aufgrund von Faulheit usw. nicht mehr wirklich machbar sind. Es ist eine Frage des Anreizes.

Schließlich: Der erstellte Code ist zwar schneller, die Erstellung dauert jedoch mit ziemlicher Sicherheit länger.

5

Punkt 1, NEIN! Studio soll auf anständigen Computern ausgeführt werden, und diese Anforderung ist mit jeder Version leistungsfähiger geworden. Sie können einige Studio-Versionen tatsächlich sperren, wenn Sie Intellisense aktivieren und eine Single-Core-Box ohne HT verwenden.

Zu Punkt 2 gibt es einige Funktionen in den Testprojekten, mit denen Sie einige Ressourcen drosseln können. Sie sind nicht perfekt, aber sie sind da. VPC oder Low Spec VM Images für einen ziemlich guten Job, auch eingeschränkt zu sein. Ich habe Benutzer an schlechten Maschinen sitzen lassen, um gelegentlich Tests durchzuführen, damit sie die Auswirkungen der Funktionen sehen können, die sie haben angefordert haben.

4
Bill

Nein - in der Tat würde dies zu mehr Fehlern führen, da sie nicht so viele Tests durchführen und weniger zusätzliche Tools wie Profiler verwenden. Geben Sie ihnen die besten Maschinen, die Sie sich leisten können (einschließlich Grafikbeschleunigungshardware, wenn Sie eine Spieleentwicklung oder ein Grafikgeschäft sind), und lassen Sie sie in VMs testen. Die VM -Spezifikationen können nach Bedarf vergrößert oder verkleinert werden.

4
JohnL

Ich denke, das ist eine interessante Frage, und ich würde nicht so schnell ein "Nein" sagen. Meine Meinung ist: Es hängt davon ab, um welche Art von Entwicklungsteam es sich handelt. Beispiel: Wenn Sie eine Gruppe leiten, die für den jährlichen ICFP-Programmierwettbewerb kandidiert, bedeutet ein gutes Ergebnis nach einer kurzen Entwicklungszeit in einem HPC-Cluster möglicherweise nicht unbedingt, dass die gefundene Lösung gut ist. Dasselbe gilt, wenn Sie einen wissenschaftlichen oder numerischen Algorithmus schreiben: Auf Ihrem alten AMD Duron 600 MHz mit 64 MB Speicher müssen Sie vorsichtig sein, wie Sie die Dinge erledigen, und dies kann sogar einige Designs beeinflussen Entscheidungen.

Auf der anderen Seite ein kluger Programmierer/Wissenschaftler/was auch immer sowieso vorsichtig sein soll. Aber ich fand mich dabei, einige meiner besten Codes aufzuschreiben, als ich KEINEN Computer AT ALL hatte und Notizen auf Papier machen musste. Dies gilt möglicherweise nicht für große Projekte mit großen Frameworks, wenn ein IDE unbedingt erforderlich ist.

Eines ist sicher: Schnelle Maschinen und gute Sofortergebnisse machen (schlechte) Programmierer verwöhnt und können einer der Gründe für den Mist sein, den wir auf Computern finden.

4
Lorenzo Stella

Ich arbeite an einem Paket, dessen Aufbau auf meinem 8-Kern-8G-Computer ungefähr eine Stunde dauert (vollständig sauberer Build). Ich habe auch einen relativ niedrigen Laptop, auf dem ich teste. Der Low-End-Laptop verwaltet nicht zwei vollständige Builds an einem einzigen Arbeitstag.

Bin ich auf der schnellen Maschine produktiver, wenn einige absichtliche Tests auf dem Laptop durchgeführt werden, oder sollte ich alle meine Builds auf dem Laptop ausführen?

Denken Sie daran, dass dies keine erfundenen Zahlen sind.

Es ist eine manipulierte Demo, da ich normalerweise nicht jeden Tag einen sauberen Build durchführen muss (ich kann viele Tests an einzelnen Modulen durchführen), aber selbst die Teil-Builds zeigen einen Unterschied in der Größenordnung der Kompilierungs-/Verknüpfungszeiten .

Das eigentliche Problem ist also, dass auf meiner langsameren Maschine ein typischer Build lang genug ist, um eine Tasse Kaffee zu holen, während ich auf meiner schnelleren Maschine nur ein wenig Kaffee trinken kann.

Unter dem Gesichtspunkt der Erledigung der Arbeit bevorzuge ich die Entwicklung auf einer schnellen Maschine. Ich kann Termine viel zuverlässiger einhalten. Andererseits stelle ich mir vor, wenn das Management mich dazu bringen würde, auf meinem langsamen Computer zu entwickeln, würde ich viel mehr im Internet surfen oder zumindest Bücher lesen.

4
Stripes

Interessanterweise habe ich bei einem Startup gearbeitet, bei dem wir das gemacht haben. Ich denke, es hat tatsächlich ziemlich gut funktioniert, aber nur aufgrund der spezifischen Situation, in der wir uns befanden. Es war ein mod_Perl-Shop, in dem das automatische Nachladen von Klassen tatsächlich korrekt funktionierte. Alle Entwickler verwendeten vim als IDE der Wahl) (oder verwendeten eine Remote-Bearbeitungssoftware). Das Endergebnis war, dass nur sehr wenig (wenn überhaupt) Zeit verloren ging, bis der Code kompiliert/neu geladen/wurde. usw.

Grundsätzlich gefällt mir diese Idee, wenn IFF für alle Entwickler einen vernachlässigbaren Einfluss auf den Entwicklungszyklus hat und sich nur auf den Laufzeitbetrieb Ihres Codes auswirkt. Wenn Ihr Code ohnehin kompiliert, vorverarbeitet usw. ist, fügen Sie Zeit hinzu, um die Schleife "Fehler beheben; Test; nächste", in der Entwickler arbeiten, zu beheben.

Von der zwischenmenschlichen Seite waren die Leute nie gezwungen, die langsamen Server zu verwenden, aber wenn Sie die langsamen Server verwendeten, mussten Sie keine eigene Wartung oder Einrichtung durchführen. Auch dieses Setup gab es von Anfang an. Ich kann mir nicht vorstellen, es an ein etabliertes Entwicklungsteam zu verkaufen.

Nachdem ich Ihre ursprüngliche Frage noch einmal gelesen habe, fällt mir ein, dass eine Sache, die mich immer wieder erschreckt, Entwicklungsumgebungen sind, die sich von Produktionsumgebungen unterscheiden. Warum nicht ein VM für die Codeausführung verwenden, das Sie zur Laufzeit lähmen können, ohne die Entwicklungsarbeitsstation zu beeinträchtigen? In letzter Zeit habe ich VirtualBox verwendet/geliebt.

3
user6041

Ich werde mich auch hier dem Trend widersetzen.

Anekdote: Ich habe für eine niederländische Softwareentwicklungsfirma gearbeitet, die 286 Computer auf 486-es aktualisiert hat (ja, ich bin so alt). Innerhalb weniger Wochen sank die Leistung aller unserer internen Bibliotheken um 50% und die Fehler nahmen zu ... Eine kleine Untersuchung ergab, dass die Benutzer den Code selbst während des Debugging-Prozesses nicht mehr durchdachten, sondern auf "schnellen" Code nacheinander zurückgingen -> Kompilieren -> Testen -> Fixieren (Code) usw. Zyklen.

Verwandte: Als ich eine Tochtergesellschaft für dasselbe Unternehmen in den USA gründete, stellte ich schließlich russische Programmierer ein, weil sie an PCs mit weniger Funktionen/weniger Leistung gewöhnt waren und viel effizientere Programmierer waren.

Mir ist klar, dass dies unterschiedliche Zeiten waren und die Ressourcen viel knapper waren als heute, aber es überrascht mich immer wieder, wie bei all den Fortschritten, die auf dem Gebiet der Hardware erzielt wurden, das Nettoergebnis zu sein scheint, dass jeder Schritt nach vorne ist negiert durch schlampigere Programmierung, die höhere Mindestanforderungen erfordert ...

Daher ... Ich bin der Meinung, dass Programmierer gezwungen sein sollten, ihre Anwendungen auf Computern zu testen, die die 'Average Joe'-Rechenleistung und die Hardwarespezifikationen nicht überschreiten.

3
John SMythe

Hardware ist kostengünstiger als die Entwicklungszeit.

Die meisten Engpässe befinden sich in der Datenbank, nicht auf dem Client-PC. Dies entschuldigt jedoch nicht das Testen auf langsameren Computern als der Entwickler. Verwenden Sie Testwerkzeuge, um die Optimierung zu testen.

3
Brian

Absolut nicht. Geben Sie Ihren Programmierern das beste Laptop-Geld, das Sie kaufen können, eine Tastatur ihrer Wahl, mehrere große Bildschirme, ein privates Büro, kein Telefon, kostenlose alkoholfreie Getränke, alle gewünschten Bücher (die relevant sind), jährliche Reisen zu wichtigen technischen Konferenzen und Sie erhalten großartige Ergebnisse. Testen Sie dann Hardware-/Software-/Browser-/Bandbreitenkombinationen der oberen und unteren Grenze.

3
addictedtoswdev

Bei vielen Anwendungen besteht das Problem darin, dass Entwickler mit realen Datensätzen testen müssen, bevor sie "fertig" sind. Für interaktive Anwendungen wäre eine Basistestmaschine/VM erforderlich.

2
user6043

Ich arbeite auf einem langsamen Windows95-Computer und kann so effizient künstliche MindForth-Intelligenz in Forth und JavaScript schreiben.

2
Mentifex

Dies ist ein interessanter Gedanke (wenn Entwickler eine langsame Maschine verwenden, können sie möglicherweise mehr optimieren).

Die Lösung ist jedoch besser umrahmt: Stellen Sie die Reaktionszeit in die Anforderungen für Programme und stellen Sie eine Low-End-Maschine zum Testen zur Verfügung.

Wenn Sie einen wirklich hervorragenden Compiler/eine Sprache haben, kann er möglicherweise verschiedene Methoden entwickeln, um Code zu generieren und den besten auszuwählen. Das würde nur ein schnellerer Computer helfen.

2
Paul Nathan

Andere haben geantwortet, dass Entwickler im Allgemeinen schnelle Maschinen haben sollen. Genau. Überspringen Sie nicht RAM - Sie möchten so viel Speicher wie möglich - einige Build-Prozesse beanspruchen die Festplatte sehr stark.

Dinge, die Sie vielleicht in Betracht ziehen sollten, um Antivirus auf Build-Laufwerken loszuwerden! Das verlangsamt sich nur und kann ein extrem starker Verlangsamungsfaktor sein.

Möglicherweise möchten Sie die Entwicklungen nach Möglichkeit unter Linux entwickeln lassen. Die Tools dort sind viel besser für alle Arten von zusätzlichen Aufgaben (suchen Sie einfach nach etwas in einer Datei usw.). Dadurch wird auch das Antivirus beseitigt.

2
user1249

Programmierer zu fragen, ob Programmierer gute Hardware bekommen sollten, ist wie einen dicken Mann zu fragen, ob er Essen mag. Ich weiß, dass dies der subjektive Austausch ist, aber trotzdem ... lohnt es sich, uns die Frage zu stellen? : P.

Das heißt, ich stimme natürlich der Mehrheit zu: NEIN .

2
Matthew Read

Ich bin versucht, kategorisch "Nein" zu sagen, aber lassen Sie mich eine aktuelle Erfahrung mitteilen: Jemand in unserem Projekt hat an Code gearbeitet, um Daten in die Datenbank zu importieren. Zu dieser Zeit hatte er den ältesten PC in unserer Gruppe, vielleicht sogar die gesamte Organisation. Mit VS 2008 hat es gut funktioniert, aber natürlich hätte eine schnellere Maschine die Erfahrung verbessert. Wie auch immer, irgendwann wurde der Prozess, den er schrieb, während des Testens bombardiert (und das war, bevor er voll funktionsfähig war). Er hatte kein Gedächtnis mehr. Die Ausführung des Prozesses dauerte mehrere Stunden, bevor er bombardiert wurde. Denken Sie daran, soweit wir wussten, dass dies das ist, was die Benutzer hätten verwenden müssen.

Er bat um mehr RAM. Sie lehnten ab, da er in 3-4 Wochen eine neuere Maschine bekam und die alte weggeworfen werden würde.

Denken Sie daran, dass die Optimierungsphilosophie dieses Typen lautet: "Wir haben schnelle Maschinen mit viel RAM" (seine und einige Maschinen sind sowieso ausgeschlossen). Warum also wertvolle Programmierzeit für die Optimierung verschwenden? Die Situation zwang ihn jedoch, den Algorithmus so zu ändern, dass er speichereffizienter ist, damit er auf seinem 2-GB-Computer (mit XP) ausgeführt werden kann. Ein Nebeneffekt des Umschreibens ist, dass der Prozess auch viel, viel schneller als zuvor ausgeführt wurde . Auch die Originalversion hätte irgendwann sogar mit 4 GB bombardiert, als mehr Daten importiert wurden - es war schlicht und einfach ein Speicherfresser.

Soooo ... Während ich im Allgemeinen "Nein" sagen würde, ist dies ein Fall, in dem der Entwickler mit einer weniger leistungsstarken Maschine zu einem besser optimierten Modul führte und die Benutzer davon profitieren (da dies kein Prozess ist, der dies tun muss) sehr oft ausgeführt, hatte er zunächst nicht die Absicht, es so oder so zu optimieren, so dass sie mit der Originalversion hängen geblieben wären, wenn die Maschine genug gehabt hätte RAM, um ein paar große Tests durchzuführen .. .) Ich kann seinen Standpunkt verstehen, aber ich persönlich mag die Idee nicht, dass Benutzer 8 Stunden warten müssen, bis ein Prozess abgeschlossen ist, wenn er in einem Bruchteil dieser Zeit ausgeführt werden kann.

Vor diesem Hintergrund sollten Programmierer in der Regel über leistungsstarke Maschinen verfügen, da die meisten Entwicklungen sehr intensiv sind. Es sollte jedoch sorgfältig darauf geachtet werden, dass die Tests auf Maschinen mit dem kleinsten gemeinsamen Nenner durchgeführt werden, um sicherzustellen, dass der Prozess nicht bombardiert wird und die Benutzer Paint nicht den ganzen Tag lang trocken beobachten. Aber das wurde schon gesagt. :) :)

2
MetalMikester

Beim Lesen der Frage und der Antworten bin ich von der Vehemenz des NO-Falls verblüfft.

Ich arbeite seit 25 Jahren in der Softwareentwicklung und kann ohne zu zögern sagen, dass Programmierer eine Reihe von Dingen benötigen, um guten Code zu entwickeln:

  • Eine vernünftige Entwicklungsumgebung. Kein Dinosaurier. Es muss auch nicht Edge bluten. Gut genug, um nicht frustrierend zu sein.

  • Eine gute Spezifikation (wie viel wird ohne schriftliche Spezifikation gemacht?)

  • Gutes und unterstützendes Management.

  • Ein vernünftiger Entwicklungsplan.

  • Ein gutes Verständnis der Benutzer und der Umgebung, die die Benutzer haben werden.

In diesem letzten Punkt müssen Entwickler darüber nachdenken, was die Benutzer verwenden werden. Wenn die Benutzer Supercomputer haben und Atom-Splitting-Simulationen durchführen oder etwas, bei dem die Leistung viel Geld kostet und die Berechnungen viele Stunden dauern, zählt das Denken an die Leistung.

Wenn die Benutzer über 286 Steam-Laptops verfügen, führt die Entwicklung und Durchführung von Entwicklertests durch Entwickler auf dem neuesten 47-GHz-Core i9000 zu einigen Problemen.

Diejenigen, die sagen "Gib Entwicklern das Beste und teste es", haben teilweise recht, aber dies hat ein großes MENTAL-Problem für die Entwickler. Sie schätzen die Benutzererfahrung erst, wenn es zu spät ist - wenn der Test fehlschlägt.

Wenn das Testen fehlschlägt - Architekturen wurden festgelegt, das Management hat Versprechen abgegeben, viel Geld ausgegeben und dann wird es zu einer Katastrophe.

Entwickler müssen vom ersten Tag an gerne denken, verstehen und sich in der Zone der Benutzererfahrung befinden.

Diejenigen, die schreien "oh nein, so funktioniert es nicht", sprechen ihr Whatsit aus. Ich habe das schon oft gesehen. Die übliche Antwort der Entwickler lautet: "Sagen Sie den KUNDEN, sie sollen einen besseren Computer kaufen", was den Kunden effektiv beschuldigt. Nicht gut genug.

Das bedeutet also, dass Sie mehrere Probleme haben:

  • Halten Sie die Entwickler bei Laune und pissen Sie das Management an, und erhöhen Sie die Wahrscheinlichkeit, dass das Projekt scheitert.

  • Verwenden Sie langsamere Maschinen für die Entwicklung, mit dem Risiko, die Entwickler zu verärgern, aber konzentrieren Sie sich auf das, was wirklich wichtig ist.

  • Stellen Sie 2 Maschinen auf den Entwickler-Schreibtisch und zwingen Sie sie, den CLUNKER zu testen (was sie nicht tun, weil er verachtet wird ... aber zumindest ist es dann sehr klar, wenn es im Test Leistungsprobleme gibt).

Erinnern Sie sich an Batch-Systeme und Lochkarten? Die Leute warteten eine Stunde oder einen Tag auf die Wende. Sachen wurden erledigt.

Erinnern Sie sich an alte Unix-Systeme mit 5-MHz-Prozessoren? Dinge wurden erledigt.

Techo-Geeks lieben es, die blutende Kante zu verfolgen. Dies fördert das Basteln, nicht das Denken. Etwas, über das ich im Laufe der Jahre mit mehr jungen Entwicklern gestritten habe ... als ich sie aufforderte, die Finger von der Tastatur zu entfernen und mehr Zeit damit zu verbringen, den Code zu lesen und nachzudenken.

Bei der Entwicklung von Code gibt es keinen Ersatz für das Denken.

In diesem Fall ist mein Gefühl - herauszufinden, was wirklich wichtig ist. Erfolg des Projekts? Ist dies eine Übung, die ein Unternehmen macht/tötet? Wenn ja, können Sie es sich nicht leisten, zu scheitern. Sie können es sich nicht leisten, Geld für Dinge zu sprengen, die im Test fehlschlagen. Da der Test im Entwicklungszyklus zu spät ist, werden die Auswirkungen eines Fehlers zu spät festgestellt.

[Ein im Test gefundener Fehler kostet etwa das 10-fache der Behebung eines Fehlers, den ein Entwickler während der Entwicklung gefunden hat.

Und ein Fehler, der im Test gefunden wurde, kostet ungefähr das 100-fache der Behebung des Fehlers, der während der Phase des Architekturentwurfs ausgearbeitet wurde.]

Wenn dies kein Deal Breaker ist und Sie Zeit und Geld zum Brennen haben, verwenden Sie die Entwicklungsumgebung von Bleeding Edge und erleiden Sie die Hölle voller Testfehler. Andernfalls finden Sie einen anderen Weg. Unteres Ende h/w oder 2 Maschinen auf jedem Schreibtisch.

2
quickly_now

Mein Macbook Pro bei der Arbeit ist ein paar Jahre alt. Zwischen Linux und Windows (zum Testen von IE Macken) vms) sowie einigen geöffneten Webbrowsern und Terminals zeigt sich das OSX-Spinnrad häufig. Ratet mal, was ich mache, wenn es sich dreht, ich sitze und warten. In diesem Fall verlangsamt eine langsame Maschine die Produktivität.

2
Thierry Lam

Ich sage, Entwickler brauchen das beste verfügbare Entwicklungssystem - aber das bedeutet nicht unbedingt das schnellste. Dies kann durchaus ein modernes, aber relativ langsames System mit rein passiver Kühlung bedeuten, um beispielsweise das Rauschen auf ein Minimum zu beschränken.

Eine Sache - ein Entwicklungssystem sollte einigermaßen neu sein und absolut mehrere Kerne haben.

Ein alter PC mag in einer frühen Art und Weise attraktiv klingen, aber ein Pentium 4 zum Beispiel kann tatsächlich schneller (pro Kern) sein als einige aktuelle Chips. Das bedeutet, dass ich einen Entwickler auf die Verwendung eines P4-Systems beschränke (eigentlich das, was ich jetzt verwende - obwohl das mein persönliches Budgetproblem ist) ...

  1. Sie fördern die Entwicklung nicht gleichzeitiger Software, die von den aktuellen Mainstream-Mehrkernsystemen nicht profitiert.
  2. Selbst wenn Multithread-Software entwickelt wird, werden Fehler möglicherweise nicht (oder zumindest nicht frühzeitig) bemerkt, da beim Testen auf einem Single-Core-System möglicherweise keine Probleme im Zusammenhang mit der Parallelität auftreten.
  3. Multithread-Software kann schwerwiegende Leistungsprobleme verursachen, die sich bei Multi-Core-Prozessoren erheblich verschlechtern können. Eine Ursache wäre ein Thrashing des Festplattenkopfs (was zu einem tausendfach langsameren Zugriff auf Daten führen kann), wenn einzelne Threads sequentiellen Zugriff haben, jedoch jeweils auf einen anderen Teil der Festplatte. Dies kann sogar auf älteren langsameren PCs verschwinden, z. Mit zwei alten 160-GB-Laufwerken anstelle eines 1-TB-Laufwerks kämpfen diese Threads möglicherweise nicht mehr miteinander um den Zugriff auf dieselbe Festplatte.

Es gibt auch Probleme mit PCs, die zu begrenzt sind, um virtuelle Maschinen gut zu unterstützen - z. zum Testen auf mehreren Plattformen.

1
Steve314

Die Antwort liegt in der Mitte.

Haben Sie eine schnelle Box, um die Entwicklungsumgebung auszuführen (z. B. Eclipse)

Und noch eine Slow Box zum Testen der Ausgabe. Dies ist besonders wichtig für Web-Apps.

Side-by-Side-Bildschirme, einer für jede Box.

Wenn der Code im Ausgabefeld akzeptabel ist, ist er für die meisten Benutzer mehr als akzeptabel.

Schnelle Entwicklungsboxen machen Programmierer faul. Suchen Sie beispielsweise jedes Mal nach einem Element im DOM, wenn es benötigt wird. Finden Sie es einmal und zwischenspeichern Sie das Ergebnis.

Sie werden den Unterschied bei einer langsamen Box, die ausgeführt wird, wirklich bemerken IE 6 ....

1
David Semeria

Diese Theorie ist einfältig und veraltet. Es war damals wahr.

Ich erinnere mich, dass ich mehr Zeit damit verbracht habe, meine Turbo Pascal-Produkte auf meinem Pre-Pentium-Computer zu optimieren. Es hat gerade vor dem Jahr 2000 Sinn gemacht, geschweige denn seitdem. Heutzutage optimieren Sie nicht für 10 Jahre alte Hardware. Es reicht aus, Software zu testen, um Engpässe zu finden. Da alle hier agieren, bedeutet dies nicht, dass die Produktivität der Entwickler (und damit der Optimierung) damit korreliert, dass sie veraltete Hardware für die Entwicklung erhalten.

1
mario

1) Wenn ich einem Entwickler eine langsamere Maschine gebe, bedeutet das, dass der resultierende Code schneller oder effizienter sein kann?

Gute Entwickler sind verwöhnt. Wenn sie sehen, dass sie in Ihrem Unternehmen schlechte Werkzeuge bekommen, werden sie woanders arbeiten. (Gute Entwickler haben normalerweise die Wahl, woanders hinzugehen)

1

Ist die Antwort auf diese Frage nicht ein klares "NEIN", unabhängig davon, wen Sie fragen?

Fragen Sie Ihre Grafiker, ob sie eine langsamere Maschine erhalten sollen.

Fragen Sie Ihre Autoren, ob sie eine langsamere Maschine einer schnelleren vorziehen würden.

Fragen Sie Ihre Verwaltungsassistenten, ob sie eine langsamere oder schnellere Maschine bevorzugen.

Alle werden sagen, dass sie mit einer schnelleren Maschine produktiver sind.

1
Barry Brown

Ich kann mir das Profil nur vorstellen, wenn ich eine langsame Maschine benutze. Huch.

Zusamenfassend. Auf keinen Fall.

Haben Sie auch mindestens 4 GB RAM, damit Sie 2 GB auf Ihrem Hauptcomputer haben können, 1 für eine VM und die andere 1 für den zusätzlichen Speicher, den die VM benötigt) und damit Sie Speicherplatz haben.

Auch zwei Prozessoren sind ein Muss. Wenn eine App die CPU sperrt/auffrisst, muss der Entwickler nicht schmerzhaft etwas tun, um die Strg-Alt-Taste zu drücken.

0
user2528

Gehen wir hier gegen den Strom: JA. Zumindest ist dies seit Jahrzehnten die allgemeine Weisheit in der Branche (außer natürlich unter Entwicklern, die immer wütend werden, wenn sie nicht wie Könige behandelt werden und die neuesten Geräte und Computer erhalten).

Natürlich gibt es einen Punkt, an dem das Reduzieren des Computers des Entwicklers sich nachteilig auf seine Arbeitsleistung auswirkt, da es zu langsam wird, um die Anwendungen auszuführen, die er ausführen muss, um seine Arbeit zu erledigen. Aber dieser Punkt ist weit entfernt von einem Computer über 10000 US-Dollar mit 6 GB RAM, 2 4 GB-Videokarten, einer High-End-Soundkarte, 4 Bildschirmen usw. usw.

Ich hatte noch nie eine High-End-Maschine im Einsatz und sie hat mich nie wesentlich verlangsamt, solange sie anständig war (und die wenigen echten Maschinen, die nicht dem Standard entsprachen, wurden schnell ersetzt, als ich zeigte, wie sie mich verlangsamten).

0
jwenting

Die Laufzeitgeschwindigkeit auf dem Entwicklercomputer ist so irrelevant, es sei denn, Sie möchten Ihren Entwickler dafür rächen oder bestrafen, dass er langsamen Code geschrieben hat und die Zielbereitstellungsumgebung nicht kennt.

Als Manager sollten Sie sicherstellen, dass die Entwickler das Ziel des Projekts kennen und stets auf dem richtigen Weg sind. In Bezug auf das Problem mit der Zielmaschine, das wir diskutieren, könnte dies durch frühzeitiges und häufiges Testen auf langsamen Maschinen verhindert werden, nicht durch langsame Verwendung und Leiden.

Die langsame Laufzeit verlangsamt auch die Entwicklung, da die meisten Programmierer die Code-and-Test-Methode verwenden. Wenn die Laufzeit langsam ist, ist auch ihre Aufgabe langsam.

0
tia