Was ich durch die erstmalige Entwicklung von Unternehmenssoftware gelernt habe

In diesem Artikel werde ich zehn Lektionen teilen, die ich aus meinem ersten Projekt als autodidaktischer Softwareentwickler gelernt habe. Ich arbeitete zu dieser Zeit für ein Beratungsunternehmen und mein offizieller Titel war Software Engineer. Das Projekt, an dem ich gearbeitet habe, war eine Webanwendung für den öffentlichen Sektor.

Lektion 1: Lernen Sie die Architektur so schnell wie möglich

Am Anfang war es am schwierigsten, sich an die Menge des geschriebenen Codes zu gewöhnen. Als ich anfing, musste es mindestens eine Million Codezeilen gegeben haben! Dies wurde so viel einfacher, nachdem wir etwas über die Architektur gelernt hatten, die wir verwendeten. Ich erinnere mich, dass ich damals verwirrt war.

Erst als ich einen von der Firma angebotenen Crashkurs über Schichtarchitektur absolvierte, verstand ich wirklich, wie man durch die Codebasis navigiert. Als ich anfing, bekam ich einen sehr kurzen Überblick, aber ich wünschte, ich hätte früher ein besseres Verständnis als ich.

Lektion 2: Nehmen Sie keine Verknüpfungen mit der Architektur

In der Mitte meiner Projektzeit haben wir viele neue Funktionen hinzugefügt. Einiges davon konnten wir mit neuerer Technologie erreichen. Da ich den Wert der von uns verwendeten Architektur immer noch nicht wirklich verstand, entschied ich mich für Verknüpfungen. Dies kostete Zeit und Ressourcen, als wir zurückgehen und es reparieren mussten.

Lektion 3: Unterschätzen Sie nicht den Wert des Geschäftskontexts

Ein wichtiger Teil des Projekts ist das Erlernen der Geschäftsanforderungen. Ich habe die Bedeutung für die gesamte Projektdauer völlig unterschätzt. Dies war ein teurer Fehler. Wenn Sie den geschäftlichen Kontext Ihrer Arbeit nicht verstehen, ist es sehr einfach, den falschen Weg einzuschlagen.

Lektion 4: Unterschätzen Sie nicht den Wert des Autodidakten

Durch dieses Projekt konnte ich viel Vertrauen in meine Fähigkeiten als Entwickler gewinnen. Ich bin der festen Überzeugung, dass Sie, wenn Sie die richtigen Werkzeuge haben, ein Experte für alles werden können.

Obwohl ich nicht behaupte, ein Experte zu sein, war mein autodidaktisches Lernmaterial mehr als genug, um mich auf dieses Projekt vorzubereiten. Denken Sie daran - die Liste war viel kürzer, als ich anfing! Diese Offenbarung hat mich zum Schreiben inspiriert. Hat sich das Lernen gelohnt?

Lektion 5: Schreiben Sie schnelle Tests und löschen Sie veraltete Tests

Unser Projekt bestand aus vielen Tests. Wir hatten eine autonome Testsuite, die Komponententests, Persistenztests und Integrationstests durchführte. Die Unit-Tests dauerten einige Minuten, aber alle zusammen dauerten eine ganze Stunde! Ich erkannte, dass Schnelltests am besten sind und es keinen Sinn macht, an alten Tests festzuhalten, die veraltet sind.

Lektion 6: Seien Sie vorsichtig bei den Konsequenzen, wenn Sie weniger häufig festlegen

Wir haben Subversion für unsere Versionskontrolle verwendet. Leider wurde der von uns festgeschriebene Code automatisch in das Repository eingecheckt. Wir haben sehr selten mit Filialen gearbeitet, da die Opportunitätskosten zu hoch zu sein schienen. Dies führte dazu, dass weniger häufig Code festgeschrieben wurde. Ich habe immer noch versucht, mich häufig zu verpflichten, aber manchmal habe ich den Build abgebrochen - ich dachte nicht, dass ich die Stunde investieren müsste, um die Tests vor Ort durchzuführen.

Lektion 7: Schreiben Sie zuverlässige Tests - und vergessen Sie nicht, diese beizubehalten

Darüber hinaus waren einige Tests nicht immer grün. Sie arbeiteten manchmal, aber sie scheiterten genauso oft. Dies würde dazu führen, dass der Build rot ist. Infolgedessen habe ich den Wert eines roten Builds nicht wirklich geschätzt. Manchmal war der Build tagelang rot, weil jemand nicht bemerkte, dass ein anderer Test abgebrochen worden war.

Lektion 8: Überprüfen Sie den Code so schnell wie möglich

Normalerweise schreiben ein Entwickler den Code und ein anderer Entwickler überprüft den Code. Ich hatte die Möglichkeit, beides zu tun. Oft bekam ich ein Feature zu entwickeln. Bevor ich fertig bin, würde ich etwas zur Überprüfung bekommen. Es könnte Tage dauern, bis ich zur Überprüfung kam.

Dies verursachte häufig Kopfschmerzen, da der von mir überprüfte Code nicht mit dem entwickelten Code übereinstimmte. Die Paarprogrammierung hätte dieses Problem vermieden, aber so haben wir nicht gearbeitet.

Lektion 9: Refactoring sollte von Tests begleitet werden

Die Tests wurden erst fünf Jahre nach Projektbeginn eingeführt. Zuvor wurden alle Tests manuell durchgeführt. Dies bedeutete, dass ein Großteil der Codebasis keine Testabdeckung hatte, was gefährlich ist.

Persönlich mag ich die Idee, die Pfadfinderregel auf Code anzuwenden. Ich neigte natürlich dazu, viel umzugestalten. Da wir jedoch nicht für alles, was ich überarbeitet habe, eine Testabdeckung hatten, führte ich manchmal Fehler in unsere Software ein.

Lektion 10: Die Entwicklung von Software ist ein Kompromiss zwischen Geschäftswert und hervorragender Software

Wir haben ein V-Modell für den Softwareentwicklungsprozess verwendet. Dies beinhaltete Fristen für die Entwicklung, das manuelle Testen und die Freigabe der Software. Wir hatten keine unbegrenzte Zeit, um den Code, den wir geschrieben haben, zu entwickeln oder zu überprüfen. In einigen Fällen würde ich zu viel Zeit damit verbringen, den Code zu perfektionieren, was nicht immer einen geschäftlichen Nutzen bringen würde.

Abschließende Gedanken

Dieses Projekt war für mich eine sehr wertvolle Lernerfahrung. Ich hoffe, Sie konnten auch etwas daraus lernen. Lassen Sie mich in den Kommentaren unten wissen, ob Sie ähnliche oder gegensätzliche Erfahrungen gemacht haben!

Bevor du gehst ... Danke, dass du den Artikel gelesen hast! Wenn es Ihnen gefallen hat, vergessen Sie bitte nicht, Ihre Wertschätzung zu zeigen, indem Sie auf das unten klicken!

Ich schreibe über meine beruflichen und pädagogischen Erfahrungen als autodidaktischer Softwareentwickler. Klicken Sie also auf die Schaltfläche "Folgen", wenn Sie dies interessiert! Sie können auch meinen Blog lesen oder meinen Newsletter abonnieren, um weitere Inhalte zu erhalten.

  • Erfahren Sie, wie Sie mit diesen Ressourcen codieren (Material für Anfänger)
  • Warum ich meine Karriere geändert habe
  • Wie ich meine Karriere geändert habe
  • Hat sich das Lernen gelohnt?