Clean Code / Software Principles - Wo seid ihr??
-
@john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:
Nur warum soll man für eine deutsche Steuersoftware, eine Arztpraxen Abrechnungssoftware, eine Rechtsanwaltssoftware, … die Dokumentation auf Englisch verfassen?
Damit du nicht für den gesamten Lebenszyklus der Software (von der Planung bis zum Endbetrieb) ausschließlich auf deutsche Arbeitskräfte angewiesen bist?
-
Schon interessant dieser Thread, es dreht sich doch viel um die Sprache und das dazu passende Tastaturlayout.
Frageschwerpunkt von @tbird war nicht nur "lingua franca", sondern auch "Clean Code, SOLID, allg. Software Principles" um langlebigen, verständlichen, wartbaren Source-Code zu erstellen. Und eigentlich geht es doch bei Letzterem um so etwas wie Vorgehensmodelle zur Softwareentwicklung und nicht nur ums "coden" (Außer man versteht unter Softwareentwicklung nur "coden" und nicht eine umfangreiche Ingenieurleistung).
Ist das nicht viel ausschlaggebender für ein erfolgreiches Softwareprojekt?
-
@john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:
Früher gab es in Deutschland gut ausgebildete Handwerker und Techniker, aber weil wir da ein erhebliches Nachwuchsproblem haben leidet mittlerweile die Qualität.
Uff, und ich erlebe recht heftige Probleme mit Outsourcing aus Indien, China, USA und Thailand. Und es betrifft Software, Hardware, Verpackung und Packaging.
Ich kann es hier nicht beschreiben, man muss es selbst erlebt haben. Einen regelmäßige Kontrolle des Blutdrucks vorrausgesetzt.
-
@Helmut-Jakoby sagte in Clean Code / Software Principles - Wo seid ihr??:
Schon interessant dieser Thread, es dreht sich doch viel um die Sprache und das dazu passende Tastaturlayout.
Frageschwerpunkt von @tbird war nicht nur "lingua franca", sondern auch "Clean Code, SOLID, allg. Software Principles" um langlebigen, verständlichen, wartbaren Source-Code zu erstellen. Und eigentlich geht es doch bei Letzterem um so etwas wie Vorgehensmodelle zur Softwareentwicklung und nicht nur ums "coden" (Außer man versteht unter Softwareentwicklung nur "coden" und nicht eine umfangreiche Ingenieurleistung).
Ist das nicht viel ausschlaggebender für ein erfolgreiches Softwareprojekt?
Ich denke der Punkt "sauber programmieren" ist nicht kontrovers genug, als dass da jemand dagegen diskutieren würde. Ich muss zugeben, dass ich den (Menschen-)Sprachaspekt bewusst ein bisschen stärker gepusht habe, als ich in Wirklichkeit zu ihm stehe, eben damit es eine Diskussion gibt.
-
@SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:
@hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:
Aber ich kenne ein paar Leute die das tun. Klar kann man da dann sagen "oh je, da läuft ja einiges falsch". Nur ändert das nix. Es ist halt einfach so. Und ein IT Leiter der strikt der Meinung ist "wir müssen jetzt alles Englisch" wird die Situation der Firma vermutlich nicht signifikant verbessern.
Dass das so gelebt wird, bestreitet wohl niemand. Aber dass das ein Zeichen dafür ist, dass in der Firma krass etwas schief läuft, doch bestreitest du doch wohl auch nicht?
Die Frage ist IMO: kann man es realistisch besser machen? Du hast nunmal einen Haufen Leute die nicht oder nur sehr schlecht Englisch können. Die müssen irgendwo arbeiten. Und die sind auch nicht alle doof. D.h. als Gesellschaft willst du die vermutlich auch als Facharbeiter, Techniker etc. einsetzen. Weil du sonst Potential ungenutzt lässt. Und wie soll das gehen wenn Doku grundsätzlich in Englisch geschrieben ist? In 2-3 Generationen wird das vielleicht anders aussehen. Aber im Moment sehe ich kaum eine Alternative.
-
@SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:
Ich denke der Punkt "sauber programmieren" ist nicht kontrovers genug, als dass da jemand dagegen diskutieren würde.
Naja, so ganz unstrittig ist das nicht. Zum einen muss man auch irgendwann mal fertig werden, und sauber programmieren dauert halt länger als eine Q&D Lösung. Und dann ist da noch die Frage wie "sauber programmiert" überhaupt aussieht. Beides nach meiner Erfahrung sehr kontroverse Themen.
-
@tbird sagte in Clean Code / Software Principles - Wo seid ihr??:
Jedoch wollen gerade WIR zu einem "Global Player" werden, der wir aber noch lange nicht sind. Darum muss man einige Dinge eventuell Dogmatisch sehen.
Sehe ich nicht so. Wenn ihr zu einem globalen Player werden wollt, dann wird es Sinn machen alles was Code/Doku angeht auf Englisch zu machen. Das kannst du genau so begründen, ganz ohne Dogmatismus. Also z.B. mit dem Hinweis dass es leichter ist hochqualifiziertes Personal zu bekommen wenn die potentiellen Bewerber nicht bzw. nicht gut Deutsch können müssen.
Eine Regel mit Erklärung/Begründung wird nach meiner Erfahrung besser angenommen, als wenn etwas einfach nur dogmatisch gefordert wird.
ps: Vielleicht versteht einer von uns beiden das Wort "dogmatisch falsch? Ich meine damit: etwas einfach zu fordern, nicht nur ohne Bereitschaft es zu "verhandeln" sondern auch ohne Erklärung. Und das ist mMn. selten die beste Lösung.
-
@hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:
Die Frage ist IMO: kann man es realistisch besser machen? Du hast nunmal einen Haufen Leute die nicht oder nur sehr schlecht Englisch können. Die müssen irgendwo arbeiten. Und die sind auch nicht alle doof.
Es gibt natürlich die recht brauchbare Möglichkeit, das der Entwickler die Dokumentation seiner Arbeit in seiner bevorzugten Sprache verfasst um diese durch einen "Translator" für die "Öffendlichkeit" ins englische übersetzen zu lassen. Übersetzungsfehler können dann durch eine Doku-Qualitätssicherung (die sollte es eigentlich bei größeren Projekte geben) behoben werden.
Nebenbei lernt der betreffende Entwickler dadurch mit der Zeit besser englisch.
-
@Quiche-Lorraine sagte in Clean Code / Software Principles - Wo seid ihr??:
Uff, und ich erlebe recht heftige Probleme mit Outsourcing aus Indien, China, USA und Thailand. Und es betrifft Software, Hardware, Verpackung und Packaging.
Ich wollte damit nur zum Ausdruck bringen, dass es in Deutschland mit weniger bis gar keinen Englischkenntnisse in der Vergangenheit deutlich besser war als das heute in Deutschland ist. Im Ausland ist es oftmals deutlich schlechter, weil es die Berufsausbildung wie es sie in Deutschland, Schweiz und Österreich gibt, nicht existiert.
@SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:
Damit du nicht für den gesamten Lebenszyklus der Software (von der Planung bis zum Endbetrieb) ausschließlich auf deutsche Arbeitskräfte angewiesen bist?
Was nützt mir ein Nichtdeutschprachiger Entwickler, wenn er eine Arztpraxensoftware warten soll, bei der 99% der Änderungen sich durch gesetzliche Auflagen ergeben? Jemand ohne Deutschkenntnisse wird niemals in der Lage sein, diese Software zu warten, da er die Anforderungen nicht lesen und verstehen kann.
-
@john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:
Was nützt mir ein Nichtdeutschprachiger Entwickler, wenn er eine Arztpraxensoftware warten soll, bei der 99% der Änderungen sich durch gesetzliche Auflagen ergeben? Jemand ohne Deutschkenntnisse wird niemals in der Lage sein, diese Software zu warten, da er die Anforderungen nicht lesen und verstehen kann.
Sehr guter Einwand!
In nicht englischsprachigen Ländern müssen Entwickler also mindesten zweisprachig sein. Also Landessprache für landesspezifische Anforderungen und Englisch für die Entwicklung und Doku.
-
@hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:
Naja, so ganz unstrittig ist das nicht. Zum einen muss man auch irgendwann mal fertig werden, und sauber programmieren dauert halt länger als eine Q&D Lösung. Und dann ist da noch die Frage wie "sauber programmiert" überhaupt aussieht. Beides nach meiner Erfahrung sehr kontroverse Themen.
Ja, bei der Entwicklung dauert es evtl. laeger - jedoch wird die Wartbarkeit und damit die Zeit beim Finden von evtl. Bugs oder auch bei Erweiterungen deutlich reduziert.
Ist ja wie bei (Unit-) Tests. Sie kosten bei der Entwicklung Zeit, sparen sie aber dann, wenn man eigentlich keine Zeit mehr hat - im Feld, wenn die Software schon beim Kunden ist.
Und eigentlich ist "sauber programmieren" ueberhaupt nicht kontrovers. Dazu gibt es echte Richtlinien - SOLID - und die entsprechenden Prinzipien.
-
Ach, ich hasse meine zynische Art... Nichts als Dogma annehmen. Also vor allem das mit dem "GOTO nie und nimmer benutzen". SOLID sind Konventionen, an denen man sich orientieren kann, aber warum soll man mal nicht von der Konvention abweichen? DRY, geht nicht immer gut, zum Beispiel. Und man muss nicht Design Patterns um jeden Preis und überall implementieren. Wie wäre es mit einer Prise Pragmatik?
Es gibt auch noch weitere Ansätze, die man eher in wenigen Industrien findet: DOD.
Wobei was heißt Pragmatik, meistens sind die Leute nicht an Qualität interessiert und bezahlen Dich schlecht und wollen das Du dies und jenes mit der höchsten Qualität implementierst, aber bei der Bezahlung geizt man natürlich.
Dann werden wichtige Tests ausgelassen und Fehlerbehandlung halbherzig oder gar nicht implementiert. Wird ja nicht bezahlt, wa?Wie konnte aus mir nur ein Volkard werden? Ein Rätsel...
-
@tbird sagte in Clean Code / Software Principles - Wo seid ihr??:
@hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:
Naja, so ganz unstrittig ist das nicht. Zum einen muss man auch irgendwann mal fertig werden, und sauber programmieren dauert halt länger als eine Q&D Lösung. Und dann ist da noch die Frage wie "sauber programmiert" überhaupt aussieht. Beides nach meiner Erfahrung sehr kontroverse Themen.
Ja, bei der Entwicklung dauert es evtl. laeger - jedoch wird die Wartbarkeit und damit die Zeit beim Finden von evtl. Bugs oder auch bei Erweiterungen deutlich reduziert.
Das ist schon klar. Aber die Praxis zeigt dass man nicht alles bis zur letzten Zeile, dem letzten Implementierungsdetail sauber programmieren kann wenn man konkurrenzfähig sein will. Schon gar nicht wenn man ein Startup ist. Die Streitfrage ist dann: wo zieht man die Grenze?
Ist ja wie bei (Unit-) Tests. Sie kosten bei der Entwicklung Zeit, sparen sie aber dann, wenn man eigentlich keine Zeit mehr hat - im Feld, wenn die Software schon beim Kunden ist.
Richtig. Aber auch hier wieder: wie viele Tests, wiel viel Coverage? 90% 95% 98%? Line-Coverage oder Branch-Coverage?
Ein weiteres beliebtes Streitthema ist: wie sollen Tests aussehen? Da gibt es z.B. das Lager das auf strikten Unit-Test besteht. Also Tests die ausser der "unit under test", Standard-Library Funktionen und speziellen Test-Mocks keinen anderen Code aufrufen. Was mMn. völliger Quatsch ist, weil es erfahrungsgemäss unnötig viel Aufwand ist und dabei Tests rauskommen die sehr gerne brechen, obwohl man gar keinen "breaking change" gemacht hat.
Und eigentlich ist "sauber programmieren" ueberhaupt nicht kontrovers. Dazu gibt es echte Richtlinien - SOLID - und die entsprechenden Prinzipien.
Doch, ist es
U.a. weil die ganzen Richtlinien sich z.T. widersprechen und auch für sich genommen nicht immer sinnvoll sind. KISS ist z.B. oft im Konflikt mit diversen SOLID Regeln. DRY ist in bestimmten Situationen nicht sinnvoll wie @CarnageStorm auch schon geschrieben hat. MISRA-C++ verbietet effektiv ADL in Templates zu verwenden (siehe Rule 14–6–2 http://www.tlemp.com/download/rule/MISRA-CPP-2008-STANDARD.pdf). Halte ich so generell auch nicht für sinnvoll.
Und wie ich schon geschrieben habe: es gibt verschiedenste Richtlinien-Sammlungen. Wer soll nun entscheiden welche eingehalten werden müssen und welche nicht?
-
Man muss - und das habe ich eingesehen, den korrekten Weg für die Firma finden (und dieser ist manchmal auch nicht der stringenteste).
Wir machen viel Projekt - Arbeit. Da ist evtl. schon eine Test-Abdeckung der Grundfunktionen ausreichend (Gerade wenn es um Kunden-Spezifische Anpassungen geht). 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).
Dass sich Regeln teilweise widersprechen, liegt doch auch an den Einsatzgebieten dieser Regeln, oder? Gerade der MISRA Standard beschreibt doch "C++ in Critical Systems". Was ist jedoch ein "Critical System"? Ja - das Ganze ist komplexer wie ich es am Anfang gesehen habe.
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.
-
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.
-
@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)
-
@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.
-
@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.
-
@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.
-
@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.
