Wie programmiert Ihr?
Hallo,
schreibt Ihr alles aus dem Kopf oder schaut Ihr als Programmierer auch nach wie z.B Befehle oder auch ganze Abschnitte Code den Ihr anschließend verwendet? Was macht ein Programmierer aus? Muss er alles aus dem Kopf schreiben können oder viele Bibliotheken auswendig lernen?
Habt Ihr eventuell eine Übersicht vieler Bibliotheken für Java?
LG und vielen Dank für die Antworten!
7 Antworten
Vieles hat man im Kopf aber alles kann sich wohl kein Mensch merken. Darüber hinaus verwendet man auch mal externe Bibliotheken und Frameworks oder bindet Schnittstellen ein, mit den man nicht gearbeitet hat. Natürlich gibt es dafür dann entsprechende API Beschreibungen.
Und sicher hat man auch mal ein Brett vorm Kopf und bemüht Google und landet dann meist bei Stack Overflow. Wichtig ist denke ich immer den Code zu verstehen und nicht blind irgendwas zusammen zu kopieren.
Für vieles, was eher Schreibaufwand ist, habe ich z.B. auch Snippets und Templates, genauso für Sachen die komplizierter sind, die man regelmäßig brauch aber nicht so regelmäßig, als dass man sich das merken würde oder auf Datenbank Ebene für bestimmte Performance Analysen usw.
Je nach Bereich verwendet man ja auch Algorithmen, die man ebenso wenig auswendig im Kopf hat oder muss sich in die Mathematik dahinter ein wenig einlesen.
Aber ja der überwiegende Großteil ist ja eher Boilerplate und die Domänenlogik bzw. entsprechende Abstraktionen, die man selbst schreibt. Dafür muss man natürlich nirgendwo was nachschauen.
(...) schreibt Ihr alles aus dem Kopf oder schaut Ihr als Programmierer auch nach (...)
Mh, an der Stelle würde ich zunächst einmal etwas abgrenzen.
Zumindest in der professionellen Programmierung besteht Programmieren ja nicht daraus, Code oft komplett neu zu schreiben. Stattdessen wird viel wiederverwendet. Sei es aus dem Projekt, an dem man gerade arbeitet oder aus anderen Projekten. Das heißt, an der Stelle kann bereits einige Kommunikation mit Teammitgliedern stattfinden oder man recherchiert selbst, wenn man es nicht bereits weiß.
Bei der Nutzung externer Abhängigkeiten (Frameworks / Bibliotheken) ist eine Recherche nach deren Funktionen oft ebenfalls notwendig, um nicht unbeabsichtigt Redundanzen / instabilen Code einzufügen. Ich möchte es einmal an einem PHP-Beispiel erklären (weil es mir spontan sofort einfällt):
Angenommen, man hat eine Webanwendung mit PHP entwickelt, die eine Referenz auf die PHPMailer-Bibliothek besitzt. Nun möchte man ein Kontaktformular implementieren und dazu die E-Mail heraussenden. Ein Programmierer, der sich neu mit an das Projekt setzt, könnte nun sagen: Ich kenne die mail-Funktion, die bereits in der PHP-Standardbibliothek implementiert ist, die bau ich ein. Es ist ja eh nahezu ein Einzeiler, alles schön einfach.
In dem Moment entstehen aber zwei Probleme:
- Das Projekt wird inkonsistent (an einigen Code-Stellen wird die externe Bibliothek eingesetzt, an anderen wieder nicht) und die externe Bibliothek verliert einen Stück weit ihren Sinn / ihre Bedeutung.
- Die Probleme, die die PHPMailer-Bibliothek im Gegensatz zu mail behebt, werden an der Stelle nicht genutzt.
Zugegeben, solche Fälle sind nicht vollkommen vermeidbar, doch es sollte zumindest eine gewisse Vorprüfung stattfinden.
Wenn man nun Code direkt aus dem Kopf schreibt, dann logischerweise nur den, der sich im Langzeitgedächtnis verewigen konnte (weil sich z.B. das Verfahren / die Struktur kaum ändert; Stichwort: Boilerplate-Code).
Kurzum hängt es von der Erfahrung ab. Wenn man eine Bibliothek / ein Framework gerade erst neu kennenlernt, kann man nie und nimmer dessen Funktionen sofort kennen (wohl eher erahnen). Und folgend damit zu beginnen, alle Funktionen auswendig zu lernen, würde zu viel Zeit beanspruchen. Viel eher baut man sich ein persönliches Toolset (Wörterbuch) auf. Wenn man bspw. mit Java beginnen würde, um ein Hangman-Spiel zu bauen, könnte es damit losgehen, dass man einige String-Methoden kennenlernt. Oder für einen Webcrawler die Request API von Java. Dieses Toolset erweitert sich stetig, sofern man noch weiter damit arbeitet.
Aber selbst da halte ich es nicht für unbedingt notwendig, Name, Parameterliste, usw. noch ganz exakt im Kopf zu behalten. Das verfestigt sich dann eher automatisch, wenn man es eh öfter nutzt.
Um hier aber kein Missverständnis zu erzeugen: Mit den Grundlagen / der Grundstruktur muss man sich auf jeden Fall möglichst früh auseinandersetzen. Wenn ein Framework bspw. einen asynchronen Stil fordert, sollte man sich dem anpassen und nicht dagegen arbeiten, nur weil man sich mit dem Konzept nicht auseinandersetzen möchte.
Hilfreich bei neuen Bibliotheken / Frameworks ist es, wenn man auf Kenntnisse anderer Tools zurückgreifen kann oder ebenso etwas intuitiv arbeitet. So könnte man bei dem Hangman-Spiel sagen: Hey, ich kenne Programmiersprache XY und die hat in ihrer Standardbibliothek eine Funktion für mein Problem - womöglich gibt es so etwas in Java ebenso. Sollte die Dokumentation an der Stelle nicht weiterhelfen, können es Foren (StackOverflow, u.ä.).
Wenn das neue Tool, welches man nutzt, auf einen bestimmten Zweck ausgerichtet ist (z.B. das zur Verfügung stellen von grafischen Komponenten), kann man auch von einer gewissen Erwartungshaltung reden, die man dem Tool entgegenbringt (von einem GUI Toolkit erwarte ich bspw. Funktionen, um die Komponenten in einem gewissen Layout anordnen zu können).
Ferner würde ich zwei wichtige Punkte benennen, mit denen man vertraut sein sollte:
- Man muss formulieren können, wonach man sucht und das womöglich in einzelne Teilaufgaben herunterbrechen (die übliche Analysephase).
- Man muss recherchieren können. Ein übliches Suchfeld sind API Referenzen in englischer Sprache (oder bereits bestehender Code). Doch manchmal reicht auch die Auto Suggestion einer IDE.
Umso öfter man das macht, umso einfacher wird es mit der Zeit.
(...) schaut Ihr als Programmierer auch nach wie z.B Befehle oder auch ganze Abschnitte Code den Ihr anschließend verwendet?
Ja, das ist in eingen Fällen sinnvoll, sofern es nicht nur eine Copy & Paste & Save & Close-Aktion bleibt.
Beispiel 1) Bei einigen Bibliotheken (gerade die, die auf GitHub veröffentlicht werden) ist es nicht unüblich, dass Demo-Projekte (in einem separaten Ordner) vorgestellt werden. Man kann sich ein komplettes Beispiel in das eigene Projekt kopieren und dann anpassen, das ist oft einfacher und schneller gemacht, als die einzelnen Methoden so aus der Dokumentation herauszusuchen. Ab und an gibt es nicht einmal eine Dokumentation (Auflistung aller Funktionen o.ä.) und die Demo-Projekte stellen die einzige Möglichkeit dar, einfach und schnell zu erfassen, was die Bibliothek kann.
Beispiel 2) Boilerplate-Code, wie: Zeilenweises Einlesen von Daten aus einer Textdatei. Oder wenn ein (mathematischer) Algorithmus benötigt wird, der irgendwo schon fertig implementiert vorliegt (z.B. Quicksort).
Muss er alles aus dem Kopf schreiben können oder viele Bibliotheken auswendig lernen?
Wie oben schon erwähnt, nein. Ungefähr wissen / erahnen, was es gibt, wäre nützlich und sich ein Toolset von den Funktionen anzueignen, die man oft braucht.
Habt Ihr eventuell eine Übersicht vieler Bibliotheken für Java?
Zunächst ein Link auf die Standardbibliothek: Java 14 - API Reference.
Wenn du für die Projektverwaltung Maven oder Gradle nutzt, kannst du dir leicht externe Abhängigkeiten in dein Projekt einbinden, die in einem zentralen Repository liegen. Nutze https://mvnrepository.com/ oder https://search.maven.org/ für die Suche.
Nun zu ein paar konkreteren Quellen und Tools, die mir gerade einfallen und die ich als erwähnenswert erachte:
- Ein Quell vieler Java-Utility-Tools (Webframeworks, Projekt Builder, Webserver, usw.) bietet Apache. Drei Projekte möchte ich einmal herausheben: Zum einen Apache Commons, da es nützliche Erweiterungen für die Java Standardbibliothek beinhaltet, zum anderen Apache Log4j (ein Logging Framework) sowie Lucene (Features zur Indizierung und Suche von Daten)
- Docx4j (Bearbeitung von Word-/Excel-/...-Dateien)
- Google Guava verfügt wie Apache Commons über viele nützliche Erweiterungen der Kernbibliothek
- Google GSON oder Jackson zur Verarbeitung von JSON
- jsoup (HTML-Parser)
- JUnit und Mockito für Testverfahren
- MiGLayout (zusätzlicher Layout Manager für Java Swing)
- OpenJFX (ehemals JavaFX; GUI-Toolkit)
- Spring
Ein Programmierer muss nur wissen wo was steht was er braucht und wie er es anwendet.
Das recherchieren ist ein wichtiger Teil in allen Programmierungen.
Aber es ist schon gut, wenn man alles schon mal gesehen hat, also wenn man weis, das es das gibt
Was macht ein Programmierer aus? Muss er alles aus dem Kopf schreiben können oder viele Bibliotheken auswendig lernen?
Vorweg: Es gibt in der Berufswelt eine klare Trennung zwischen Programmierer und Softwareentwickler und da ist der Programmierer wenig mehr als ein technischer Sekretär: Er kann eine Programmiersprache und bekommt ein logisches Listing oder Diagramm hingelegt und hat das in den Computer zu tippen. Im Gegenzug dazu stehen die Softwareentwickler. Das sind diejenigen, die tatsächlich neue Programme erschaffen oder bestehende Software erweitern, pflegen, umschreiben etc. Ich gehe mal davon aus, dass sie die ursprüngliche Frage eher auf den Softwareentwickler bezieht. (Von Softwarearchitekten fange ich lieber erst gar nicht an...)
Also ich erwarte von Neulingen in der Firma hier (also Softwareentwicklern) Folgendes:
- Sie sind aktiv und nicht reaktiv. Wenn sie also etwas nicht wissen oder verstehen, dann fragen sie selbst von sich aus nach, was Sache ist und erwarten nicht, dass alles zu ihnen hingetragen wird.
- Sie sind in der Lage, sich selbstständig Wissen zu erarbeiten. Wenn ich ihnen was von der "Gang of 4" und "design patterns" sage, dann lautet nicht die Gegenfrage "was'n das?" sondern sie fangen das Suchen und Lesen an und fragen dann"wie funktioniert'n das genau mit dem observer pattern?"
- Sie können sich verständlich ausdrücken. Gerade und insbesondere bei komplexen technischen Themen ist das aber gar nicht so einfach. Deswegen kann ein Softwareentwickler auch Diagramme erstellen, um Sachverhalte zu verdeutlichen. Ob er das mit Photoshop, mit Power Point, Draw oder yEd macht, das ist mir vollkommen egal.
- Sie können selbstverständlich Englisch und zwar richtig gut, damit sie sich sowohl international mit ihren Kollegen verständigen als auch unbegrenzt auf Stack Overflow nachschlagen zu können und sie sind dadurch in der Lage, jede Form von vernünftigem Manual zu lesen. Eine weitere Fremdsprache ist nett aber nicht zwingend notwendig.
- Sie haben ihre präferierten Werkzeuge, können aber mit der vorgegebenen IDE umgehen. Wenn ich ihnen also Visual Studio vorsetze, dann können sie damit umgehen (oder bringen es sich selbst ziemlich zügig bei). Ob sie dann als 08/15 Editor Notepad++, UltraEdit oder sonst irgendetwas verwenden, ist mir Jacke wie Hose.
- Sie sind in der Lage, komplexe Probleme in Teilprobleme aufzubrechen. Dabei können sie auch gerne mal um die Ecke denken und vielleicht nicht ganz offensichtliche Lösungen finden.
- Außerdem können sie ihre so gefundenen Lösungen entweder selbst direkt in Code umsetzen oder in verständichem Pseudocode für den Programmierer aufschreiben.
Was? Programmiersprachen? Muss ich demnächst auch bei einem Schreiner erst nachfragen, ob er mit Hobel und Säge umgehen kann oder was? Ja selbstverständlich hat ein Softwareentwickler ein oder zwei Programmiersprachen zu beherrschen. Die Sprachen selbst sind mir dabei ziemlich wurscht, viel wichtiger ist, dass er sich auch weitere Sprachen noch aneignen kann, je nachdem, was das nächste anstehende Prokekt halt verlangt.
Fazit: Wer sich nur und einzig und allein auf eine einzige Programmiersprache versteift, ist für meine Belange als Softwareentwickler nicht geeignet.
Einiges kenne ich auswendig, einiges Google ich halt. Warum auswendig lernen, wenn man auch nachgucken kann. Manchmal Google ich auch komplette Funktionen, die ich zwar selber schreiben könnte, aber bei dem kleinen Programm was ich gerade erstelle lohnt es sich halt nicht darein Zeit zu investieren.
Was dabei aber wichtig ist, ist das du verstehst, was du eigentlich tust.