Was muss ein Junior Java Developer können?
Was muss man als Junior Developer können wenn man neu im Beruf ist?
Kriegt man eine Aufgabe zum programmieren bekommt, tippt man dann einfach drauf los oder sucht man auch im Internet und kopiert Codes hin und her?
Im Studium sind viele der Kommilitonen schon langjährige Programmierer oder haben zumindest aus dem Hobby Erfahrungen gesammelt. Mich hat das etwas eingeschüchtert. Ich stelle mir Developer so vor, dass sie, egal ob Junior oder Senior, sofort loslegen und wissen wie der Code aussehen soll.
Wenn man sich mit entsprechendem Studienabschluss bewirbt, aber keine Berufserfahrung hat, wie wird man auf die Juniorstelle Auswahlverfahren getestet? Vom Studium kennt man nur die Grundlagen und Übungsaufgaben, aber vieles kann man erst, wenn man genug Erfahrung gesammelt hat.
Ich habe aus Wikipedia folgendes gelesen:
Üblicherweise rechnet man mit einer Produktivität – inklusive aller Projekttätigkeiten – von 10 bis 50 Codezeilen je Mitarbeiter und Tag. Ein Softwareentwicklungsprojekt mit einem gesamten Aufwand von 1.000 Personentagen (ca. 5 Personenjahre) sollte also zwischen 10.000 und 50.000 Lines of Code produziert haben.
Das kommt mir für einen Developer sehr wenig vor. Wenn ich eine kleine Anwendung schreibe sind 10 Zeilen davon nur Variablendefinition. Verstehe ich vielleicht unter Zeilen etwas falsches?
2 Antworten
Das kommt mir für einen Developer sehr wenig vor.
Beachte den Hinweis: inklusive aller Projekttätigkeiten. Das bedeutet etwa: Aufgabenstellung verstehen, nachfragen, schätzen, Projektmanagement-Hausaufgaben machen (JIRA-Tickets bearbeiten, bunte Post-Its herumschieben, ...), Testfälle schreiben, Lösungsansatz überlegen und ggf. mit Kollegen diskutieren, eigentlichen Code schreiben, testen, statische Codeanalyse ansehen, korrigieren, Refactoring, Doku schreiben, Code-Reviews, Bugfixes von Produktionsproblemen samt mühsamer Fehlersuche, ...
Als Entwickler verbringt man tatsächlich relativ wenig Zeit damit, neuen Code zu schreiben - das kommt eher schubweise, gefolgt von längeren Phasen ganz ohne. Besonders schön ist es sogar, wenn man bestehenden Code löschen kann.
Soviel auch zu deiner Frage:
tippt man dann einfach drauf los
Und dazu:
oder sucht man auch im Internet und kopiert Codes hin und her?
Natürlich wird auch im Internet gesucht - und sei es nur die Dokumentation der Werkzeuge und Bibliotheken, mit denen man arbeitet. Wer aber bei der kleinsten Aufgabenstellung schon hilf- und planlos nur halb verstandenen Code aus dem Internet zusammenpappt, wird sich mittelfristig nicht beliebt machen.
Ich würde raten, dir etwas Literatur zur Praxis des Software Engineerings zu besorgen. Das wäre sowas wie Robert C. Martins Clean Code und der Pragmatic Programmer von Hunt et al.
Zumindest für Unit Tests ist der Entwickler selbst zuständig. Für den Rest: kommt drauf an, wie das im Unternehmen organisiert ist. Die Softwareentwicklung hat sich in den letzten Jahrzehnten weg von einer strikten Arbeitsteilung entwickelt, auch beim Testen. Siehe Schlagwörter wie DevOps, TDD, usw.
Gerade wenn du studierst oder studiert hast, sollte dir doch klar sein, dass man eben nicht sofort darauf los programmiert. Als erstes macht man sich Gedanken um die Struktur. Das muss nicht immer UML sein, aber eine Zergliederung der Aufgabe in Teilaufgaben und geeignete Schnittstellen sind unglaublich wichtig für die Zukunft.
Je nach Aufgabe muss man sich auch erst mal Code von Kollegen anschauen, verstehen was wie gemacht wird und sich auch auf einen Codestil einigen - z.B. kann ein Code-Stil vorgegeben werden. Das hilft auch später, wenn man an das Projekt noch mal ran muss. Als Aufgabenfeld dazu kommt ja evtl. noch dokumentieren, testen,...
macht das Testen nicht jemand anderes, der als Java-Tester eingestellt wurde?