Skip navigation

Clean Code DeveloperClean Code Developer

5250 members | 550 posts | Public Group
Hosted by:Ralf Westphal

This post is only visible to logged-in members. Log in now
Hallo Sven, eigentlich ist die Definition ganz einfach: nur den Operationen ist der Aufruf von APIs erlaubt. Ok, jetzt wirst du nach einer Definition von "API" fragen ;-) Ausdrücke wie "x + 1" oder "a > 5" sind API Calls, weil hier eine von der Runtime oder einem Framework gelieferte Funktion aufgerufen wird. Frameworks werden binär verwendet, d.h. in Java bindest du ein JAR File ein. Manche APIs gehören zur Runtime (wie Ausdrücke), für andere bindest du spezielle Frameworks ein, wie vlt. Spring o.ä. Wenn nun ein anderes Team innerhalb deiner Firma dafür zuständig ist, ein eigenes Framework zu basteln und ihr dieses binär als JAR verwendet, ist es API, also nur in Operationen erlaubt. Bindest du das Projekt als Quellcode in deine Anwendung ein, rufst du "Methoden deiner Lösung" auf, integrierst diese also. if/for/foreach sind in Integrationen erlaubt, solange die Bedingung, auf der das if arbeitet, in einer Funktion ausgelagert ist. Erlaubt: if(GoldStatus(kunde)) { ... } Verboten: if(kunde.Umsatz > 10.000) { ... } Der Aufruf der Funktion "GoldStatus" ist ein Aufruf einer eigenen Methode, kein API Call. Dagegen ist der Vergleich ">" ein API Call und somit den Operationen vorbehalten. Ob du eigenen Code direkt aufrufst oder über ein Interface, spielt keine Rolle: es ist Integration. Das gleiche gilt für abstrakte Basisklassen: wenn du sie in deinem Code beerbt hast, ist es Integration. Falls du es noch nicht kennst: hier findest du die Aufzeichnung meines Webinars zum Thema. Vielleicht beantwortet das die ein oder andere Frage. https://refactoring-legacy-code.net/aufzeichnung-zum-webinar-softwareentwicklung-ohne-abhaengigkeiten-veroeffentlicht/ Viele Grüße Stefan Lieser --
This post is only visible to logged-in members. Log in now

Metrics are fun, failure metrics are hilarious! We're continuing our metrics series with test failure rate. See that guy in the picture? Nobody's tracking him, so he'll run out of arrows. Not a pretty sight. Don't be that guy.

http://www.everydayunittesting.com/2020/06/the-metrics-test-failure-rate.html

Metrics are very important to track and review if you’re after improving the quality of your code. This post (the first in the series) is about “Number of Tests Added”. It already makes me want to see graphs on the walls. Into the Metrics!

http://www.everydayunittesting.com/2020/06/the-metrics-number-of-new-tests.html

Klingt gut. Erstmal. Aber ein wichtige Formulierung in deinem Beitrag aus meiner Sicht ist: „for a while“. Denn wenn mehr Tests mehr gut bedeuten, dann schreibt man halt mehr Tests. Irgendwie. Hauptsache Tests. Das wird ja gemessen. Im Zweifel wird niemand gefeuert, wenn er einen Test mehr schreibt - aber einen Test zu löschen, das wäre gefährlich😉 Mehr Tests bedeuten auch nicht automatisch mehr Nutzen im Sinne von Codeabdeckung. Und im schlimmsten Fall bedeuten mehr Tests mehr Korsett, das bei Refaktorisierungen behindert. Mit der Metrik wäre ich also sehr vorsichtig. „For a while“, wenn man mit autom. Tests beginnt, mag sie motivieren. Aber ich würde sie so bald wie möglich durch etwas anderes ersetzen, zb Testcoverage. Bei der ginge es natürlich nicht um einen Zielwert wie 100% oder auch nur 89,3%, sondern um die Tendenz. Aber die ist sofort relativ zur Codemenge. Insofern ginge es nicht um Anstieg, sondern Erhalt eines angemessenen Niveaus. Wenn dafür weniger Tests ausreichen, würde ich sogar welche löschen. Ich bin sehr für autom. Tests! Test-first rulez😁 Es ändert aber nichts daran: Tests sind nur ein notwendiges Übel und insofern eine Form von Verschwendung. Deshalb finde ich eine Metrik, die mehr davon „belohnt“ grundsätzlich problematisch.
Thanks Ralf! The reason for the "for a while" is because the target when we begin is that quanitity matters. After that, quality is better of course. I'm going to write about coverage, of course. Metrics (and therefore goals) should be managed correctly, otherwise, we're going to have lots of unwanted side effects. That's why people need to understand what they mean, and what will happen if things change, or if they are trying to reach the goals by any means necessary.

Liebe Gruppen Mitglieder,

ich möchte Sie gerne auf mein nächstes Webinar am 30.06.2020 - 18:00 mit dem Thema "Flow Design am Beispiel" hinweisen.

Registrierung: https://stefanlieser.webinarninja.com/live-webinars/365899/register

Viele Grüße

Stefan Lieser

--

Q: What are Adapters?

A: Adapters are wrappers of something usually with a different interface.

In testing-related scenarios, we build adapters for things that make testing hard.

If our code connects to a physical printer directly, we'll need a printer to run our tests. But if it calls the printer through an adapter, we can mock that adapter.

To facilitate testability, use adapters in your architecture. It will not only make testing easy but also promote testing.

Clean Code Development in der Diskussion

Die Gruppe lädt alle Softwareentwickler ein, darüber zu diskutieren, wie die Wandelbarkeit von Software und die Produktivität von Teams verbessert werden können. Sie schließt an das an, was die Initiative http://clean-code-developer.de an Bausteinen für sauberen Code zusammengetragen hat.

Aber natürlich soll die Diskussion dort nicht stehenbleiben. Wie kann die Softwareentwicklung über die bisherigen Ideen von Clean Code und Agilität hinausgehen? Lasst uns darüber nachdenken...

Wir sind gespannt auf eure Beiträge!

-Ralf Westphal & Stefan Lieser, Gruppenmoderatoren

PS: Laut Entscheidung der Gruppenmitglieder soll die Gruppe frei von Werbung sein. Offensichtlich kommerzielle & werbende Beiträge von Gruppenmitgliedern werden daher ohne Vorankündigung gelöscht und die, die sie einstellen blockiert. Dasselbe gilt für Stellenanzeigen.