Vieles, was einem erfahrenen Entwickler völlig offensichtlich erscheint, ist für einen Anfänger nicht offensichtlich. Ich spreche nicht über das Schreiben von Code, die Kenntnis von Mustern usw. Dies gilt für die Denkweise im Allgemeinen: wie man das Problem löst, wie man fragt, wie man den Zorn der Mentoren Ihrer Ältesten nicht erregt . Heute werden wir versuchen, darüber zu sprechen.
Methoden des rationalen Denkens (hier) sind Fragen, die in jeder Phase des Denkens über ein Problem gestellt werden sollten. Mit ihrer Hilfe können Sie schnell die richtige Entscheidung treffen und Ihre Arbeit effizienter gestalten.
Frage 1. Was ist der Grund?
Nach dem Gesetz der Gemeinheit funktioniert beim ersten Start der Anwendung definitiv etwas nicht. Zuerst sollten Sie versuchen, die Fehlerursache selbst zu ermitteln. Am einfachsten ist es, auf die Konsole zu schauen. Vielleicht reicht der Fehlertext aus, um zu verstehen, wie er behoben werden kann.
Frage 2. Habe ich alles getan, was ich konnte?
Auch wenn der Fehlertext nicht geholfen hat, beeilen Sie sich nicht mit Fragen. Zuerst müssen Sie sicherstellen, dass alles getan wurde, was möglich ist. Sie können so etwas überprüfen:
- Ich habe in der Anwendungsdokumentation nach einer Lösung für dieses Problem gesucht
- Ich googelte und fand nichts
- Ich habe auf Englisch gegoogelt und nichts gefunden
- Keiner der gefundenen Tipps hat mir geholfen.
Wenn die Antwort überall Ja lautet, fahren Sie mit dem nächsten Absatz fort.
Frage 3. Ich scheine verwirrt zu sein. Warum?
Es ist in Ordnung, Ihren Mentor / Mentor / Chef / Freund nach einer Lösung zu fragen. Vielleicht hast du einfach vergessen, von ihr zu erzählen. Die Frage sollte jedoch nicht nur aus den Worten „etwas funktioniert nicht“ bestehen, sondern alle verfügbaren Eingabedaten sollten darin enthalten sein. Eine gut konstruierte Frage spart Ihrem Mentor Zeit und hilft Ihnen, effizienter zu arbeiten. Versuchen Sie, die Frage auf "Vollständigkeit" zu überprüfen:
- Fehlertext angegeben
- Es wird ein Fall angezeigt, in dem ein Fehler aufgetreten ist (bis zum Starten von Befehlen).
- Bewährte Lösungsmethoden sind angegeben.
Gewinn! In kürzester Zeit erhalten Sie eine Lösung für das Problem und tiefen Respekt von Kollegen. Freuen Sie sich also auf die Entwicklung von Aufgaben.
Frage 4. Löst meine Lösung das Problem vollständig?
Lassen Sie uns nun darüber sprechen, wie Sie eine Aufgabe erledigen können. Hinweis: Die richtige Frage für sich.
Wenn dies ein Fehler ist, lohnt es sich zu überprüfen: Ist das Problem behoben oder maskiert? Zum Beispiel gibt es eine Funktion, die eine Zahl zurückgeben sollte, aber (plötzlich) eine Zeichenfolge zurückgibt. Durch Konvertieren des Ergebnisses in den Ort des Funktionsaufrufs können Sie das Problem maskieren. Aber vielleicht lohnt es sich, die Transformation darin durchzuführen und damit das Problem vollständig zu beheben.
Eine Funktion oder ein Fehler, seien Sie am Ende nicht faul, um alle möglichen Fälle zu überprüfen. Wie die Praxis zeigt, verursacht der Ausdruck „sollte funktionieren“ schreckliche Fehler und noch schrecklichere Unzufriedenheit auf der Empfangsseite.
Frage 5. Warum bin ich mir dessen sicher?
Schauen wir uns sofort ein Beispiel an: Es ist Zeit, verschiedene Teile einer großen Anwendung zu integrieren. Das mit der Junior-Aufgabe verbundene Backend wurde lange entwickelt. Er startet ein Feature auf seiner Seite und ... alles hängt! Ziemlich schnell stellt er fest, dass das Backend eingefroren ist. Man könnte sofort sagen: "Das Problem ist nicht auf meiner Seite", die Aufgabe abwerfen und unser Geschäft betreiben. Aber der Rational Junior wird denken: „Wenn die Backend-Aufgabe als erledigt markiert ist, wurde sie wahrscheinlich getestet. Warum bin ich sicher, dass das Problem im Backend liegt? “ Es spielt keine Rolle, auf wessen Seite das Problem liegt. Es ist wichtig, dass er nicht zu einem anderen Entwickler kommt, ohne das Verhalten auf seiner Seite zu überprüfen.
Frage 6. Warum wurde das gemacht?
Es sollte als selbstverständlich angesehen werden, dass vernünftige Leute herumarbeiten und keinen Unsinn schreiben (zumindest absichtlich). Wenn es den Anschein hat, dass jemand eine Zeile in den Code geschrieben hat, die überflüssig ist, sollten Sie zweimal überlegen, bevor Sie sie löschen. Auch wenn es das Problem vollständig löst. Die wahrscheinlichsten Möglichkeiten, nichts zu überspringen:
- Zeigen Sie die letzte Festschreibungsnachricht an, mit der diese Zeile geändert wurde
- Festschreibungsaufgabe anzeigen (häufig in der Festschreibungsnachricht angegeben)
- Sehen Sie, wer das Commit ausgeführt hat, und fragen Sie ihn, nachdem Sie über seine Aufgabe gesprochen haben
Abschließend möchte ich eines hinzufügen: Es ist nicht notwendig, alle Bündnisse aus diesem Artikel zu befolgen, aber es ist notwendig , ständig und unabhängig zu denken .