Software Development

Was ein Decorator wirklich mit Ihrer Funktion macht Sie wollen jede Funktion zeitlich messen, die eine langsame externe API aufruft. Sie können time.perf_counter()-Aufrufe in jede einzelne einfügen, oder die Messung einmal schreiben und überall anwenden. Ein Decorator ist die zweite Option: eine Funktion, die eine andere Funktion nimmt, sie in zusätzliches Verhalten einwickelt und die eingewickelte Version unter dem ursprünglichen Namen zurückgibt. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import time def timed(func): def wrapper(*args, **kwargs): start = time.perf_counter() result = func(*args, **kwargs) elapsed = time.perf_counter() - start print(f"{func.__name__} took {elapsed:.3f}s") return result return wrapper @timed def fetch_price(ticker): time.sleep(0.2) # Platzhalter für einen Netzwerkaufruf return 142.50 fetch_price("AAPL") # fetch_price took 0.201s @timed über def fetch_price ist die Kurzform von fetch_price = timed(fetch_price). Python ruft timed einmal auf, direkt nachdem fetch_price definiert wurde, und bindet den Namen fetch_price neu an das, was timed zurückgibt. Das ist alles, was das @ tut. ...

Führen Sie 0.1 + 0.2 in einer Python-Shell aus, kommt nicht 0.3 heraus, sondern 0.30000000000000004. Probieren Sie es in JavaScript, Java, Go, C oder Rust, und Sie bekommen denselben sechzehnstelligen Schwanz. Jede dieser Sprachen tut genau das, was der Hardware-Standard vorschreibt. Eine Zahl, die unendlich viele Binärstellen bräuchte, wird in 64 Bit gepresst, und irgendetwas muss nachgeben. Warum sich 0.1 nicht exakt binär speichern lässt Computer speichern Gleitkommazahlen zur Basis 2. In Basis 2 hat der Bruch 1/10 eine periodische Entwicklung, genau wie sich 1/3 in Basis 10 endlos wiederholt (0.3333...). Ausgeschrieben beginnt 0.1 binär so: ...

Ein Zugriff auf ein Python-Dictionary dauert etwa 100 Nanosekunden, egal ob das Dictionary 1.000 oder 1.000.000 Schlüssel enthält. Eine verschachtelte Schleife, die eine Liste auf Duplikate prüft, braucht eine halbe Millisekunde bei 200 Elementen und 136 Millisekunden bei 3.200. Sechzehnmal die Eingabe, fast 280-mal die Wartezeit. Gleiche Maschine, gleiches Python. Die Big-O-Notation ist der Name für diesen Unterschied. Was die Big-O-Notation misst Big O beschreibt, wie die Laufzeit (oder der Speicherverbrauch) eines Codestücks wächst, wenn die Eingabe größer wird. Es ist keine Stoppuhr-Messung, und es ist egal, ob Ihr Laptop schnell oder langsam ist. Entscheidend ist die Form der Wachstumskurve: Verdoppelt sich die Zeit, wenn Sie die Eingabe verdoppeln, vervierfacht sie sich, oder bewegt sie sich kaum? ...

Führen Sie git reset --hard auf einem Commit aus, den Ihr Team schon per Pull geholt hat, und Ihre Historie weicht ab sofort von der der anderen ab. Führen Sie git revert auf einen Tippfehler aus, den Sie noch nicht gepusht haben, und Sie haben dem Log einen überflüssigen Commit hinzugefügt. Git hat vier Befehle zum Rückgängigmachen, restore, reset, commit --amend und revert, und sie sind nicht austauschbar. Wählen Sie den falschen, passiert entweder gar nichts, oder es passiert deutlich mehr, als Sie wollten. ...

Hier ist eine Klasse, die Sie ohne eine laufende Datenbank und einen funktionierenden SMTP-Server nicht unit-testen können: 1 2 3 4 5 6 7 8 9 10 11 public class OrderService { private readonly SqlOrderRepository _repository = new SqlOrderRepository("Server=prod-db;Database=Orders;..."); private readonly SmtpEmailSender _emailSender = new SmtpEmailSender("smtp.company.com"); public void PlaceOrder(Order order) { _repository.Save(order); _emailSender.Send(order.CustomerEmail, "Order confirmed"); } } OrderService baut sich seine eigenen SqlOrderRepository- und SmtpEmailSender-Instanzen mit new, Connection-String und allem. Jeder Test, der PlaceOrder berührt, braucht eine echte Orders-Datenbank und einen echten Mailserver, sonst scheitert er, bevor Ihre Assertion überhaupt läuft. Die Logik, die Sie testen wollen, sind zwei Zeilen: die Bestellung speichern, die Bestätigung senden. Sie ist an zwei konkrete Klassen geschweißt, die Sie nicht austauschen können. ...

Eine Funktion kann 100 % Unit-Test-Abdeckung haben, und die Seite, die sie aufruft, kann in Produktion trotzdem einen 500er zurückgeben. Das ist kein Widerspruch. Unit-, Integrations- und End-to-End-Tests prüfen unterschiedliche Dinge, und eine Testsuite, die bei einer Ebene stark und bei einer anderen schwach ist, hat ein bestimmtes, vorhersehbares Loch. Was Unit-, Integrations- und End-to-End-Tests jeweils prüfen Nehmen Sie eine Registrierungsfunktion: Eine Funktion validiert die Eingabe, schreibt eine Zeile in eine Datenbank und verschickt eine Willkommens-E-Mail. Drei Tests können das abdecken, und jeder beantwortet eine andere Frage. ...

Führen Sie das in Node oder einer Browser-Konsole aus: 1 2 3 4 console.log("1"); setTimeout(() => console.log("2"), 0); Promise.resolve().then(() => console.log("3")); console.log("4"); Die Ausgabe ist 1 4 3 2. Ein setTimeout mit 0ms Verzögerung läuft trotzdem nach dem Promise-Callback, und beide warten auf jede Zeile synchronen Codes darunter. async/await baut auf dieser Reihenfolge auf, nicht auf einem neuen Mechanismus. Die meisten überraschenden Verhaltensweisen in asynchronem JavaScript entstehen, weil man await so schreibt, als würde es das gesamte Programm anhalten, obwohl es nur die Funktion anhält, in der es steht. ...

Ihr Frontend läuft auf http://localhost:5173, Ihre API auf http://localhost:4000, und der fetch-Aufruf, der in Postman anstandslos funktionierte, schlägt im Browser mit einer Wand aus rotem Text fehl: Access to fetch at 'http://localhost:4000/api/users' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Ihr Server hat die Anfrage womöglich verarbeitet und eine 200 zurückgegeben. Der Browser hat sich einfach geweigert, die Antwort an Ihr JavaScript weiterzugeben. ...

Einen Bug debuggen, der nur auf einer Maschine ohne Visual Studio auftritt Ein Bug reproduziert auf dem Testserver, aber nicht auf Ihrem Laptop. Der Testserver hat kein Visual Studio, und dort eine komplette IDE zu installieren, nur um einen Breakpoint zu setzen, kommt nicht infrage. Genau dafür ist Remote-Debugging gemacht. Ein kleines, eigenständiges Programm läuft auf der Zielmaschine, Ihr lokales Visual Studio verbindet sich über das Netzwerk damit, und Sie bekommen Breakpoints und Variableninspektion auf einem Prozess, der nirgendwo in der Nähe Ihres Schreibtischs läuft. ...