Muss ich alles auswendig können?

5 Antworten

Vom Fragesteller als hilfreich ausgezeichnet

Ich arbeite seit nunmehr fast 25 Jahren in der Branche. Und ich kann nur bestätigen, was bereits gesagt wurde:

  • Dokumentiere deinen Code systematisch, regelmäßig und nachhaltig! Das ist nicht nur für andere wichtig, sondern auch für dich und deinen Lernprozess.
  • Schreibe immer so, dass DU es verstehst! (C&P also VERSTEHEND KOPIEREN!) Damit erweiterst du deine "allgemeinen Kenntnisse" und wirst quasi vollautomatisch immer effizienter.
  • Freunde dich mit den Suchmaschinen an! Mit den richtigen Suchbegriffen findest du - mittlerweile - für (fast) jedes Problem eine Lösung.
  • Lege dir Link-Listen für die besten Dokumentationen, über die du im Laufe der Zeit unweigerlich stolpern wirst, an!
  • Lege dir Toolboxes für die wichtigsten Snippets an! Nutze und verbessere die Snippets, wann immer es geht!

Im Gegensatz zur Empfehlung, sich Nachschlagewerke ins Regal zu stellen, empfehle ich, der ich mittlerweile fast 1000 solche Bücher besitze, dir aber: Vergiss es! Im Regelfall liest du so ein Buch höchstens einmal wirklich, schlägst danach noch 10-15 Mal nach ... und lässt es dann verstauben. Nutze stattdessen Online-Versionen, so weit wie irgend möglich. Die sind leichter durchsuchbar und nehmen nicht so viel Geld, Zeit und Platz in Anspruch.

... ob diese Arbeitsweise mich zum schlechten Programmierer macht

Schon allein diese Frage zeichnet dich aus, Praza. Schlechte Programmierer sind Leute, die NICHT immer wieder über die Effizienz ihrer Arbeit(sweise) nachdenken ... und/oder die Erkenntnisse solcher Denkprozesse umsetzen.

In der shcule lerne ich Java und im Betrieb setzen wir VB.NET (ASP.NET)ein. Zu Hause arbeite ich mit Perl und PHP.

Erfahrungsgemäß kommt dann am Ende jemand raus, der von allem ein bisschen, aber nichts richtig kann. Ich würde meine Kräfte konzentrieren, Praza. Besser ein "guter Java/VB"-Entwickler sein, als ein "mittelmäßiger Java/VB/PHP/Perl"-Programmierer...

Ich habe auch immer das Problem, dass ich vorallem wenn ich ne längere Zeit nicht programmiert habe, Sachen vergessen habe. Daher ist die Doku sehr sinnvoll.

Oben wurde schon alles gesagt, ich kann dir noch http://DocHub.io empfehlen, Datenbank für CSS, HTML, PHP, JavaScript, jQuery und Phyton

Du brauchst keine Dokus zu machen, die gibt es eigentlich für jede Programmiersprache bereits (und wesentlich umfangreicher, als du es als einzelner je hinbekommen könntest).

Ich programmiere/scripte neben Ruby auch wie du in PHP und Java. Für PHP ist die offizielle Dokumentation ausgezeichnet, für Java zwar umfangreich aber leider sehr unübersichtlich.

Meine Einstellung: Du musst nicht alles wissen, aber die Grundlagen beherrschen und wissen, wo du weitere Infos zu einem Thema findest, das du nicht auswendig weißt.

Das bedeutet im Klartext, sich mit der Dokumentation auseinandersetzen und Google nutzen zu können. Bisher bin ich mit dieser Lösung immer super gefahren. Je nachdem wie viel du dir von den am häufigsten gebrauchten Infos auswendig merken kannst, desto schneller bist du dann eben, wobei du dir häufig benutzte Sachen aber eh besser merken kannst als irgendwas exotisches, was du in deinem Leben nur ein, zwei, drei mal brauchst. Von daher wirst du ganz von selbst mit der Zeit immer schneller.

Was sich übrigens auch gut anbietet, ist sich ein Kompendium etc. in Buchform zu kaufen und ins Regal zu stellen - einmal durchlesen, immer wieder mal nachschlagen. Für Java würde ich dir das wegen der wie bereits erwähnt sehr bescheidenen offiziellen Doku besunders empfehlen; bei PHP kannst du wunderbar die offizielle Doku benutzen.

Ich persönlich definiere einen guten Programmierer neben einem guten Programmierstil hauptsächlich über seine Effizienz. Und auf welchem Weg jemand effizient arbeitet, das halte ich für vollkommen unwichtig. Das Ergebnis ist das was zählt.

weed458  15.02.2013, 07:12

Das kann ich nur bestätigen! Auch die erfahrensten Programmierer wissen nicht alles auswendig. Auch nicht wenn diese nur 1 oder 2 Programmiersprachen verwenden. Wofür ich aber eine persönliche Doku sehr sinnvoll finde (und sie selbst auch schon lange mal anlegen wollte), sind kleinere oder auch komplexe Probleme, für die du lange Zeit gerätselt hast wie du sie löst und die auch nicht so alltäglich sind. Den entsprechenden Code-Block würde ich mir in einer kleinen Sammlung hinterlegen zusammen mit einer Beschreibung und evtl. ein paar Schlagworten. Falls ein ähnliches Problem wieder mal aufkommt, kann ich ohne langes Suchen einfach nachschlagen. Aber das wie gesagt nur für Dinge, für die du sonst mit Google & Co keine Antwort in wenigen Minuten findest.

0
verreisterNutzer  15.02.2013, 07:18
@weed458

Das was du da anführst würde ich aber nicht als Doku bezeichnen, sondern mehr als Sammlung von Code Snippets - welche auch häufig online gestellt werden und man damit eh wieder mit Suche findet.

Natürlich da auch ein "legitimes" Mittel sich selbst eine private Sammlung anzulegen, solange es entsprechendes nicht bereits aus anderen Quellen fertig gibt.

0

Code dokumentieren ist immer sinnvoll, wird nur meist aus Zeitgründen vernachlässigt. Wenn du es dir angewöhnt hast: gut, behalt es bei.

Praza 
Fragesteller
 14.02.2013, 23:53

Also, ich schreibe die noch zusätzlich in einem Word-Dokument, das meinte ich. sry habe wohl falsch ausgedruckt.

0
florianscholz  15.02.2013, 02:52
@Praza

Man sollte aufjedenfall interessanten Code noch einmal auslagern oder einfach seine Projekte ausreichend kommentieren und sichern. Aber wieso in einer WORD-Datei? Microsoft Word zerreisst jede Formattierung! Was spricht gegen txt-Dateien?

Wichtig ist übrigens auch, dass du nichtunbedingt den Code dokumentierst sondern wie du auf ihn kamst bzw. was er macht. Beispiel verkettete Listen:

Es macht keinen Sinn pro Programmiersprache eine Implementierung einer verketteten Listen zu speichern, wenn an dieser nichts besonderes dran ist. Wichtiger ist, dass du das Prinzip verstanden hast und diese in 3 Minuten in jeder prozeduralen oder objektorientierten Programmiersprache runterprogrammieren kannst.

0