it-swarm.dev

Schnelleres Codieren (ohne Qualitätseinbußen)

Ich bin seit mehreren Jahren ein professioneller Programmierer. Die Kommentare zu meinem Code waren im Allgemeinen die gleichen: Schreibt großartigen Code, gut getestet, aber könnte schneller sein .

Also wie werde ich ein schnellerer Codierer ohne Qualitätseinbußen? Um dieser Frage willen werde ich den Bereich auf C # beschränken, da ich dies hauptsächlich (zum Spaß) codiere - oder Java, das in vielerlei Hinsicht ähnlich genug ist.

Dinge, die ich bereits mache:

  • Schreiben Sie die minimale Lösung, mit der die Aufgabe erledigt wird
  • Schreiben Sie eine Reihe automatisierter Tests (verhindert Regressionen)
  • Schreiben (und verwenden) Sie wiederverwendbare Bibliotheken für alle möglichen Dinge
  • Verwenden Sie bekannte Technologien dort, wo sie gut funktionieren (z. B. Ruhezustand).
  • Verwenden Sie Entwurfsmuster dort, wo sie passen (z. B. Singleton).

Diese sind alle großartig, aber ich habe nicht das Gefühl, dass meine Geschwindigkeit mit der Zeit zunimmt. Ich kümmere mich darum, denn wenn ich etwas tun kann, um meine Produktivität zu steigern (sogar um 10%), ist das 10% schneller als meine Konkurrenten. (Nicht dass ich welche hätte.)

Außerdem habe ich diese Rückerstattung immer wieder von meinen Managern erhalten - ob es sich um eine kleine Flash-Entwicklung oder eine Java/C++ - Unternehmensentwicklung handelte.

Edit : Es scheint viele Fragen zu geben, was ich unter schnell verstehe und woher ich weiß, dass ich langsam bin. Lassen Sie mich mit einigen weiteren Details klarstellen.

Ich habe in kleinen und mittleren Teams (5-50 Personen) in verschiedenen Unternehmen über verschiedene Projekte und verschiedene Technologien (Flash, ASP.NET, Java, C++) gearbeitet. Die Beobachtung meiner Manager (die sie mir direkt sagten) ist, dass ich "langsam" bin.

Ein Teil davon ist, dass eine bedeutende Anzahl meiner Kollegen Qualität für Geschwindigkeit geopfert hat; Sie schrieben Code, der fehlerhaft, schwer zu lesen, schwer zu warten und schwer zu automatisieren war. Mein Code ist im Allgemeinen gut dokumentiert, lesbar und testbar.

Bei Oracle würde ich Fehler durchweg langsamer lösen als andere Teammitglieder. Ich weiß das, weil ich entsprechende Kommentare bekommen würde; Dies bedeutet, dass andere (ja, ältere und erfahrene) Entwickler meine Arbeit in kürzerer Zeit als nötig bei nahezu gleicher Qualität (Lesbarkeit, Wartbarkeit und Testbarkeit) erledigen können.

Warum? Was vermisse ich? Wie kann ich das verbessern?

Mein Endziel ist einfach: Wenn ich heute in 40 Stunden Produkt X herstellen und mich irgendwie verbessern kann, damit ich morgen nach 20, 30 oder sogar 38 Stunden dasselbe Produkt erstellen kann, dann möchte ich das wissen - wie komme ich dort hin? Welchen Prozess kann ich verwenden, um mich kontinuierlich zu verbessern? Ich hatte gedacht, es geht darum, Code wiederzuverwenden, aber das scheint nicht genug zu sein.

148
ashes999

Ich mag Jeff Atwoods Ansatz, der hier zu finden ist http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Grundsätzlich verweist er in dem Artikel auf eine Passage aus dem Buch Art & Fear von David Bayles und Ted Orland. Die Passage lautet:

Der Keramiklehrer gab am Eröffnungstag bekannt, dass er die Klasse in zwei Gruppen aufteilen werde. Alle auf der linken Seite des Studios, sagte er, würden nur nach der Menge der von ihnen produzierten Arbeit bewertet, alle auf der rechten Seite nur nach ihrer Qualität. Sein Verfahren war einfach: Am letzten Tag des Unterrichts brachte er seine Personenwaage mit und wog die Arbeit der Gruppe "Menge" ab: 50 Pfund Töpfe mit der Bewertung "A", 40 Pfund mit der Note "B" und so weiter. Diejenigen, die mit "Qualität" bewertet wurden, mussten jedoch nur einen Topf produzieren - wenn auch einen perfekten -, um ein "A" zu erhalten. Nun, es kam die Zeit der Benotung und eine merkwürdige Tatsache tauchte auf: Die Werke von höchster Qualität wurden alle von der Gruppe produziert, die nach Quantität benotet wurde. Es scheint, dass die "Quantitäts" -Gruppe, während sie fleißig Arbeitshaufen produzierte - und aus ihren Fehlern lernte - die "Qualitäts" -Gruppe über Perfektion theoretisiert hatte und am Ende für ihre Bemühungen kaum mehr zu zeigen hatte als grandiose Theorien und ein Haufen toten Lehms.

Wenn Sie sich die Hände schneller und häufiger schmutzig machen, verbessern Sie Ihre Fähigkeiten besser, als wenn Sie Ihre Zeit damit verbringen, die "perfekte" Art und Weise zu studieren und zu theoretisieren. Mein Rat, üben Sie weiter, halten Sie sich mit der Technologie auf dem Laufenden und studieren Sie Design.

160
chrisw

Eine Möglichkeit, die sonst niemand erwähnt zu haben scheint, ist, dass es Ihnen gut geht und Ihre Manager nicht sehr gut sind. Wie messen sie die Produktivität? Können sie Ihnen konkrete Beispiele geben oder ist es nur eine allgemeine Wahrnehmung? Haben sie die Zeit berücksichtigt, die sie damit verbracht haben, die Arbeit anderer Menschen im Vergleich zu Ihrer zu reparieren?

Ich habe viele Leute gesehen, die Anerkennung dafür bekommen, dass sie Dinge erledigt haben, während der Rest ihres Teams das Chaos behebt, das sie hinterlassen haben.

72
pdr

Das meiste, was Menschen denken wichtig ist, ist nicht wichtig. Die Schreibgeschwindigkeit ist nicht wichtig. Schnellere Maschinen oder Werkzeuge sind nicht wichtig. Wir sind keine Schreibkräfte oder Maschinenbediener. Wir sind Vordenker. Wir sind Entscheidungsträger .

Was ist wichtig ist, ist die Verwendung von Feedback, um Ihren Entscheidungsprozess kontinuierlich zu verbessern. Der einzige Weg, dies zu tun, wie das Erlernen anderer Fähigkeiten, ist durch Erfahrung, zielgerichtet Übung und kontinuierliches Feedback.

  • Arbeiten Sie an Nebenprojekten.
  • Arbeiten Sie an Open Source-Projekten.
  • Arbeiten Sie mit Entwicklern zusammen, die besser sind als Sie. Paar Programm!
  • Setzen Sie sich neuen Werkzeugen und Techniken aus. Behalten Sie, was funktioniert.
  • Führen Sie Programmierübungen durch, um Ihren Entscheidungsapparat * zu trainieren.
  • Überwachen Sie Ihre Verbesserung anhand objektiver Metriken wie Fehlerrate und -geschwindigkeit sowie subjektiver Metriken wie Codequalität und Fitness.

Schließlich: Denken Sie daran, dass Geschwindigkeit ohne Qualität nutzlos ist und umgekehrt. Um Ihren Nutzen zu maximieren, finden Sie ein Gleichgewicht zwischen diesen Spannungen.

* http://codekata.pragprog.com/

39
Rein Henrichs

Es ist durchaus möglich, dass Sie tatsächlich aufgefordert werden, etwas Qualität für eine höhere Geschwindigkeit zu opfern.

In einigen Entwicklungsumgebungen1Es ist einfach nicht die zusätzliche Zeit wert, etwas Poliertes zu produzieren, wenn "gerade gut genug" ausreicht.


1 - Ich denke insbesondere an "internen Werkzeugschmied", aber es gibt wahrscheinlich andere.

25
Michael Shaw

Es hört sich so an, als ob Sie all die guten Dinge tun - das wird Sie mittelfristig schneller machen, daher ist es nicht offensichtlich, ob Sie tatsächlich langsam sind. Nur du weißt das wirklich. (aber es ist eine sehr reale Möglichkeit - PeopleWare behauptet einen bis zu 10-fachen Produktivitätsunterschied zwischen Entwicklern für dieselbe Aufgabe).

Ich habe also einige Vorschläge für Sie:

  1. Zeit ist eine relative Sache, also ist das Problem vielleicht nicht Ihre tatsächliche Geschwindigkeit, sondern die Wahrnehmung der Zeit, die Sie geben. Sie könnten implizieren, dass es eine Woche dauern wird, aber am Ende zwei Wochen verbringen, während andere 3 Wochen verbringen könnten ... aber Sie sehen nur 1 Woche langsam aus.

  2. Da Sie dieses Feedback häufig erhalten, ist es vielleicht an der Zeit, mit Ihrem Manager und Kollegen zu sprechen, um zu sehen, was sie sagen - es muss viel von ihnen lernen.

  3. Führen Sie eine Paarprogrammierung mit einem Entwickler mit "schneller Qualität" durch, um festzustellen, ob Sie den Unterschied erkennen können.

12
Stephen Bailey

Alle Fragen, die die Leute gestellt haben, ob Sie wirklich langsam sind oder nicht, sind dumm. Ein schnellerer Programmierer zu werden, ohne die Qualität zu beeinträchtigen, ist immer ein gutes Ziel, egal wie langsam oder schnell Sie bereits sind. Dies ist mein oberstes Ziel als Programmierer und ich werde niemals fertig sein. Ich versuche immer schneller zu werden, ohne die Qualität zu beeinträchtigen. Ich bin davon besessen. Folgendes hat bisher in der Reihenfolge der Hilfsbereitschaft für mich funktioniert, zusammen mit einigen experimentellen Ideen am Ende:

1) Hören Sie nie auf zu lernen: Erfahren Sie alles über das Programmieren und Verwenden von Computern im Allgemeinen. Finden Sie Bereiche, in denen Sie schwach sind, und lernen Sie sie. Auch wenn es völlig unabhängig von Ihrer Arbeit und C # zu sein scheint, garantiere ich, dass Sie, wenn Sie danach suchen, häufig Möglichkeiten finden, es auf das anzuwenden, was Sie tun. Beim Lernen geht es auch um Erfahrung. Lesen Sie also nicht nur Dinge, sondern probieren Sie sie aus und erweitern Sie Ihre Fähigkeiten. Wenn Sie an Windows gewöhnt sind, probieren Sie Unix aus oder umgekehrt. Wenn Sie normalerweise IDEs verwenden möchten, versuchen Sie es mit Befehlszeilentools und Texteditoren oder umgekehrt. Wenn Sie von einem Werkzeug oder einer Technologie hören, von der Sie vorher noch nichts gehört haben oder von denen Sie nicht viel wissen, geben Sie der Versuchung nicht nach, weiterzumachen. Schlag es nach! Haben Sie keine Angst, über den Tellerrand hinaus zu denken und experimentelle neue Technologien zu erlernen, die andere für unpraktisch halten. Wir fangen gerade erst an, die Oberfläche der produktiven Programmierung zu kratzen.

2) Projekte aufteilen: Versuchen Sie, Ihre Projekte in Miniprojekte aufzuteilen. Versuchen Sie, jeden Tag oder höchstens alle paar Tage eine neue Version zu veröffentlichen. Fragen Sie sich: "Was ist die Mindestmenge an Funktionen, die ich freigeben kann, und geben Sie dennoch etwas frei, das für den Benutzer nützlich ist." Dies ist eine Fähigkeit, die Sie dadurch lernen werden. Möglicherweise müssen Sie Ihre Manager davon überzeugen, dies zuzulassen, aber sie werden in der Regel recht schnell mit den Ergebnissen zufrieden sein. Auf diese Weise werden Sie feststellen, dass Dinge, von denen Sie dachten, dass sie für Ihre Funktion wesentlich sind, tatsächlich zusätzliche Funktionen sind, die später entwickelt werden können. Auf diese Weise können Sie und Ihre Manager nur die wichtigsten Funktionen anstelle aller Funktionen priorisieren, die sich auf die Funktionen beziehen, an denen Sie arbeiten. Dies ermöglicht es Ihnen, schneller zu denken, indem Sie Ihren Geist klar und konzentriert halten. Sie werden wiederum legitimerweise schneller programmieren. Ihre Manager oder zumindest die Manager Ihres Managers werden wahrscheinlich auch feststellen, dass Sie jetzt noch schneller programmieren als Sie wirklich sind, weil Sie mehr Releases herausbringen. Ein weiterer großer Vorteil davon ist, dass Sie viel besser einschätzen können, wie lange die Veröffentlichung dauern wird, und Ihre Manager werden Sie dafür lieben. Da Sie bereits viele automatisierte Tests durchführen, sollten Sie keine Probleme mit häufigen, stabilen Releases haben. Möglicherweise müssen Sie Ihr automatisiertes Build-System jedoch verbessern. Ich empfehle dringend, das Buch Continuous Delivery in der Martin Fowler-Reihe zu lesen. Es ist schwer zu lesen und weil es sich extrem wiederholt, aber immer noch sehr hilfreich ist.

3) Verwenden Sie die Pomodoro-Technik und passen Sie an, was für Sie nicht funktioniert. Wenn Sie dies mit Nummer 2 in dieser Liste kombinieren, erhalten Sie einen RIESIGEN Produktivitätsschub.

4) Lerne Vim. Selbst wenn Sie diese Befehle in Visual Studio über ViEmu oder in Eclipse über ein Plugin oder in Emacs verwenden, werden Sie an Produktivität gewinnen. Der beste Weg, um Vim zu lernen, besteht darin, es zu verwenden und sich zu zwingen, es niemals zu deaktivieren (deaktivieren/zu Ihren alten Werkzeugen zurückkehren), bis Sie es beherrschen. Anfangs ist es schmerzhaft, aber Sie werden niemals zurück wollen und sogar zusammenzucken wollen, wenn Sie ohne es arbeiten müssen. Einige würden sagen, dass dies Ihre Geschwindigkeit nicht wesentlich erhöhen wird. Aber schneller ist schneller, besonders wenn das Lesen und Ändern von Code WAS WE DO) ist, und ich habe gelegentlich viel Zeit damit gespart.

5) Letzteres wird nicht unbedingt empfohlen, da ich nicht sicher bin, ob es eine gute Idee ist, und es kann Ihre Produktivität tatsächlich verringern, aber ich werde es trotzdem durchgehen. Sie könnten versuchen, mehr Abnahmetests und weniger Komponententests durchzuführen, oder zumindest sicherstellen, dass Sie einige Abnahmetests durchführen. Ich hatte Erfolg mit SpecFlow, aber ich vermute, dass es da draußen etwas Besseres gibt. Sogar das Schreiben der Spezifikationen kann ziemlich technisch sein. Vielleicht möchten Sie, dass Ihr Manager/Kunde zuerst eine grobe Entwurfsversion schreibt, die Sie erheblich ändern, oder Sie schreiben das Ganze selbst und lassen sie einfach lesen und in Ordnung bringen. Dies wird Ihnen bei Nummer 2 aus dieser Liste helfen. Auch Abnahmetests können praktischer sein und erfordern weniger Code als Unit-Tests. Das heißt nicht, dass sie sie ersetzen, verschiedene Werkzeuge für verschiedene Dinge. Wenn Sie jedoch viele Abnahmetests durchführen, können Sie möglicherweise mit weniger Unit-Tests davonkommen.

6) Dieser ist noch experimenteller und kontroverser. Ich habe das nicht selbst gemacht, daher kann ich es nicht genau empfehlen. Lernen und verwenden Sie das Meta-Programmiersystem von JetBrains. Verwenden Sie diese Option, um Tools zu erstellen, mit denen Ihr Manager/Kunde die gewünschte Software selbst erstellt. Möglicherweise können Sie sogar die Durchführung von Einheiten- und Abnahmetests beenden, wenn Sie damit Tools erstellen können, mit denen Ihr Manager/Kunde das Verhalten auf sehr einfache und unkomplizierte Weise spezifiziert. Die Idee ist nicht, den Programmierer loszuwerden. Die Programmierer müssten diesen vom Kunden/Manager verwendeten Tools immer noch neue Funktionen hinzufügen, wenn sie (die Personen, nicht die Tools) die gewünschten Funktionen nicht einfach erstellen können. Ich glaube, dass entweder MPS oder ähnliche Tools der Weg der Zukunft sind.

8

Tatsächlich läuft es darauf hinaus, Erfahrung. Um schneller zu sein, was Sie tun, ist wie Autofahren. Zunächst haben Sie Angst, da andere schnelle (oder betrunkene) Fahrer (oder beides) sind und Sie sicher nach Hause gelangen möchten (in Bezug auf die Software möchten Sie sicherstellen, dass Ihr Code vorhanden ist funktioniert wie entwickelt und es funktioniert gut).

Im Laufe der Jahre/Monate lernen Sie, sobald Sie sich mit dem Fahren und den Autobahnen vertraut gemacht haben, einige Tricks, die Ihr Fahren zum Spaß machen. Das nennen wir Erfahrung. Diese "Tricks" (die ich Eigenschaften nenne) helfen.

In meinem Fall habe ich die tatsächliche Verwendung von Entwurfsmustern durch Codieren (sogar @ home) und Erlernen der Verwendung einiger gelernt. Wenn ich also auf ein Problem stoße, das ein Entwurfsmuster erfordert, nutze ich die Erfahrung der Vergangenheit, um zu sehen, welche funktionieren und warum es für meine Situation funktioniert/nicht funktioniert.

Zusammenfassend:

  • Erfahrung schafft Eigenschaften, die das Vertrauen und die bessere Software stärken.

PS: Erfahrung kommt auch vom Lernen von anderen. Z.B. Hilfe von SO, Pair Programming, Peer Reviews usw. Sie können keine Erfahrung machen, wenn Sie nicht zurückblicken und aus Fehlern lernen können (oder wenn jemand Ihre Bemühungen niemals in Frage stellt).

8
Buhake Sindi

Die Frage ist, ob Sie bei der Betrachtung der langfristigen Gesamtkosten günstiger sind.

Mit anderen Worten, sind Ihre sorgfältig ausgearbeiteten Fehlerkorrekturen von so hoher Qualität (einschließlich Testfällen und Dokumentation), dass sie die Kosten für die Wartung des Fehlers überwiegen Korrekturen durch Ihre schnelleren Mitarbeiter?

Wenn ja, müssen Sie Ihre Vorgesetzten auf diese Tatsache aufmerksam machen. Es kann schwierig sein zu argumentieren, wenn sie nicht messen und über die erforderlichen Daten verfügen, um Ihre Einschätzung zu bestätigen.

Wenn nein, müssen Sie unbedingt berücksichtigen , warum dies der Fall ist:

  • Bist du zu unerfahren?
  • Verbringst du viel zu viel Zeit damit, Dinge zu tun, die deiner Meinung nach nicht vorhanden sein sollten?
  • Haben Sie Schwierigkeiten festzustellen, wann der Fix abgeschlossen ist?
  • Ist Ihr Code doch von geringerer Qualität als Sie denken?
  • Sollten Sie die Codeentwicklung anders angehen, weil Sie zu lange brauchen, um sich auf dem neuesten Stand zu halten?
  • Haben Sie zu viel Zeit mit solchen Dingen verbracht?

Überlegen Sie es sich und bearbeiten Sie Ihre Frage mit Ihren Ergebnissen.

8
user1249

Verwenden Sie Ihr Gehirn mehr und führen Sie weniger Tests durch. Um ehrlich zu sein, hat das Testen seinen Platz, ist aber teuer.

Lesen Sie auch The Art of Unix Programming (kostenlos online, Buch den Preis wert)

Schließlich sind Sie möglicherweise nicht am richtigen Ort. Runder Stift im Vierkantjob usw.

Letztendlich ist es wie in der Schule: "Output was der Lehrer will" wird zu "Output was das Management verlangt und bezahlt".

5

Wenn Sie ein größeres, abgeschlossenes Projekt nehmen und die Anzahl der "letzten" Codezeilen pro Mannstunde erhalten, werden Sie feststellen, dass Programmierer VIEL langsamer codieren, als Sie es sich vorgestellt haben.

Wir sprechen nur ein paar Codezeilen pro Tag. Den Rest der Zeit verbringst du mit Debuggen, Umschreiben und allgemeinen Programmierarbeiten.

Möglicherweise haben Sie das alte Sprichwort gehört: Wenn Sie während der Eingabe einen Fehler feststellen, sparen Sie 10-mal mehr Zeit, wenn Sie ihn zur Erstellungszeit abfangen, was 10-mal besser ist als während der Qualitätssicherung, was 10-mal besser ist als es nach der Veröffentlichung zu fangen ..

Wie beschleunigen Sie es? Ich würde mich nicht auf irgendeine Form der Schreibgeschwindigkeit konzentrieren - das Reduzieren von Fehlern und das Verbessern anderer "zukünftiger Interaktionen" mit Ihrem Code sollte eine viel bessere Investition Ihrer Zeit sein.

Lesbarer, klarer Code ist entscheidend. Sie schreiben Ihren Code einmal, aber er wird dutzende Male gelesen. Das Schreiben zur besseren Lesbarkeit erspart Ihnen auf der ganzen Linie VIELE Probleme (was auch viel Zeit spart). Wenn Sie jemals zurückgehen und Ihren Code lesen und auch nur eine Sekunde darüber nachdenken müssen, dann machen Sie es falsch.

Durch die Paarprogrammierung kann die QS-Zeit verkürzt werden. Wenn Sie davon ausgehen, dass ein Programmierer nur wenige Zeilen pro Tag erstellt, können zwei mit der gleichen Rate wie eine, jedoch mit weniger Fehlern codieren.

Defensives Codieren (z. B. Parameterprüfung) kann Probleme reduzieren ... Wenn Sie einen wirklich guten Analysten/Architekten in Ihrem Team haben, können Sie mit einem guten Startdesign Zeit sparen.

Ansonsten verbessern Sie einfach Ihre Designfähigkeiten. Wenn Sie Erfahrung sammeln, werden Sie in der Lage sein, Muster zu erkennen, die nicht funktionieren, und sie zu vermeiden. Sie können Zeitsenken früher erkennen usw.

5
Bill K

Soweit ich weiß ist es:

  1. gut
  2. schnell
  3. billig

Als Manager können Sie 2 auswählen.

Machen Sie sich keine Sorgen über die Kommentare, die Sie zur Geschwindigkeit erhalten haben. Als Mitcodierer würde ich lieber Code beibehalten, der gut durchdacht und gut geschrieben ist, als etwas, das zusammengeschlagen wurde.

3
Nico

Haben Sie darüber nachgedacht, während Ihrer Arbeit eine detaillierte Prüfung Ihrer Person durchzuführen? Verfolgen Sie entweder mit Stift und Papier, wie Sie Ihre Zeit verbringen, oder verwenden Sie Rescue Time , um sich selbst zu verfolgen.

Sobald Sie genau wissen, wie Sie Ihre Zeit verbringen, können Sie eine bessere Vorstellung davon bekommen, was verbessert werden muss, und Ihre Bemühungen dort konzentrieren.

Im Idealfall können Sie auch einige Ihrer Mitarbeiter dazu auffordern, Ihre Ergebnisse vergleichen und sich gegenseitig Ideen einfallen lassen. Sie haben wahrscheinlich einige Stärken, von denen auch sie profitieren könnten.

Vielleicht stellen Sie fest, dass Sie zu viel Zeit für einen Teil Ihres Prozesses aufwenden, der automatisiert werden könnte, oder dass Sie an einem bestimmten Teil des Tages viele Ablenkungen haben und ein anderer Teil des Tages ruhig ist. Dann können Sie Ihre Aufgaben planen das usw.

Oder vielleicht stellen Sie fest, dass das Testen mehr Zeit in Anspruch nimmt als gedacht und Sie müssen Ihre Wahrnehmung überdenken, dass es Sie schneller macht.

Wenn nichts anderes, gibt es Ihnen einige Benchmarks, gegen die Sie arbeiten können.

3
DKnight

Von Ihrer Liste geht es Ihnen gut.

Wenn Ihre Kollegen Code mit einer höheren CRAP-Nummer erstellen, werden sie schneller. CRAP ist eine komisch benannte Metrik, die zyklomatische Komplexität und Testabdeckung kombiniert.

Schreiben Sie keinen Code, der mehr CRAP enthält als nötig. ;)

Meine einzige Änderung, die ich Ihnen vorschlagen möchte, ist die Verwendung von Bibliotheken. Schreiben Sie sie nur, wenn:

  1. Ihr Unternehmen verkauft Bibliotheken
  2. Sie haben wiederkehrenden Code in eine Bibliothek umgestaltet

Du liest und machst und das ist großartig. Aber Sie könnten nicht weiterkommen und über Procuedural oder OO Code, Haben Sie sich der funktionalen Programmierung (sagen wir Haskell?) Und Prolog ausgesetzt?

Haben Sie mit Smalltalk/Squeak gespielt, um Ihre OO Programmiertechnik) zu schärfen?

Und schließlich die Theorie. Haben Sie zumindest ein rudimentäres Verständnis der Graphentheorie? (Einige Programme arbeiten irgendwann mit Bäumen, DAGs oder einfachen Diagrammen. Netzwerke sind Diagramme.)

3
Tim Williscroft

Ich werde zitieren Onkel Bob :

Der einzige Weg, schnell zu gehen, ist, gut zu gehen.

Jedes Mal, wenn Sie der Versuchung begegnen, Qualität gegen Geschwindigkeit einzutauschen, werden Sie langsamer. Jedes Mal.

-- "Vehement Mediocrity", Robert C. Martin

3
Johnsyweb

Ich habe Einwände gegen die Ansicht "OP-Qualität für Geschwindigkeit geopfert" von OP.

Professionelle Programmierer (Programmierer) müssen 3 Objekte erfüllen:
1) Der Code sollte wie vorgesehen ausgeführt werden
2) Die Lieferung sollte pünktlich erfolgen
3) Gute Qualität, Dokumentation usw.
4) Andere usw.

Ich denke, OP wurde als langsam beschuldigt, wahrscheinlich weil OP nicht rechtzeitig erledigt wurde.

2
9dan

Dies ist ein Haken 22, der schwer zu umgehen ist. Obwohl Ihnen möglicherweise noch Erfahrung fehlt und einige Kenntnisse in vielen Aspekten bereits schneller sind als die meisten anderen, ist der Haken, dass es schwerer zu messen .

Persönlich ist das Beste, was Sie an diesem Punkt tun können, sich selbst zu messen. Geben Sie sich Feedback zu Ihrer Arbeitsweise. Vielleicht können einfache Änderungen Ihrer Arbeitsgewohnheiten Sie produktiver machen.

Ich stellte fest, dass Mails viel mehr wegfressen, als ich dachte, nur wegen der Unterbrechung. Jetzt beantworte ich Mails nur noch zweimal am Tag und habe an manchen Tagen fast 1 Stunde Produktivität gewonnen. Versuchen Sie Methoden wie pomodoro , ich habe es als Maßmittel verwendet. In regelmäßigen Abständen (15 Minuten) notierte ich mir, was ich damals tat. Dadurch konnte ich sehen, wie meine Tage strukturiert waren und was ich tun konnte, um die Effizienz zu maximieren.

2
Newtopian

Die wichtigsten Dinge, an die ich denken kann, sind folgende

  • Erhöhen Sie Ihre Schreibgeschwindigkeit.
  • Verwenden Sie Tools, die Produktivitätssteigerungen ermöglichen. Zum Beispiel ReSharper.
  • Schnellere Maschinen oder Werkzeuge. Wie mehr RAM oder ein Solid-State-Laufwerk.

Ich bin mir sicher, dass es einige Dinge gibt, die Sie auch im Bereich der Codierungsfähigkeiten tun können, aber es hört sich so an, als wären Sie mit all diesen Dingen fertig. Die Dinge, die ich oben aufgeführt habe, werden normalerweise von Entwicklern übersehen.

2
mpenrow

Sie könnten einen Speed-Typing-Kurs belegen. Ich weiß nicht, ob schnelleres Tippen ein Problem ist, aber "zu langsames Codieren" kann durch einfach langsame Tippgeschwindigkeiten verursacht werden.

Was ist mit Codegeneratoren? Manchmal wiederholt sich der Code. Durch Refactoring kann ein Teil davon entfernt werden, aber selbst dann können Sie wiederholt dieselbe Refactored-Funktion aufrufen. Abhängig von den Daten und dem Code, mit denen Sie arbeiten, können Codegeneratoren (geschrieben in Excel, Perl, Java, was auch immer ...) viel Zeit sparen . Die Verwendung von Tools zur Codegenerierung für die UI-Entwicklung ist normalerweise ein Kinderspiel.

Und schließlich sind die Metriken möglicherweise falsch. Haben Sie darüber nachgedacht, dass Sie bei allem anderen mit der schnellstmöglichen Geschwindigkeit codieren und dass die Zeitleisten zu kurz sind, was Sie scheinen ein langsamer Codierer zu sein?


Basierend auf den Änderungen in Ihrer Frage scheint es, als könnten Sie entweder den Weg einiger Ihrer Mitarbeiter einschlagen und gemeinsam die schnellste Lösung hacken, die funktioniert - und Dokumentation und Qualitätssicherung sind verdammt!

Oder ... sammeln Sie mehr Erfahrung und üben Sie in einem bestimmten Bereich, damit Sie die Codebasis und die API so gut kennen, dass Sie die Lösungen im Schlaf codieren können. Dies ist möglich, erfordert jedoch mehr Zeit. Wenn die anderen Entwickler, die schneller sind als Sie, älter und erfahrener sind, müssen Sie nur eines tun: Sie müssen werden älter und erfahrener!

Der Vorteil von Squeak für schnelles Codieren geht weit über das bloße "Honen der eigenen OOP Fähigkeiten") hinaus. Es gibt einen Grund, warum moderne GUIs sowie IDEs auf Smalltalk erfunden wurden, ganz zu schweigen davon, dass JUNIT eine Portierung von war SUNIT to Java, der Begriff "OOP" wurde erfunden, um Smalltalk usw. usw. zu beschreiben.

Man muss immer die Sprache und Umgebung verwenden, die für das, was man erreichen möchte, am besten geeignet ist, aber für das allgemeine Prototyping würde ich zumindest Quietschen mit allem vergleichen, mit der möglichen Ausnahme von HyperCard, und selbst das würde ein Benchmarking erfordern, um zu sehen, welches war tatsächlich schneller, da in Squeak hyperkartenähnliche Einrichtungen eingebaut sind.

0
user22340