Sie fragen nach dem Heiligen Gral der Softwareentwicklung, und noch hat niemand die Antwort auf diese Frage.
Entscheidend ist, dass Sie die von Ihnen gemachten Fehlertypen nachverfolgen und diese Fehler anschließend analysieren, um festzustellen, ob ein gemeinsamer Trend vorliegt. Die Ursachenanalyse ist die formale Bezeichnung für diese Art der Selbstbeobachtung, und im Internet gibt es viel Material dazu.
Profis verwenden ein Fehlerverfolgungssystem, damit sie (1) wissen, was behoben werden muss, aber auch (2) analysieren, was nachträglich behoben werden musste. Sie müssen nicht so förmlich sein - es kann für Sie in Ordnung sein, nur eine Liste in einem Notizbuch zu führen.
Design Stage Defects
Wenn Sie feststellen, dass die meisten Ihrer Fehler auf ein Missverständnis der Problemstellung zurückzuführen sind oder wenn Sie immer wieder feststellen, dass Sie den falschen Algorithmus oder Pfad für die Lösung Ihrer Probleme gewählt haben, treten Probleme in der Entwurfsphase auf.
Sie sollten sich zu Beginn des Projekts mehr Zeit nehmen und genau aufschreiben, was zu tun ist und wie es zu tun ist. Lesen Sie diese Arbeit sorgfältig durch und gehen Sie das ursprüngliche Problem noch einmal durch und stellen Sie fest, ob Sie es wirklich richtig angehen. Eine oder drei zusätzliche Stunden zu Beginn können Ihnen viele Stunden später ersparen.
Codierungsfehler
Wenn Ihr Design solide ist, Sie aber ständig gegen die Sprache kämpfen, mit der Sie programmieren, sollten Sie sich Tools besorgen, die Ihren Code analysieren und Sie frühzeitig und häufig warnen, dass Sie Fehler machen.
Wenn Sie in C programmieren, aktivieren Sie alle Compiler-Warnungen, verwenden Sie einen Semantik-Checker wie lintund verwenden Sie ein Tool wie valgrind, um allgemeine Probleme im Zusammenhang mit dem dynamischen Speicher zu erkennen.
Wenn Sie Perl programmieren, schalten Sie strictund ein warningsund beachten Sie, was darin steht.
Unabhängig davon, welche Sprache Sie verwenden, gibt es wahrscheinlich viele Tools, mit denen Sie häufig auftretende Fehler erkennen können, lange bevor Sie das Debugging-Stadium erreichen.
Integrationsstadiumsdefekte
Wenn Sie Ihren Code gemäß guter Modularitätspraktiken entwickeln, müssen Sie damit beginnen, die einzelnen Teile zusammenzukleben. Beispielsweise haben verschiedene Abschnitte Ihres Codes möglicherweise mit Benutzereingaben, Datenbankinteraktion, Datenanzeige, Algorithmen / Logik zu tun, und jeder dieser Abschnitte ist relativ unabhängig voneinander aufgebaut (dh Sie konzentrieren sich in der Regel auf den jeweiligen Abschnitt anstatt sich Gedanken über die Integration mit allem anderen zu machen).
Hier bietet sich die testgetriebene Entwicklung (TDD) an. In jedem Modul Ihres Codes können Tests durchgeführt werden, die überprüfen, ob sie gemäß ihrer Konzeption funktionieren. Diese Tests sollten entweder zuerst oder sehr früh im Prozess geschrieben werden, damit Sie eine Reihe von "Helfern" haben, um ehrlich zu bleiben. Wenn Sie damit beginnen, dass alles zusammenarbeitet und Sie feststellen, dass Sie ändern müssen, wie dieses oder jenes implementiert wird oder mit einem anderen Subsystem interagiert, können Sie auf Ihre Tests zurückgreifen, um sicherzustellen, dass das, was Sie getan haben, funktioniert Das Zusammenspiel beeinträchtigt nicht die Korrektheit des Codes.
Und so weiter...
Lernen Sie in Büchern über Software-Engineering und praktische Codierungstechniken viele verschiedene Methoden kennen, um die Entwicklung weniger chaotisch und zuverlässiger zu gestalten. Sie werden auch feststellen, dass Sie mit einer einfachen, alten Erfahrung, die Sie an der Schule für harte Schläge erworben haben, ebenfalls in Form gebracht werden.
Fast alles läuft darauf hinaus, dass sich ein wenig Zeit und Vorarbeit später im Entwicklungs- / Release-Prozess in gewaltigen Dividenden auszahlt.
Die Tatsache, dass Sie diese Probleme so früh in Ihrer Karriere bemerkt haben, spricht gut für Ihre Zukunft, und ich wünsche Ihnen viel Glück.