In Stellenausschreibungen steht heute immer öfter die Anforderung, Git über die Command Line zu nutzen. Gerade bei Senior-Entwicklern wird dieses Wissen bereits explizit vorausgesetzt. Das Command-Line-Wissen kannst du dann auch anwenden, wenn dir kein Rechner mit Sourcetree zur Verfügung steht, weil du dich vielleicht direkt auf den Linux-Servern lokal oder remote bewegen musst.

Git Commands, die tatsächlich gebraucht werden

Es sind nicht so viele Git Commands, die für die tägliche Arbeit gebraucht werden, wie man vielleicht glaubt. Hier mal ein einfacher Task mit den Git-Commands direkt auf der Command Line.

Git Repository klonen

git clone https://url.com/example-repo

Mit dem Git Command wird das Repo in das Verzeichnis „example-repo“ geklont. Gibt man hinter der URL ein anderes Ziel oder Target an, wird ein anderer Ordner genommen. Das macht bei der späteren Anwendung keinen Unterschied, kann aber zu mehr Übersicht in der Dateistruktur genutzt werden. Mit der Angabe von „.“ wird das Repository in das aktuelle Verzeichnis geklont. Das ist zwar ein seltener Anwendungsfall, spart einem aber bei Bedarf Zeit. Dafür muss der Ordner allerdings vollständig leer sein. Auch die Verzeichnisse der PHP-IDEs, wie PhpStorm, dürfen hier nicht vorhanden sein.

Branch erstellen

git checkout -b myNewTask
Mit dem Checkout-Befehl und dem Parameter -b wird ein neuer Branch „myNewTask“ erstellt und automatisch auf diesen gewechselt. Hier ist darauf zu achten, auf welchen Branch man sich zu dem Zeitpunkt der Erstellung befindet, und natürlich auch darauf, dass man den aktuellsten Stand auscheckt – also vorher ein „git pull“ ausgeführt hat.

Developing auf dem Branch

git add . && git commit -m “#myNewBranch add css file”
oder
git add layout/mynewtask.css && git commit -m “#myNewBranch add css file”

Generell soll ja bei jeder funktionierenden Änderung ein Commit gemacht werden. Hier ist Disziplin gefragt. Grafische Tools wie Sourcetree verleiten jedoch dazu, dies zu einem späteren Zeitpunkt zu machen. Hier kann man sehr einfach einzelne geänderte Zeilen separaten Commits zuweisen. Das bedeutet leider noch lange nicht, dass der Commit tatsächlich alles tut, was er soll, und wie gewünscht funktioniert hat.

Insofern ist es besser, regelmäßig kleine Commits zu machen. Der Git-Add-Befehl dient dabei einmal für das separate File und einmal für alles seit dem letzten Commit. Auch hier gilt: Regelmäßige und sinnvolle Commits machen einem das Leben leichter und sind effektiver. Vorher ist es zudem immer sinnvoll, sich die aktuellen Änderungen mit „git status“ noch einmal anzeigen zu lassen. Denn schließlich kommt es vor, dass man etwas übersehen hat. Das trifft auch auf von der Applikation generierte Files zu, die eventuell noch über .gitignore ausgeschlossen werden müssen.

Commit Messages

Damit man die Historie einer Entwicklung nachvollziehen kann, sind Commit Messages wichtig. Diese müssen aussagekräftig sein und beinhalten idealerweise eine Ticket-ID. Denn somit können die Arbeitsschritte direkt zugeordnet werden. Nicht aussagekräftige Commit Messages indes schaden dem Team und einem selbst.

Mit Pre Hooks ist es möglich, Commits ohne Ticket-ID direkt zu unterbinden. Das kann sogar erweitert werden, dass sich das Ticket im richtigen Status befinden muss. Solche Maßnahmen einzuführen und umzusetzen, ist allerdings nicht so einfach wie deren technische Implementierung.

Es gibt einige Spaßseiten zu dem Thema wie beispielsweise Commits from last night – dabei ist das Thema doch eigentlich sehr ernst. Denn es dient der Dokumentation der eigenen Arbeit und zeigt, dass du ein Profi bist. Soll heißen: Arbeite immer möglichst professionell. Das ist wichtig und richtig.

Git-flow installieren und sofort nutzen

git flow feature start myNewBranch
git flow feature finish myNewBranch

Git-flow hat sich in vielen Projekten bewährt und wird vor allem gerne bei neuen Projekten eingesetzt. Auf dem Mac ist es schnell mit Homebrew installiert, und nach einem „git flow init“ kann es nach einigen Bestätigungen der Default-Settings sofort eingesetzt werden. Mit dem oben aufgeführten Start-Befehl wird dabei ein neuer Branch aus dem aktuellen Develop Branch erstellt. Danach kann man sein Feature entwickeln und mit dem Finish-Befehl wieder abschließen. Hier wird ein Merge zurück in den Develop Branch ausgeführt und der Feature Branch sofort gelöscht. Falls man das aber nicht unbedingt möchte, geht es auch mit Hotfixes und Releases.

Eine gute Übersicht zu all dem bietet http://danielkummer.github.io/git-flow-cheatsheet/. Ausführliche Informationen zu Git-flow gibt es außerdem unter https://github.com/nvie/gitflow. Wir haben uns im praktischen Einsatz dazu entschlossen, nach dem Git-Flow-Workflow zu arbeiten, die zusammengeführten Branches allerdings zu archivieren und zu erhalten.

Git-Workflow nur auf der Command Line

Der Git-flow ist eine Zusammenfassung von Befehlen, die man selbstverständlich auch eigenhändig und einzeln ausführen kann. In meinen Augen ist aber ein großer Nachteil, dass Branches, die zurückgemerged wurden, auch gelöscht werden.

Persönlich finde ich es zudem besser, Bugfixes auf dem Feature Branch durchzuführen und sich öfter mit dem aktuellen Stand abzugleichen. So kann man die Arbeit auf einem Feature besser dokumentieren. Das Ganze geht manuell auf der Command Line – CLI – wie folgt:

// Aktuellen Develop Branch auschecken und aktualisieren
git checkout develop
git pull

// Feature Branch für Jira Ticket SUP-123 erstellen
git checkout -b feature/SUP-123

// Commits auf das Ticket
git status
git add . && git commit -m “#SUP-123 what i have done”

// Git Pushes sollten mindestens jeden Abend durchgeführt werden – und zwar auf jeden Fall vor den Merges, egal in welche Richtung
git status
git push

// Feature Branch zurück in Develop bringen
git checkout develop
git pull
git merge feature/SUP-123
git status

// Tag setzen
git tag -a v1.2.0 -m “Version v1.2.0”
// Push mit Tags
git push && git push –tags

Die oben aufgeführten Commands in oh-my-zsh
// Aktuellen Develop Branch auschecken und aktualisieren
gco develop
gl

// Feature Branch für Jira Ticket SUP-123 erstellen
gcb feature/SUP-123

// Commits auf das Ticket
gst
gaa && gcmsg “#SUP-123 was ich gerade getan habe”
gst

// Git Push sollte mindestens jeden Abend durchgeführt werden – und zwar auf jeden Fall vor den Merges, egal in welche Richtung
gst
gp

// Feature Branch zurück in Develop bringen
gco develop
gl
gm feature/SUP-123
gst

// Tag setzen
git tag -a v1.2.0 -m “Version v1.2.0”

// Push mit Tags
gp && gp –tags

Mit oh-my-zsh sind eine Vielzahl von Git Commands als Alias abgelegt. Im praktischen Einsatz kommen in meinen Augen die oben abgebildeten zum Tragen. Allein gaa && gcmsg „my message“ bringen einem sehr viel, da sie ein häufiger Anwendungsfall sind. Auch gc für git checkout geht schnell in Fleisch und Blut über.

Probleme mit Git

Git-Konflikte sind ein großes Thema bei Git und natürlich auch Themen wie Rebase. Aber in diesem Artikel gehe ich nicht zusätzlich auf diese Themen ein. In Zukunft werden wir hier in unserem Webdevelopment-Blog das Thema Git auch in anderen Zusammenhängen aufgreifen. Auch gehe ich nicht auf Tools, wie Tig ein. Aber natürlich ist es wichtig und richtig, mit visuellen Tools zu arbeiten.

Fazit zu Git auf der Command Line CLI

Git ist in der heutigen Zeit des Webdevelopments der Quasi-Standard. Jeder Entwickler, egal ob Frontend oder Backend, muss damit umgehen können. Man braucht und darf keine Ausreden bei der Nutzung einer Command Line haben. Nur so wird man zum Profi – sonst ist man nur ein Anwender. Ein User.

In diesem Artikel ist ein einfaches Beispiel über die Entwicklung eines Feature Branches abgebildet. Man sieht ganz deutlich, dass nur wenige Commands nötig sind. Es ist wichtig, diese einfachen Vorgänge zu 100 Prozent auf der Command Line durchführen zu können und dies auch regelmäßig zu tun. Nur so lernt man Git richtig.

Unsere Git-PHP-Schulung

Git wird von vielen Webdevelopern benutzt. Sie haben es aber leider häufig nicht verinnerlicht oder verstanden, warum man damit genau so arbeitet, wie man es tut. In unserer Schulung gehen wir ganz praktisch vor und erklären Git von den Grundlagen bis zu praktischen und etablierten Workflows. Wir gehen auf die Anwendungsfehler ein und geben unsere persönliche Erfahrung direkt an die Teilnehmer weiter. Es ist eine sehr individuelle Intensiv-Schulung. Alle Informationen zu dem Thema gibt es auf
http://www.entwicklungshilfe.nrw/seminare/git-flow-git-branching-model-fuer-agile-software-projekte/

Wie nutzt du Git bislang? Hast du es schon mal per Command Line versucht, und wie sind da ggf. deine Erfahrungswerte?

Der Beitrag Git auf der Command Line CLI einsetzen erschien zuerst auf Entwicklungshilfe NRW.

Voraussetzungen für einen erfolgreichen Workflow

Grundlage für den hier gezeigten Workflow sind PhpStorm als IDE mit installiertem git-flow-Plugin sowie ein funktionierendes Ticketsystem Redmine. Natürlich gibt es Alternativen zu dieser Kombination. PhpStorm arbeitet mit sehr vielen Systemen zusammen, und auch andere IDEs haben ähnliche Funktionen. Der Workflow im Versionskontrollsystem basiert auf unserer git-flow-Präsentation und ist aus meiner Sicht zwar im Feinen anpassbar, im Groben aber alternativlos.

Ticketsystem Redmine richtig einstellen

Das Ticketsystem sollte von außen erreichbar sein. Der zur Verknüpfung benutzte User sollte im Ticketsystem aktiv sein und Projekte und Tasks – im Weiteren auch Issues genannt – zugewiesen haben. Zusätzlich muss die REST-Api in der Konfiguration des Ticketsystems aktiviert sein.

In PhpStorm geht es weiter

In PhpStorm geht man zunächst über die Tastenkombi cmd+“,“ (Mac) in die Einstellungen und navigiert zu Tools -> Tasks -> Servers. Dort setzt man nach Auswahl des Ticketsystems die URL und Zugangsdaten zu seinem Ticketsystem.

Ein Klick auf den Test-Button liefert das Ergebnis:

Im zweiten Reiter stellt man die Commit-Einstellungen ein. Das Ticketsystem Redmine ist in der Lage, Commit-Nachrichten auszulesen und darauf zu reagieren. Eine sinnvolle Einstellung zur Automatisierung spart hier wertvolle Zeit.

Optimaler Workflow in PhpStorm mit dem Ticketsystem Redmine

Die Voraussetzungen sind hier ein Projekt im ausgecheckten develop-Branch, ein vorhandenes Ticket und eine eingerichtete Entwicklungsumgebung.

Die Steuerungsleiste für das Taskmanagement befindet sich im rechten oberen Bereich.

Über das Dropdown kommt man in den „Task öffnen“-Dialog.

Nach erfolgreichem Öffnen eines Tasks sollte man eine für den Task eingerichtete Changelist in PhpStorm und auf Ebene der Versionskontrolle einen Feature-Branch ausgecheckt haben.

Sollte man seine relevanten Entwicklungen lokal abgeschlossen haben, kommt der Zeitpunkt, an dem man seinen Code committet. Durch die Nutzung der taskrelevanten Changelisten ist dies selbst bei Bearbeitung mehrerer Issues in einem Projekt durchschaubar. Zudem verringern die voreingestellten Informationen aus dem Ticketsystem die manuell einzugebenden Informationen.

Vor dem anschließenden Push zeigt PhpStorm eine Zusammenfassung der Änderungen.

Als Abschluss muss man das Feature leider noch manuell über das git-flow-Plugin schließen, aber ich hoffe, dass das in naher Zukunft automatisiert wird.

Als Meldung sollte PhpStorm einblenden, dass der Feature-Branch erfolgreich zurückgemerged wurde.

Es kann zudem vorkommen, dass PhpStorm die Changelist nicht löscht. Um die Ordnung nicht zu verlieren, hilft das manuelle Löschen.

Außerdem kann es helfen, bei zu vielen Issues in der Liste auch diese manuell zu löschen.

Überprüfung in der Versionskontrolle und im Ticketsystem Redmine

Wer ähnlich wie wir Redmine mit gitolite und dem redmine git hosting nutzt, kann jetzt in seinem Projekt bei Redmine im Projektarchiv seinen neuen Workflow überprüfen.

Weiterführende Informationen zum Beispiel vom PhpStorm-Hersteller Jetbrains bekommt ihr hier.

Nutzt ihr in euren PHP-Projekten eine andere Kombination von Ticketsystem, Versionskontrolle und IDE? Wenn ja, dann schreibt uns hier doch bitte mal, welche das sind. Denn von einem solchen Know-how-Austausch profitieren ja letztlich alle. Die oben beschriebene Kombination schulen wir übrigens auch.

Der Beitrag PhpStorm mit dem Ticketsystem Redmine nutzen erschien zuerst auf Entwicklungshilfe NRW.

Legacy-Code-Probleme sind überall bekannt

„Nirgends werden tote Pferde so weit geritten wie in der Software-Entwicklung“ heißt es auf meiner Website. Nicht von ungefähr. Denn als Trainer und Dozent im Bereich der Software-Qualität kann ich infrage kommende Code-Stellen, die nach Robert C. Martin gerne als „Code smells“ bezeichnet werden, auch ohne die Unterstützung von Software sehr schnell ausfindig machen. Zudem sind sie unter Webdevelopern durchaus bekannt. Aber sie werden aus Zeitgründen umschifft.

Dabei ist Legacy Code längst kein Problem mehr, welches nur auf den Backend-PHP-Teil betrifft. Denn da heute Webapplikationen geschrieben werden, ist der Anteil von Javascript beträchtlich – und in den kommenden Jahren wird sich das noch weiter verschieben: API-Schnittstellen, Webservices und Microservices werden den Teil des Backends in der Applikation darstellen und unterschiedlichste Clients im Frontend die bereitgestellten Daten verarbeiten. Mit Technologien wie React und AngularJS zeichnet sich hier ein sehr klares Bild des zukünftigen Webdevelopments ab.

Legacy-Code-Nester in Webdevelopment-Projekten

Bei den Frontend-Teilen eines Webprojekts braucht man gar nicht lange zu suchen. Große Ansammlungen sind hier z. B. main.css, style.css und natürlich script.js und app.js. Das sind große und historisch gewachsene Files, die immer nur erweitert werden und selten ein Code-Refactoring gesehen haben. Auch im Bereich der Backend-Entwicklung wird trotz Software-Design und Patterns oft nicht sauber gearbeitet.

Eben dort ist PhpStorm eine große Hilfe: Code, der offensichtlich nicht verwendet wird, wird farbig ausgegraut und kann so recht zuverlässig entfernt werden. Aber auch hier ist große Vorsicht geboten: Ohne automatisierte Tests ist es nahezu unmöglich, effektiv zu arbeiten. Fakt aber ist, dass durch die gewachsene Komplexität und die schlechte Lesbarkeit viel Zeit und Motivation verloren gehen. Wenn man da überhaupt noch durchsteigt. Dann wird gerne kapituliert, was sogar bis zur Krankmeldung gehen kann. Hier Licht reinzubringen, ist, wenn man es nicht regelmäßig macht, ein immenser, unausweichlicher und stetig wachsender Kostenfaktor.

Legacy Code verursacht weitaus höhere Projektkosten

Webdevelopment-Projekte sind in einem schlechten Software-Zustand nicht mehr wartbar, zumal nach und nach immer mehr Bugs ans Tageslicht kommen. Das richtet großen Schaden in sämtlichen Bereichen einer Firma an und kann diese sogar in den Ruin treiben.

Auch Kunden ist das mittlerweile klar geworden: Rund 30 Prozent Mehrkosten sind als On-Top-Budget für Software-Qualität längst eine feste kalkulatorische Größe. Damit werden dann beispielsweise automatisierte Tests eingeführt, um den Entwicklungsprozess optimieren zu können.

Legacy Code verhindert die Weiterentwicklung der Berufssparte

Wenn die verfügbaren Ressourcen eines Webdevelopment-Teams völlig aufgebraucht werden, leiden darunter Weiterbildung und Motivation sowie die Bereitschaft, sich mit Herzblut in seine Arbeit einzubringen. Code wird dann sprichwörtlich hingerotzt. Dabei ist gerade bei der heutigen Programmierung ein enorm hohes und komplexes Wissen gefragt. Das kann nicht mal eben mit einer einzelnen PHP-Schulung abgebildet werden.

Zudem wird es Junior-Webdevelopern auf diese Weise nahezu unmöglich gemacht, sich in die vorhandenen Strukturen zu integrieren. Hinzu kommt die vertane Zeit. Denn sich mit Problemen aus einer „anderen technischen Epoche“ auseinandersetzen zu müssen, ist nicht zielführend. Innovationen und Sprünge in der Entwicklung sind so nicht machbar. Man steckt im Sumpf der Legacy-Projekte fest.

Refactoring ist der Anfang vom Ende des Legacy Codes

Software-Qualität entsteht durch Refactoring von Quellcode. Man spricht hier auch von „Aushärten“. In allen Arbeitsbereichen wird dabei noch einmal über die bestehende Arbeit geschaut, um diese zu korrigieren und zu verbessern. Sogar ein einfacher Blog-Artikel wie dieser hier bekommt dadurch mehr als zehn Revisionen.

Betrachtet man hingegen Code-Stellen, bleibt man im unteren einstelligen Bereich. Hier muss wesentlich mehr Zeit investiert und eingeplant werden. Dies ist dann zugleich eine Investition in das eigene Webdevelopment-Team. Denn warum sollte man sich schwieriger und langsamer in Projekten bewegen, bloß weil der Kunde an diesem Punkt keinen Bedarf sieht …? Schließlich geht es nicht zuletzt um die eigene Software-Qualität – und damit letztlich auch um Lebensqualität.

Wir können Software-Projekte nicht neu schreiben

Noch immer gibt es die Illusion, dass eine Website alle paar Jahre komplett neu gemacht werden muss. Selbst auf Internetseiten, die an Werbekampagnen gebunden sind, soll dies zutreffen. Doch in „Wegwerf-Seiten“ wurde in aller Regel keine aufwendige Business-Logik implementiert – wie etwa in Bereichen des E-Commerce. Insofern ist es purer Wahnsinn, zu denken, man könne mit den vorhandenen personellen Ressourcen parallel einfach mal eine neue Seite entwickeln. Das ist der falsche Weg.

„Same old thinking – same old result“ ist hier ein Problem an sich. Es verhindert, dass sich Entwickler mit neuem Wissen frisch ans Werk machen können, zumal dadurch alte Probleme am Ende nur neu verpackt werden. Zudem ergeben sich beträchtliche Spannungen, wenn ein Teil des Teams neue Software schreiben muss, während der andere Teil den bestehenden Teil weiterpflegt. So kommt nur unnötige Unruhe auf, die dem Teamgeist schadet und das Projekt behindert. Allerdings ist es ohne Weiteres möglich, bestimmte Routen eines Projekts neu zu erstellen und somit sukzessiv Teile zu erneuern. Zu diesem Thema beraten wir gerne.

Mit Pair Programming Probleme erkennen und lösen

Vor allem Refactoring im Team bietet eine hervorragende Möglichkeit, mit Pair-Programming anzufangen. Nutzt man diese Chance, so bildet man gleich auch das Webdevelopment-Team weiter und spart eine ganze Menge Zeit, die sonst für Absprachen und Konventionen nötig wäre. Gerade der „doppelte Blick“ ist ja der Schlüssel dafür, Probleme zu erkennen und aus einem anderen Blickwinkel betrachten zu können. Wir bieten Schulungen mit genau diesem Ziel an. Da der Start mit Pair Programming jedoch nicht immer ganz einfach ist, ist eine externe Meinung umso wichtiger, damit es hier nicht zum Kompetenzgerangel kommt.

Legacy Code und der innere Schweinehund

Sport ist gut für die Gesundheit, gesunde Ernährung ohnehin, und Bewegung tut ihr Übriges. Ein gesunder Körper kann am Ende immer auf einen gesunden Geist zählen. Und halten wir zur Genüge daran? Nein. Wir verfügen über einen regelrechten Ausreden-Katalog, der von täglichen Problemen bis hin zum Wetter immer eine passende Ausrede für uns parat hält. Und dabei ist es doch einfach nur eine Kopfsache.

So ist es auch in der Software-Entwicklung. Hier verhalten wir uns aus mehreren Gründen unvernünftig. Wobei oft gar nicht erst nach Gründen gesucht, sondern ebenso wie beim Thema Sport & Gesundheit bei jeder Gelegenheit der „Keine-Zeit-Joker“ ausgespielt wird. Einfach mal mit einem festen Termin über zwei Stunden in der Woche freitags ab 16 Uhr starten! Das kommt auch erstmal gut an. Aber hier sind Ausdauer und Disziplin gefragt!

Wenn der Budget-Plan keine Software-Qualität zulässt

Investitionen in die Software-Qualität und in das Personal sind dringend notwendig. Aber oft lässt der Budget-Plan dies nicht zu. Doch wie weit kommt man mit einem Auto mit brennender Motorleuchte, ohne einen Motorschaden zu riskieren …? Schlimmstenfalls bis zum Totalschaden. Gleichermaßen riskant ist ein solch „blindes“ Vorgehen in der Software-Entwicklung. Und noch einmal: Darunter leidet immer auch die Stimmung in der gesamten Firma.

In puncto Software-Qualität muss also die richtige Entscheidung getroffen werden! Es gilt, konsequent Ziele zu beschließen und zu erreichen. Der Prozess muss kontrolliert und überwacht werden.

Mit zu viel Legacy Code werden Entwickler verheizt

Als Webentwickler mit Berufserfahrung findet man derzeit in jeder Stadt Arbeitgeber und kann sofort eine Stelle besetzen. Die Stellen selbst sind dabei, auch wenn die Gehälter einander entsprechen, höchst unterschiedlich. Wird der Entwickler gefordert und gefördert – oder doch nur verheizt? Etwa durch zu viel Legacy Code. Letzteres findet man überall. Ersteres vielleicht in den vier großen Städten. Vor allem Berlin zeigt, wie es geht. Und gerade deshalb gibt es dort auch so tolle Erfolgsstories.

Der Ruf der Entwicklungsabteilung und der Software-Qualität im Unternehmen ist ein zunehmend wichtiges Entscheidungskriterium für die Karriere. Daher gilt auch hier: Ist der Ruf erst ruiniert … Treffen Unternehmen indes die richtigen Entscheidungen, so festigt man die bestehenden Strukturen und macht sich attraktiv für neue Bewerber.

Mein Fazit zum Thema Legacy Code

Legacy Code ist nach wie vor ein großes Problem, das sich nur mit Arbeit lösen lässt. Doch ist man diesen Weg einmal gegangen, dann lohnt er sich. Denn klar ist:

• Die Software-Qualität steigt.
• Die Kunden sind zufriedener.
• Die Abteilungen können effektiv arbeiten.
• Der Spaß kehrt zurück an den Arbeitsplatz.

So betrachtet ist die gezielte und intensive Beschäftigung mit Legacy Code ein notwendiges Übel. Denn niemand mag es, ständig aufzuräumen und Ordnung zu halten. Für Profis gehört aber genau das nun einmal dazu.

Welche Erfahrungen hast du mit Legacy Code gemacht? Du kannst gerne das Kommentarfeld unter diesem Beitrag nutzen, um deine Erfahrungen mit anderen zu teilen.

Der Beitrag Legacy Code – Entstehung, Ursache und Auswirkung erschien zuerst auf Entwicklungshilfe NRW.

Berufliche Weiterbildung steht in Deutschland weiterhin hoch im Kurs. So gaben im Jahr 2015 bei einer im Auftrag des ILS Institut für Lernsysteme durchgeführten Forsa-Studie unter 20- bis 40-jährigen acht von zehn Befragten an, durch gezielte Schulungsmaßnahmen mehr Kompetenz und Sicherheit im Beruf erlangt zu haben. Und immerhin 60 Prozent waren sich darin einig, mit ihrem erweiterten Wissen fortan selbstbewusster auftreten zu können. Der immense Wert von Weiterbildung ist damit unter Arbeitnehmern weitgehend unbestritten, und besonders groß sind die Herausforderungen im IT-Bereich. Hier nicht zuletzt in puncto PHP-Schulungen für Webentwickler.

Mit PHP-Schulungen Personalmangel kompensieren

Das hat seine Gründe. Denn einerseits ist der IT-Markt angesichts der rasant fortschreitenden Digitalisierung der Wirtschaftsprozesse von einer immer größeren Dynamik geprägt, und andererseits erfordern die durch die zunehmende Anzahl an Cyber-Angriffen entstehenden finanziellen Schäden immer bessere Systeme mit ständig zu optimierenden Sicherheitsvorkehrungen. Hinzu kommen die stark veränderten User-Gewohnheiten, die „mobile first“ zum derzeit alles beherrschenden Schlagwort machen.

Da aber auf dem Arbeitsmarkt nach wie vor ein akuter Mangel an gut ausgebildeten Webdevelopern herrscht, bleiben viele Stellen unbesetzt. Kompensieren lässt sich dieser nun schon seit einigen Jahren währende Engpass kurzfristig wohl nur durch gezielte PHP-Schulungen. Hier ist also Lernen angesagt, um die Effektivität von Webdevelopern zu erhöhen. Ziel ist es dabei, deren individuelle Skills kontinuierlich zu erweitern und zu verfeinern. Letzten Endes ergibt sich daraus eine Win-Win-Situation für Arbeitgeber (sprich: größere Leistungsfähigkeit der Entwicklerteams) und Arbeitnehmer (sprich: höhere Arbeitsplatzsicherheit und bessere Karrierechancen), von der dann auch die deutsche Wirtschaft insgesamt profitiert.

Strategische Überzeugungsarbeit in drei Schritten

Allerdings winken die meisten Unternehmen (bzw. deren IT-Abteilungsleiter) längst nicht jede aus den Reihen der Entwicklerteams vorgeschlagene PHP-Schulungsmaßnahme einfach so durch. Finanzieller Aufwand und Belastung des Arbeitszeitkontos sind dabei die häufigsten „Totschlagargumente“ gegen das Erlernen neuer PHP-Fertigkeiten. Hier ist also zunächst einmal jede Menge Überzeugungsarbeit gefordert, und dabei solltest du unbedingt die drei nun folgenden Punkte für ein strategisch durchdachtes Vorgehen beachten:

1. Fokussiere den Nutzen für dein Unternehmen, ohne dabei dein Licht unter den Scheffel zu stellen!

Formuliere deinen Vorschlag immer so, dass nicht etwa eine etwaige Wissenslücke oder fachliche Schwäche deinerseits im Vordergrund steht, sondern stets der (wirtschaftliche) Nutzen, den das Unternehmen durch deine PHP-Schulung erfährt. Deine bereits vorhandenen Skills dürfen hierbei nicht in Zweifel gezogen werden können. Im Zweifelsfall solltest du das also vorher üben.

2. Suche dir Verbündete und schaffe Allianzen, denn gemeinsam seid ihr durchsetzungsfähiger!

Statt alleine nach vorne zu preschen, stimme dich zuerst mit deinen Teamkollegen ab, damit ihr idealerweise mit einem gemeinschaftlichen Vorschlag an euren Team- oder Projektleiter herantreten könnt. Sieht auch dieser die Vorteile für das Entwicklerteam (und für sich selbst als Verantwortlichen), so seid ihr schon mal auf einem guten Weg zur Budgetierung der gewünschten PHP-Schulung.

3. Erkundige dich genau über die Lerninhalte der PHP-Schulung und sammle stichhaltige Argumente!

Umso exakter du den Nutzen für dein Unternehmen am Beispiel aktueller Projekte und Problemstellungen formulieren und anhand deines zukünftigen Know-hows belegen kannst, desto eher bekommst du grünes Licht für das Vorhaben. Du musst also schon im Erstgespräch genau nachweisen, inwiefern die PHP-Schulung zu dir, zum Projekt und zum Unternehmen passt.

Übrigens: Als allerletzte Trumpfkarte kannst du gegebenenfalls immer noch deine Bereitschaft zum Ausdruck bringen, die PHP-Schulung zumindest anteilig in deiner Freizeit wahrzunehmen. Denn wie gesagt: Du selbst profitierst ja auch von der Maßnahme, insofern sie dich fachlich nach vorne bringt und dir möglicherweise neue berufliche Perspektiven innerhalb deines Unternehmens eröffnet.

Wenn du Interesse an den PHP-Schulungen von Entwicklungshilfe NRW hast, findest du hier ausführliche Informationen zu den Seminaren und Workshops.

Der Beitrag Wie du deine Vorgesetzten vom Nutzen einer PHP-Schulung überzeugst erschien zuerst auf Entwicklungshilfe NRW.

Damit ist im Großen und Ganzen der thematische Rahmen des hiermit vom Stapel gelaufenen Webentwickler-Blogs von Entwicklungshilfe NRW umrissen, der eine Ergänzung zu den PHP-Schulungen für Webdeveloper darstellen soll. Neben den branchenüblichen praktischen Tipps, Tricks und Tutorials rund um das Thema Webentwicklung wirst du hier in Zukunft auch Beiträge finden, die die nicht-technischen Aspekte deiner täglichen Arbeit als Webentwickler beleuchten. Ebenso wie mit den PHP-Schulungen von Entwicklungshilfe NRW ist es somit auch auf diesem Blog das Ziel, dich effektiv in deinem Job zu unterstützen und dir aktuelle Problemlösungen und andere für dich wichtige Informationen und Ratschläge zu liefern.

Fünf allgemeine Tipps für effizienteres Arbeiten

Zum „seichten“ Einstieg möchten wir dir fünf klassische Tipps für effizienteres Arbeiten geben, die so natürlich auch für alle anderen Berufsfelder gelten. In Anbetracht der oben beschriebenen Situation treffen sie auf Webentwickler heute jedoch in besonderem Maße zu.

1. Halte deine Pausenzeiten ein!

Wie eine repräsentative Befragung der Bundesanstalt für Arbeitsschutz und Arbeitsmedizin von 2014 offenlegte, lässt rund jeder vierte Arbeitnehmer in Deutschland häufig seine Pausen ausfallen. Das ist kontraproduktiv. Denn einerseits ist dieser vermeintliche Zeitgewinn eine reine Illusion, da der Verzicht auf regelmäßige Erholungsphasen wegen der dadurch abfallenden Leistungskurve ein wahrer Produktivitätskiller ist – und anderseits belastest du damit auf Dauer deine Gesundheit. Du hilfst somit also weder dem jeweiligen Projekt und deinem Unternehmen noch dir selbst.

2. Vermeide übermäßiges Multitasking!

Nur 2,5 Prozent der Menschen sind sogenannte Supertasker und können ohne Qualitätsverlust mehrere Aufgaben gleichzeitig erledigen. Alle anderen sollten tunlichst die Finger davon lassen. Sonst steigt nicht nur deine Fehlerkurve signifikant an, sondern du läufst auch Gefahr, deinem Gehirn zu schaden, wie eine Studie ergeben hat. Außerdem ist Multitasking ein Kreativitätshemmer. Hier ist, sofern überhaupt möglich, eine klare Priorisierung deiner Aufgaben nötig.

3. Du musst lernen, auch mal nein zu sagen!

Klar, das ist meist leichter gesagt als getan. Aber wenn gute Gründe dafür sprechen, die sofortige Erledigung einer neuen Aufgabe auch mal abzulehnen, dann solltest du das unbedingt tun. Vor allem wenn dadurch eine andere wichtige Deadline definitiv nicht mehr einzuhalten ist. Gerade Berufseinsteiger tun sich hiermit natürlich etwas schwer. Aber am Ende des Tages bist du es, der einen auf den Deckel bekommt, wenn eine Aufgabe nicht fristgerecht fertiggestellt wurde und dadurch der Workflow im Team ins Stocken gerät. Nimm dir in solchen Fällen also die Zeit, überzeugende Argumente für dein Nein vorzutragen.

4. Kommuniziere ausreichend und eindeutig!

Eines der größten Probleme in Projekten ist unzureichende und fehlerhafte Kommunikation. Dies gilt nicht nur für die Kommunikation zwischen Projektleiter und Team, sondern auch für die „kleinteilige“ Projektkommunikation des Teams untereinander. Klar ist: Fehlende oder unsauber kommunizierte Informationen können ganze Fehler-Kaskaden in allen nachgelagerten Arbeitsschritten auslösen. Das kostet Zeit und Geld. Und Nerven sowieso. Daher solltest du dich immer bemühen, dich in ausreichendem Maße mit anderen auszutauschen und dabei auf eine unmissverständliche Ausdrucksweise zu achten. Wenn nötig, verschriftliche deine für den Rest des Teams wichtigen Informationen oder Fragen und nutze hierzu E-Mails oder kollaborative Kommunikationstools.

5. Stehe auch zu deinen Schwächen!

Das mag sich zunächst seltsam anhören, ist aber in der Teamarbeit von zentraler Bedeutung. Schließlich beherrscht nicht jeder alles in völliger Perfektion. Insofern ist es wichtig, dass du dir an deinen neuralgischen Punkten die passende Hilfe suchst. Dazu ist ein Team letztlich da. Also überwinde den inneren Schweinehund und bitte da um Unterstützung, wo du sie brauchst. Das gemeinschaftliche Projekt und Produkt gewinnt dadurch an Qualität – und außerdem stärkt gegenseitige Hilfestellung den Teamgeist!

Auch unsere praxisnahen PHP-Schulungen für Webentwickler sind förderlich für Teamgeist und Team-Entwicklung. Hier geht es zu unseren Seminaren und Workshops.

Der Beitrag Blogstart mit fünf Tipps für Webworker (und andere) erschien zuerst auf Entwicklungshilfe NRW.