Code schreiben

14.1 Ein normaler Tag im Leben eines Entwicklers

Programmierer zu sein, ist einfach und angenehm. Für die Organisation der Arbeit ist der Project Manager verantwortlich, für die Feature-Liste des Produkts der Product Owner. Meetings werden vom Scrum Master organisiert. Alle organisatorischen Prozesse sind maximal formalisiert und standardisiert.

Du kommst morgens zur Arbeit, machst dir einen Tee oder Kaffee und setzt dich an den Computer. Du öffnest den allgemeinen Chat, schaust, ob es dringende Nachrichten gibt, ob jemand krank ist, und wenn alles in Ordnung ist, dann beginnst du mit der Arbeit.

Du öffnest die Website JIRA, auf der die Liste aller Aufgaben deines Teams gespeichert ist: das Projekt-Backlog und das aktuelle Sprint-Backlog. Die Aufgaben sind bereits von deinem Scrum Master/TeamLead oder Product Owner nach Priorität sortiert.

Du nimmst die Aufgabe von ganz oben — die am höchsten priorisierte — und beginnst daran zu arbeiten. Dafür musst du sie in den Status In Progress setzen. Das geht mit ein paar Klicks. Alles klar, die Zeit läuft.

Zur Aufgabenbeschreibung wird normalerweise zusätzliche Information oder ein Link zur Dokumentation hinzugefügt. Die Aufgabe sollte alle notwendigen Informationen enthalten, damit du sie erledigen kannst. Das Bereitstellen dieser Informationen ist die Aufgabe deines Managers.

Wenn etwas nicht stimmt, kannst du die Aufgabe (Task) an deinen Manager zurückübertragen und in den Kommentaren dazu schreiben, welche Fragen aufgetreten sind und/oder welche Informationen fehlen.

14.2 Code schreiben

Du hast die Aufgabenbeschreibung studiert und dir ist klar, was zu tun ist. Super, dann leg los. Hierbei hilft dir deine Erfahrung aus der Ausbildung bei CodeGym und die Arbeit im Team.

Nachdem die aktuelle Feature fertig ist und du dich davon überzeugt hast, musst du deinen Code in Git hochladen. Das geht mit ein paar Klicks direkt aus der IDE, in deinem Fall aus WebStorm. Du committest deinen Code zuerst in dein lokales Repository und pusht ihn dann in das zentrale Git-Repository.

Meistens wird der letzte Schritt über einen Pull Request gemacht, wenn du über Git die Anfrage an deinen Teamleiter sendest, um deinen Code zu reviewen. Wenn der Code gut ist und es keine Anmerkungen dazu gibt, wird dein Teamleiter deinen Pull Request akzeptieren, und er wird in den Hauptarbeitszweig von git aufgenommen.

Auch solltest du nicht zum Teamleiter gehen und sagen: „Das kann man nicht machen“. Solch ein Satz ist sehr frustrierend, besonders wenn der Teamleiter genau weiß, dass „es möglich ist“, und vielleicht selbst etwas Ähnliches schon mehrmals gemacht hat.

Weißt du nicht, wie man es macht — sag: „Ich habe zwei Stunden/zwei Tage damit verbracht, herauszufinden, wie das geht, aber es klappt nicht“. Der Teamleiter wird dir gerne zeigen… in welche Richtung du googeln sollst.

Jetzt haben wir uns ein Bild von der modernen Produktentwicklung gemacht. Code zu schreiben ist nur ein kleiner Teil der ganzen Arbeit, aber alles ist so organisiert, dass dich nichts von deiner Arbeit ablenkt. Also zögere nicht, dich mit Frontend auseinanderzusetzen — du wirst es lieben, als Programmierer zu arbeiten.