Company
Clean Code DeveloperClean Code Developer
5279 members | 572 posts | Public Group
Hosted by:Ralf Westphal
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.
Weekly Q&A: What is CI?
There is the right answer and the wrong answer that everyone uses.
This time, I'm going to answer the second.
Continuous integration servers, like Jenkins, Circle, or TeamCity are robots. They are automation engines. Basically, they can be programmed to do everything you want them to do, but they come equipped pre-built with integrations, connections, triggers, and operations for supporting automated software development production.
Now, robots are cool, but specifically, CI makes us effective and less error-prone.
It starts with building the software. To avoid the "works on my machine" syndrome, they connect to source control systems, pull the code, build it, and run unit tests on a separate machine. Once they do that, it's ok to run more automated tests. For that, they can load docker images, deploy the software and run it in multiple configurations, and run the automated tests against them.
Finally, they accumulate the results of those runs, save artifacts, and can show reports of specific "builds" or jobs, or overtime to show trends.
By automating this stuff, we can get feedback on what we've built on in neutral, controlled environments. Test automation is cool, but without the engine behind it, and reporting engine to show and message the audience, it would be used once, maybe twice, and no more.
CI servers give us continuous feedback, free us from manual errors, boring repeated operations, and let us concentrate on building code, tests, and adding value.
#testing, #automatedtesting, #continuousintegration, #unittesting, #compilation, #build
Don't change your code for your tests!
Yeah, I'm tired of hearing "why do I need to change my code just for the tests". Then don't! Here's my response.
https://youtu.be/E5uFfPwTE9w
#refactoring #legacycode #testing
How can we unit tests with database interaction?
Cool question asked in a recent webinar.
First, unit tests don't involve databases: Unit tests isolate code from other dependencies, to prove "OUR code" works. In that matter, they can check if we send the right parameters to the database.
We can use mocking frameworks (like Mockito) to do that, or manual mocks.
But, we can check out other options as well. They take us toward integration tests, but not by far. For example, if our database is key-value, we can build a small dictionary for our tests to serve as a database. Or for SQL-based, we can use an in-memory database, fitted for the tests. Spring, for example, can help here.
We check interaction if we want isolation. But without big effort, we may get integrated tests, that prove our code works correctly with the database. Better confidence, better sleep at night. And when a failure occurs, the analysis effort doesn't suffer too much.
#testing #tdd #automatedtesting, #unittesting
Irgendwann muss irgendwer alle Teile eines Systems zusammengesteckt testen. Dann gilt es Daumen zu drücken😁
Das ist jedoch aus meiner Sicht ein vergleichsweise seltener Fall. Und wenn man meint, das darf nichr selten sein, sondern muss ständig überprüft werden, dann ist das ein Zeichen von mangelnder Entkopplung, fehlender Testbarkeit und schwachem Vertrauen in die eigene od die Arbeit von anderen.
Systemteile, die Tests behindern (wg Verfügbarkeit, Performance, Rüstaufwand), sollten deshalb frühzeitig identifiziert und isoliert werden. Testwiderstand ist insofern ein deutlicher Treiber von Modularisierung.
Persistenz ist notorisch testwiderständig. Deshalb gehört es für mich zu sauberer Architektur, sie zu kapseln. Das ist der Fall, wenn alle anderen Subsysteme keine Abhängigkeit davon haben. Das ist das Ziel von IOSP und darauf aufbauend IODA.
Robert C Martins Beschrwibung von der Unabhängigkeit seiner Entwicklung an Fitness von einer Persistenztechnologie, finde ich in der Hinsicht immer noch beispielhaft.
Und was für Persistenz gilt, gilt für andere periphere Belange ebenfalls, zb Kommunikation, UI.
Ralf, I think it starts with what Uncle Bob describes as clean architecture. If the system is not built decoupled, it will be hard to test. Or rather, less tested, because what is hard to do, rarely gets done.
This post is only visible to logged-in members. Log in now
Die Muster, die zeigst, finde ich eingängig. Nach Muster suche ich auch bei der Beurteilung der Qualität von Quellcode (hier: Qualitätskriterium Ordnung, insb. Lesbarkeit, Übersichtlichkeit).
Allerdings glaube ich nicht, dass Laien sich wirklich ein Urteil erlauben können, selbst wenn du Muster aufzeigst. Warum sollten Laien auch in den Quellcode schauen?
Ich sehe die Analyse der Ordnung auf zwei Ebenen:
- grobe Analyse anhand von Metriken
- feine Analyse anhand von Inaugenscheinnahme
Laien mögen evtl. etwas mit Metriken anfangen können, wenn man sich auf ein paar pauschale Schwellwerte einigen kann. Dann können sie auf eine Grafik schauen und sich einen Eindruck davon verschaffen, wie sich die Metriken entwickeln.
Eine Inaugenscheinnahme jedoch ist immer Sache des Entwicklers. Hier fließen formale Kriterien zusammen mit inhaltlichen. Eine formale Sauberkeit allein reicht auch nicht. Der Lösungsansatz sollte auch "sauber" sein.
Automatisierte Tests sind in der heutigen Zeit der Standard für gute Softwareentwicklung. Besonders Unit Tests helfen uns Entwicklern bei unserer täglichen Arbeit. Aber wie fange ich damit an und wie mache ich das mit C++?
Diese und folgende Fragen sollen in diesem Webinar beantwortet werden:
- Was ist eine Unit?
- Wie fange ich das Testen am besten an?
- Worauf sollte ich bei den Tests achten?
- Wie sieht das in der Praxis aus?
Für dieses Thema konnte ich Alexander Frankeser gewinnen. Das schreibt Alexander über sich:
"Ich habe 2013 mein Studium im Fach "Technische Informatik" an der RWTH Aachen erfolgreich abgeschlossen. Seit dem bin ich C++ Entwickler bei MAGIX Software GmbH. Bereits im Studium durfte ich erkennen, dass es ohne ordentliche Arbeitsweise schnell chaotisch wird und alles länger dauert. Daher bin ich immer auf der Suche nach Verbesserungen. 2018 bin ich auf Flow Design gestoßen und das hat meine Arbeitsweise nochmal deutlich verbessert."
Das kostenfreie Seminar findet statt am Donnerstag den 12. August von 18:00 bis 19:00 Uhr. Unter folgendem Link kannst du dich anmelden:
https://us02web.zoom.us/webinar/register/WN_TJW5D23vTiCb9YFwdFw7LA
Viele Grüße
Stefan Lieser
Want to join the discussions?
Log in to read, write and comment on group posts.
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.