Clean Code / Software Principles - Wo seid ihr??

[Helmut.Jakoby]

Wenn ich mir einige Anmerkung erlauben darf,
ich habe festgestellt, dass Vorgaben, wie ein Softwareentwicklungs-Auftrag abgearbeitet wird (analysiert, programmiert, dokumentiert etc.), immer von dem/den Entwicklungsteam/s getragen werden muss (das/die Team/s immer an Entscheidungen teilhaben lassen *). Es sollte teamübergreifend ein einheitlicher Softwareentwicklungsprozess etabliert werden. Das bedeutet nicht, dass nicht verschiedene Programmiersprachen zum Einsatz kommen dürfen. Nicht nur Softwareentwicklungsprozesse sind Veränderungen unterworfen, welche nicht vernachlässigt werden sollten (alles bewegt sich).
Die Ergebnisse müssen immer vom "Kunden" gekauft bzw. akzeptiert werden.

Viel Glück

*Hast Du ja schon im letzten Satz erwähnt:

Man muss wie schon gesagt evtl. den Mittelweg gehen. Manche Dinge Pragmatisch sehen, nicht bis zum letzten alles vorschreiben sondern miteinander den Weg gehen - so kommt man zusammen schneller ans Ziel und zu einem guten Code.

[Quiche Lorraine]

@tbird sagte in Clean Code / Software Principles - Wo seid ihr??:

Was ist jedoch ein "Critical System"?

Die Wiki hat hierzu einen schönen Artikel.

Mal kurz zusammengefasst: Ein kritisches System ist ein System, welches sehr zuverlässig sein muss, da es ansonsten zu umfassenden Schäden kommen kann, welche vermieden werden müssen. Folgende Unterscheidungen gibt es hierbei:

• Safety critical -> Personenschäden (z.B. Autounfall), Umweltschäden (z.B. Kernkraftwerk)
• Mission critical -> Finanziellen Schaden durch Projektabbruch (z.B. Weltraummissionen)
• Business critical -> Finanziellen Schaden bzw. Schaden des Ansehens (z.B. Fehler in Massenproduktion, Fehler in Aktienprogrammen)
• Security critical -> Verlust von sensiblen Daten (z.B. Krankenakten)

[Mechanics]

@tbird sagte in Clean Code / Software Principles - Wo seid ihr??:

Module, die in mehreren Projekten verwendet werden haben eine entsprechend höhere Abdeckung (ob diese jetzt bei 90, 95 oder 98% liegt, muss man halt sehen).

Solche Prozentangaben sagen sowieso nichts aus. Was ist mit Code, der nicht da ist? Der ist dann logischerweise auch nicht abgedeckt.
Ich kann mir da jetzt keine Prozentzahlen aus den Fingern saugen, aber ich würde schon sagen, sehr viele Fehler, die beim Kunden passiert sind, wurden durch "fehlenden Code" verursacht. Also irgendwelche Situation, Eingabedaten, Multithreading-Bedingungen, die beim Entwickeln so nicht klar waren.

[hustbaer]

@Mechanics
Wenn man beim Testen versucht konsequent Corner- und Edge-Cases abzudecken, bzw. ganz allgemein Spezialfälle, dann findet man oft "fehlenden" Code.

Natürlich nicht immer. Wenn eine bestimmte Bedingung wirklich schon in den Vorgaben einfach fehlt, also die gewünschte Funktionalität falsch spezifiziert wurde, dann wird man das mit Tests kaum finden. (Maximal durch Zufall, wenn dem Test-Schreiber etwas komisch vorkommt und er nachfragt.)

Das ändert aber mMn. nichts an der Nützlichkeit von automatisierten Tests.

Und was Coverage angeht: ich finde schon dass die Zahl was aussagt, zumindest grob. Ob ich 50% Coverage habe oder 90% macht schon nen riesen Unterschied finde ich.

[Mechanics]

@hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:

Das ändert aber mMn. nichts an der Nützlichkeit von automatisierten Tests.

Dem will ich keinesfalls widersprechen.
Aber stell dir mal folgende Situation vor... Auf der einen Seite Schnittstellen zu vielen unterschiedlichen Fremdsystemen, die meist schlecht, falsch, oder gar nicht dokumentiert sind, und auch teilweise stark verbuggt sind, z.B. weil die jeweiligen Hersteller selbst sich wenig für die public API interessieren. Und dann auch noch irgendwelches Customizing dieser Systeme, das zu nicht vorhergesehenen Situationen führt. Und auf der anderen Seite ein eigenes Produkt, das u.a. darauf aufbaut, und auch über Jahrzehnte gewachsen ist. Ist entsprechend überhaupt nicht im Detail spezifiziert. Letzteres ist bei uns aus verschiedenen Gründen wahrscheinlich sogar unterdurchschnittlich schlecht spezifiziert/dokumentiert. Trotzdem kann man die Situation denke ich nachvollziehen, einfach ein sehr umfangreiches, technisch komplexes Projekt, wo allein schon viele Multithreading/Timing/Caching Probleme passieren können. Und auch relativ stark von irgendwelchen Daten abhängig, die wir nicht im Griff haben, aber für größere Kunden werden dann doch Umwege eingebaut, um mit seinen kaputten Daten nach seinem Schema umgehen zu können.

So in etwa ist die Situation bei uns in der Firma und das hatte ich im Sinn. Klar, wir schreiben auch automatische Tests und nützlich finde ich sie auf jeden Fall auch. Sonst würde bei jeder Version noch viel umfallen.
Nach meiner persönlichen Erfahrung sind Tests aber eben auch nichts was ich mit "damit habe ich keine Probleme beim Kunden mehr" assoziiere. Das ist für mich subjektiv viel eher, bekannte Probleme werden hoffentlich nicht mehr auftreten und bekannte Randfälle sind jetzt auch sicher abgedeckt und fallen nicht mehr aus Versehen raus.

[hustbaer]

@Mechanics
Klar, je mehr vermurkste Systeme man hat mit denen man interagieren muss, desto schwieriger wird es. Und noch dazu wenn es unterschiedliche, auf unterschiedliche Art vermurkste Systeme sind. Das macht es mMn. aber generell schwer - mit oder ohne Tests.

[wob]

Ich stimme euch zu!

Wir unterscheiden beim Testen Projekte, die nur kurz laufen und Projekte, die langfristig laufen bzw unsere Bibliothek, die wir in fast allen Projekten nutzen. Letztere ist recht gut getestet und mir fällt immer wieder auf, dass die Tests insbesondere beim Refactoring sehr hilfreich sind und Corner Cases, die der alte furchtbare Code aber abgedeckt hat, dann gerne auffallen.

Wir haben aber oftmals Projekte, die so ca 4 Wochen dauern und hauptsächlich aus einer einmaligen Datenanalyse bestehen (es ist inzwischen nur noch seltenst C++ im Spiel, aber ist hierfür egal). In dem Fall schreiben wir nur selten automatische Tests, die manuellen Tests sind dann Vergleiche der produzierten Plots auf Sinnhaftigkeit. Wenn das Projekt dann dauerhaft laufen soll, ergeben sich natürlich viele Automatisierungsanforderungen und die gehen dann auch mit Unittests daher.

Ach ja, und beliebt ist auch, dass die Kunden keine reproduzierbaren Daten liefern können. Teils, weil sie selbst oft manuell exportieren und man dann immer hoffen muss, dass die Excels oder csvs ordentlich sind (Datumsformat, Tausendertrenner etc, hört sich für unsereins trivial an, aber die Kunden haben immer eigene "innovative" Ideen) Fängt schon bei den Spaltennamen an.

Oft entdecken wir auch, dass die Kunden Fehler in ihren Daten haben. Sowas wie dass deren Jahresumsatz mal 50% daneben liegt. Fällt scheinbar niemandem auf, sowas...

[Ashtari]

Zum Thema deutsches/us Layout kommt es aus meiner Sicht einfach auf die Tastatur an ob man sich "verrenkt" oder nicht..
Ich entwickle in der Freizeit in Swift (also auf einem Macbook) und kenne das "Problem" mit dem erreichen von {} nicht, bis ich als C Entwickler eingestellt wurde
Habe mir dann einfach die Keychron K2 Tastatur geholt - deutsches Layout, 75% Tastatur, alle Tasten ideal zu erreichen..

Es kommt einfach auf das Keyboard an Kauft man sich das "Richtige" fürs entwickeln, dann hat man das Problem nicht.

Thema Variablen:
Wir haben an der Uni gelernt die Variablen so zu benennen, dass sie "klar erkennbar" sind. Dabei war uns überlassen ob es deutsch oder englisch ist.
Privat benenne ich sie alle in Englisch, ich beschäftige mich aber auch viel mit "Clean coding", Swift ist eine recht "englische Sprache", sodass Guides, Code Examples etc. sowieso auf englisch sind und in Summe möchte ich etwas im Training bleiben. Auf der Arbeit schreiben wir ausschließlich auf Deutsch, was aber historisch anhand der Kunden so gewachsen ist.

Thema Clean Code:
Da habe ich mit einem Senior C++ Dev immer mal Austausch zu und versuche das auf meinen Code in Swift zu adaptieren. Dabei versuche ich speziell in Swift MVVM zu berücksichtigen und im Allgemeinen so Dinge wie SOLID, sinnvolle Kommentare, korrekte Einrückungen usw. usw. zu berücksichtigen.

Um das ein wenig einzuordnen, ich bin seit dem 01.03. mit meinem Studium fertig und habe mir den Großteil dieser Dinge alleine angeeignet und nicht in meinem Studium mit bekommen.

[Tyrdal]

@Ashtari sagte in Clean Code / Software Principles - Wo seid ihr??:

Es kommt einfach auf das Keyboard an Kauft man sich das "Richtige" fürs entwickeln, dann hat man das Problem nicht.

Ja, es ist erstaunlich mit was für einem Schrott viele Leute arbeiten. Hab mir auch ein Redox wireless gegönnt und mit QMK ein auf Colemak DH basiertes für mich persönlich optimiertes Layout gebaut.

[*john 0]

@Ashtari sagte in Clean Code / Software Principles - Wo seid ihr??:

Habe mir dann einfach die Keychron K2 Tastatur geholt - deutsches Layout, 75% Tastatur, alle Tasten ideal zu erreichen..

Das hängt wohl auch sehr stark von den anatomischen Voraussetzungen ab. Ich nutze eine normale Cherry-Stream. Mit der linken Hand kann ich die [2] und die rechte [Strg] Taste drücken und mit der rechten Hand die linke [Strg] und die ['] Taste. Daher stört mich das deutsche Layout beim Programmieren nicht wirklich.