Welche Sprache nach C lernen?

@KitKat::new(): ich finde Rust schon cool, es sieht für mich vielversprechend aus, hat hohe Performance - was ich gelegentlich brauche. Aber!

Unter Windows ist es mir nicht gelungen, irgendwas mit OpenCV zu machen, die crate funktioniert irgendwie nicht (kann nicht geladen werden). Ich mache viele Sachen in OpenCV (C++ und Python). Bei Qt siehts ähnlich aus, ich kann die crate zwar bauen, aber funktionieren tut sie nicht, weil sie gerne unter Windows ein altes Qt (max. 5.14) sehen will und ich habe keine Lust, mehrere Qt-Versionen, die ich sonst nicht brauche (5.15.2 ist die aktuelle 5'er) auf der Platte zu verteilen. (siehe auch: https://github.com/rust-qt/ritual/issues/104). Aber ich probiere trotzdem immer wieder mal neu, vor allem OpenCV würde mich sehr interessieren. Siehe: https://github.com/twistedfall/opencv-rust - wahrscheinlich müßte ich sowohl unter Rust als auch unter OpenCV auf mingw-toolchain gehen (im Gegensatz zum "schönen" msvc-toolchain) - aber das ist mir dann doch zu anstrengend.

Und nochwas. Bei Python habe ich seinerzeit schon geflucht wegen "immutable" (strings etc.) - aber das habe ich inzwischen "eingesehen". Aber bei Rust, und das macht die Sprache ja im Wesentlichen aus, kommt noch "ownership" dazu. Das ist dann doch etwas zu viel Overkill für den technisch-wissenschaftlichen Gelegenheitsprogrammierer, für den "Sicherheitsprobleme" kaum relevant sind. Wenn man keinen idiomatischen Rust-code schreiben möchte, kann man einiges mit "unsafe" umgehen, schon klar. Was ich meine ist sowas hier - man nehme einen String, ändere ein paar Buchstaben und gebe ihn aus.

Perl:
Perl:
my $txt = 'Hello Perl';
$txt =~ y/[A-Za-z]/_/  and print $txt
Python:
Python:
txt = 'Hello Python' # immutable, but ok
txt = re.sub('[A-Za-z]', '_', txt)
print(txt)
Rust (mein laienhafter Versuch):
Rust:
 let txt: String = "Hello Rust".to_string(); // immutable/owned
 let reg   = Regex::new(r"[A-Za-z]").unwrap();
 let res: String = reg.replace_all(txt.as_ref(), "_").to_string();
 println!("{}", res);
/edit: C++
C++:
 string txt = "Hello Cplusplus";
 txt = regex_replace(txt, regex("[A-Za-z]"), "_");
 cout << txt << endl;
Also Du siehst, was ich meine. Das ist schon ganz clever, wenn man es braucht. Aber nicht für jeden Code muss man Ownership beachten sollen (IMHO) ...
 
Zuletzt bearbeitet:
Zhdun schrieb:
Rust

Bei deiner GO (leider schon etwas her bei mir)-Kritik kann ich nur "keine generische Programmierung" (generics) nachvollziehen.
z.B. finde ich, dass JetBrains guten IDE Support hat(te), statt Klassen ja structs (mit assoziierten Methoden) verfügbar sind, Vererbung nur selten benötigt wird, durch Codegeneration (was z.B. auch als Ersatz für generics und andere Sachen benutzt wird) auch Mocks aus vorhandenem Code erzeugt werden könnten.
Versionen von Fremdbibliotheken konnte ich früher bei go-dep festlegen. Wurde anscheinend ersetzt, aber dort soll es auch möglich sein: https://stackoverflow.com/questions...-a-specific-version-of-a-package-using-go-get
Bei den Schnittstellen frage ich mich was unklar ist und bei der Reflection: warum?

Zhdun schrieb:
aber sehr mächtig ist das jetzt nicht.
Eine zentrale Idee von Go war auch die Sprache so einfach wie möglich zu halten und deshalb z.B. auf Vererbung verzichtet. Daher ist das auch so die mit die einfachst zu erlernende Sprache, die ich kenne.

blöderidiot schrieb:
Und nochwas. Bei Python habe ich seinerzeit schon geflucht wegen "immutable" (strings etc.) - aber das habe ich inzwischen "eingesehen". Aber bei Rust, und das macht die Sprache ja im Wesentlichen aus, kommt noch "ownership" dazu.
Ownership hat man bei anderen Sprachen auch, nur ist es bei GC-Sprachen (wie Python) i.d.R. geteilte Ownership.
Bei C gibts das Konzept gar nicht und es ist alles dem Benutzer überlassen und die STL von C++ bietet ähnliches wie Rust.

Der Unterschied zwischen Rust und C++ und GC-Sprachen ist nur, dass es Teil der Syntax ist, wodurch der Compiler einerseits Performance rausholen kann als auch Zugriffschecks machen kann:
Bei C++ kannst du ohne Probleme auf eine vernichtete Variable zugreifen und bei GC-Sprachen soweit das Multithreading beherrscht (glaub schiweriges Thema bei Python) race conditions einführen, ohne dass man es mitbekommt.

Das ist dann doch etwas zu viel Overkill für den technisch-wissenschaftlichen Gelegenheitsprogrammierer, für den "Sicherheitsprobleme" kaum relevant sind.
Verständlich, wenn Performance unwichtig ist oder nicht ernsthaft Software entwickelt wird, wobei ich denke, dass das im Regelfall ein Automatismus wird.

blöderidiot schrieb:
Also Du siehst, was ich meine. Das ist schon ganz clever, wenn man es braucht. Aber nicht für jeden Code muss man Ownership beachten sollen (IMHO) ...
Ich sehe nur, dass du bei Rust dazu gedrängt wirst dich um einen möglichen Fehler bei der Erstellung des regulären Ausdrucks zu kümmern (kein Zusammenhang mit Ownership).
Beim Code frage ich mich, warum du dir es absichtlich schwer machst:
C-ähnlich:
    let txt = "Hello Rust"; // immutable/owned
    let reg = Regex::new(r"[A-Za-z]").unwrap();
    let res = reg.replace_all(txt, "_");
    println!("{}", res);
 
KitKat::new() schrieb:
Verständlich, wenn Performance unwichtig ist oder nicht ernsthaft Software entwickelt wird, wobei ich denke, dass das im Regelfall ein Automatismus wird.
Durchaus möglich. Dazu bedarf es aber der Motivation, sich eine Weile damit zu befassen.
Ich sehe nur, dass du bei Rust dazu gedrängt wirst dich um einen möglichen Fehler bei der Erstellung des regulären Ausdrucks zu kümmern (kein Zusammenhang mit Ownership).
Beim Code frage ich mich, warum du dir es absichtlich schwer machst:
C-ähnlich:
    let txt = "Hello Rust"; // immutable/owned
    let reg = Regex::new(r"[A-Za-z]").unwrap();
    let res = reg.replace_all(txt, "_");
    println!("{}", res);
Na ja, als Rust-Anfänger ist es schwer, von vorneherein abzuschätzen, was "Rust-idiomatisch" und elegant ist und was nicht. Das bekommt man erst im Laufe der Zeit mit. Aber nach Deiner Anregung werde ich mich schon zunächst mal mit den string-Typen beschäftigen, um diese und deren Konzepte möglichst sicher zu verstehen (z.B.: https://chrismorgan.info/blog/rust-fizzbuzz/)

Danke für die Anregungen -- obwohl es gar nicht mein Thread ist ...
 
KitKat::new() schrieb:
Bei deiner GO (leider schon etwas her bei mir)-Kritik kann ich nur "keine generische Programmierung" (generics) nachvollziehen.
z.B. finde ich, dass JetBrains guten IDE Support hat(te), statt Klassen ja structs (mit assoziierten Methoden) verfügbar sind, Vererbung nur selten benötigt wird, durch Codegeneration (was z.B. auch als Ersatz für generics und andere Sachen benutzt wird) auch Mocks aus vorhandenem Code erzeugt werden könnten.
Versionen von Fremdbibliotheken konnte ich früher bei go-dep festlegen. Wurde anscheinend ersetzt, aber dort soll es auch möglich sein: https://stackoverflow.com/questions...-a-specific-version-of-a-package-using-go-get
Bei den Schnittstellen frage ich mich was unklar ist und bei der Reflection: warum?

In Go gibt es eine lose Kopplung mit den Schnittstellen. Eine Komponente erfüllt die Schnittstelle implizit wenn sie Alle Methoden einer Schnittstelle implementiert. So kann man Schnittstellen für Komponenten schreiben die man gar nicht selbst gebaut hat und die Deklaration und Implementierung gar nicht selbst beeinflussen kann. Lose Schnittstellenkopplung kann sowohl ein Nachteil wie ein Vorteil sein, aber ich selbst finde das eher hinderlich, stehe eher auf klare Trennung und Verhältnisse. Das kann schnell unübersichtlich werden.

Reflection scheint mir im Vergleich zu Java oder C# irgendwie stark eingeschränkt und umständlich. Aber mag auch Geschmackssache sein, ich war da nicht so tief eingestiegen.

Ich habe grundsätzlich nichts gegen Go, ein minimalistischer Ansatz mag in bestimmten Bereichen auch sinnvoll sein, vermutlich ist die Sprache leichter zugänglich als die klassischen Ansätze, was ein Vorteil sein kann. Ist nur wenn man sich bereits an die Mächtigkeit von Java oder C# gewöhnt hat, kommt man sich irgendwie eingeschränkt vor und wenn man komplexe Problemlösungen umsetzen möchte, geht es bestimmt auch aber halt umständlich mit irgendwelchen Workarounds.
 
Zhdun schrieb:
In der Berufspraxis lerne ich jede Woche ein Anderes Framework kennen
Dementsprechend sieht vermutlich dann auch die Qualität Deiner Software aus. :-)

Zhdun schrieb:
Man kann das unmöglich alles lernen und auch noch dran bleiben.
Deswegen sprach ich ja davon das nicht ausufern zu lassen, sondern mich halt auf bestimmte Sachen zu beschränken. Weil es sonst einfach nicht leistbar ist.

Zhdun schrieb:
Heutzutage sind die am weitesten verbreiteten vor Allem C# und Java. Das sind so die größten Platzhirsche. Damit beschäftigt sich ein Softwareentwickler heutzutage zu 80-90% bei der Entwicklungsarbeit. Von Scriptsprachen vor Allem javascript, nicht nur in der Webentwicklung. Auch kommen relativ oft zum Einsatz groovy, ruby, python.
Mag ja alles sein. Aber selbst von Java zu Javascript hast Du viele konzeptionelle Unterschiede.
Und mag sein, das meine Beispiele extrem waren. Es ging darum zu verdeutlichen, das es bei Programmiersprachen sich eben nicht auf "Kennste Eine kennste Alle" reduzieren lässt, auch wenn es zweifelsohne große Überschneidungen gibt.

Welche Programmiersprache Du antriffst hängt im wesentlichen davon ab, in welcher Domaine Du Dich bewegst. In dem vom Threadersteller angesprochenen Embedded-Bereich hast Du keine 80-90% Java und C#

Zudem mögen meine Beispiele zwar Exoten sein, aber Vieles von dem was dort von unseren Altvorderen erarbeitet wurde, findest Du in den heute gängigen Programmiersprachen wieder.

Zhdun schrieb:
Vor Allem die Methodik und automatisierte Tests machen die Qualität. Wie gesagt in der Praxis habe ich fast jeden Tag mit einer neuen Technologie zutun. Die Qualität muss trotzdem stimmen, da kommt man nicht drum herum testgetrieben und mit der Dokumentation zu arbeiten, dann stimmt auch die Qualität.
Ich sag mal so:
Das Eine kommt ohne das andere nicht aus. Du wirst auch kein Picasso wenn Du die besten Pinsel und besten Farben einsetzt, die Du kriegen kannst. Zu allem gehört Übung und lernen.
Letzteres hat aber (wie bereits gesagt) seine Grenzen. Mehr als 24 Stunden hat nämlich ein Tag nicht. Abgesehen davon, das Du da noch Essen, Trinken, schlafen musst sind auch andere Dinge die Dir Grenzen setzen. Mehr als 8h wirst Du mit dem Kram nicht verbringen können weil die Konzentrationsfähigkeit danach rapide nachlässt. Klar kann man auch mal überperformen. Aber nicht auf Dauer.

Zhdun schrieb:
In der Praxis kommst du gar nicht drum herum verschiedenste Sprachen und Technologien gleichzeitig einzusetzen, du hast auch oft gar nicht die freie Auswahl.
Das ist sicher richtig. Ich sag ja auch nicht, das man das überhaupt nicht machen soll. Ich sprach davon, das man das nicht ausufern lassen soll.

Zhdun schrieb:
Ja streng genommen schon, dennoch ist objektorientierte Programmierung mit C durchaus möglich
Klar. Im Prinzip kannst Du auch in Assembler objektorientiert programmieren. Was schon allein dadurch bewiesen ist, das es Compiler gibt die Dein objektorientiertes C++ (oder was auch immer) in Assembler übersetzen.
Das war aber auch gar nicht die Aussage. Die Aussage war, das Objektorientierung in der Sprache unterstützt wird. Und das hast Du bei C nicht.

Zhdun schrieb:
C spielt in der Praxis heutzutage praktisch gar keine Rolle mehr, außer vielleicht bei der Anbindung ganz uralter Software.
Wie beispielsweise beim Linux-Kernel. Der ist zwar voll bis unters Dach mit C-Code. Aber richtig. Linux führt nur ein Nischendasein und ist obendrein uralte Software die nur noch mit Rolator zur Arbeit zu bewegen ist. :-)

Zhdun schrieb:
Besser zuerst Java vor C#. Sie sind sich sehr ähnlich, aber Java ist für Anfänger leichter.
Also erst fährst Du so ein "Kennste Eine, kennste Alle"-Schiene und jetzt soll man auch noch zwei Sprachen lernen die sich auch noch total ähnlich sind. Interessant. :-)

Man muss beides lernen, wenn man beides braucht. Aber einfach nur so um mal reinzugucken das zu lernen lohnt daher meiner Ansicht nach kaum.
Das ist so, als wenn ich einen VW-Transporter fahre und um mal ein anderes Fahrgefühl bekomme einen Mercedes Transporter nehme und nicht etwa ein Sportwagen oder so. :-)

Zhdun schrieb:
Ich habe grundsätzlich nichts gegen Go, ein minimalistischer Ansatz mag in bestimmten Bereichen auch sinnvoll sein
Ja. Das ist auch genau das Ziel von Go. Go soll auch kein Ersatz für C# oder so sein. Es ist eher ein (gewisser) Ersatz für C. Auch C ist ja durch einen gewissen Minimalismus geprägt.

Zhdun schrieb:
Ist nur wenn man sich bereits an die Mächtigkeit von Java oder C# gewöhnt hat, kommt man sich irgendwie eingeschränkt vor und wenn man komplexe Problemlösungen umsetzen möchte
So gehts mir immer mit Java und C#. Wenn man sich einmal an das gewöhnt hat, was man von Lisp her kennt.
Vor allem Lisp ist relativ simpel und hat auch nicht so viele Features. Aber die, die es hat sind halt sehr gut kombinierbar. Man hat auch wenig Feature-Überschneidungen, so das sich aus den wenigen Sachen dann quasi alles mögliche bauen lässt.
Wenn man sich einmal darauf eingelassen hat, merkt man erst wie umständlich und kompliziert Sprachen wie Java und Co sind.

Deswegen macht es halt (zum lernen) Sinn sich auch mal "Exoten" anzuschauen. Wenn man sich immer nur in dem ewig gleichen Programmiersprachen.Einheitsbrei aufhält merkt man das nicht ganz so gut.
 
Ich glaube wir sind ganz kurz davor, die beste Programmiersprache zu finden, wir sind maximal 1189 Beiträge davon entfernt und falls das nicht klappt wissen wir zumindest, wer sich am besten mit Programmierung auskennt. Der TE ist bestimmt auch schon ganz aufgeregt.
 
  • Gefällt mir
Reaktionen: MindofRafi und andy_m4
andy_m4 schrieb:
Dementsprechend sieht vermutlich dann auch die Qualität Deiner Software aus. :-)

Na die Qualität der Software ist messbar, und in sie wird in seriösen Softwarehäusern auch getrackt. Meine ist ausgezeichnet, unabhängig von der Programmiersprache oder Technologie die ich anwenden muss.

Du hast im professionellem Bereich nicht den Luxus zu sagen, ich mach jetzt Alles mit Lisp weil ich da die meiste Erfahrung habe. Schon alleine deshalb weil du eher selten etwas komplett neues entwickelst, meistens sind das Systembausteine in bereits bestehenden, weitreichend vernetzten Systemen. Du hast meistens nicht einmal den Luxus dir aussuchen zu können mit welcher Datenbank oder mit welcher Version welches Frameworks du dich auseinander setzen musst.

Ein Guter Programmierer ist nicht der Spezialist in einer bestimmten Sprache, sondern derjenige der mit Jeder Technologie problemorientiert und effizient arbeiten kann.
 
  • Gefällt mir
Reaktionen: RalphS
KitKat::new() schrieb:
Wie hast du sie gemessen?

Also das ist ein ziemlich großes Thema, ich wüsste jetzt nicht wo ich da anfangen würde um auf diese Frage etwas konkretes zu sagen. Um es möglichst kurz zu machen, es gibt dafür spezielle Technologien und Tools, welche während des build prozesses die Qualität anhand vordefinierter Regeln größtenteils vollautomatisch testen und tracken. Wenn dich das Thema interessiert google: Software Quality metrics.
 
Zhdun schrieb:
Na die Qualität der Software ist messbar, und in sie wird in seriösen Softwarehäusern auch getrackt. Meine ist ausgezeichnet, unabhängig von der Programmiersprache oder Technologie die ich anwenden muss.
Bla bla.

Zhdun schrieb:
Ein Guter Programmierer ist nicht der Spezialist in einer bestimmten Sprache, sondern derjenige der mit Jeder Technologie problemorientiert und effizient arbeiten kann.
Ich befürchte ja, Deine Einschätzung kommt daher das Du in einem ziemlich begrenzten Bereich arbeitest. Und dann ist natürlich sich in "alles" einarbeiten nicht schwierig.

Übrigens. Das ist auch nicht schlimm. Ohne Spezialisierung wirds schwierig und das funktioniert ja auch in anderen Bereichen als Softwareentwicklung gut.
Man sollte halt bloß nicht versuchen von seiner Domain auf einen größeren Bereich zu extrapolieren.
 
Zhdun schrieb:
Wenn dich das Thema interessiert google: Software Quality metrics.
Also mein Wissen über das Thema besagt, dass es keine Metrik gibt, die wirklich die Qualität von Software messen kann.

Zhdun schrieb:
Also das ist ein ziemlich großes Thema, ich wüsste jetzt nicht wo ich da anfangen würde um auf diese Frage etwas konkretes zu sagen.
Einfach deine verwendeten Metriken aufzählen
 
andy_m4 schrieb:

Na wenn du meinst.

andy_m4 schrieb:
Ich befürchte ja, Deine Einschätzung kommt daher das Du in einem ziemlich begrenzten Bereich arbeitest. Und dann ist natürlich sich in "alles" einarbeiten nicht schwierig.

würd ich nicht sagen, dass bei Merck Life Science in ein einem so "ziemlich begrenzten Bereich" gearbeitet wird. Wir entwickeln unter Anderem KI gestützte Laborsysteme und Standards für Chemie- und Pharmaindustrie und sind eigentlich in diesem "begrenzten" Bereich weltweit führend. Zu unseren Kunden zählen unter Anderem Biontech, AstraZeneca, Sanofi... Wir arbeiten mit einer sehr breiten Palette von Technologien von Übermorgen. Bei uns als Entwickler aufgenommen zu werden ist nicht einfach. Wir haben sehr hohe Ansprüche und Bewerber aus Allen möglichen Ländern der Welt.

Aber jetzt muss ich wieder zurück zur Sache eine Dokumentation für unsere Massenspektrometrie Schnittstelle weiterschreiben.
 
KitKat::new() schrieb:
Also mein Wissen über das Thema besagt, dass es keine Metrik gibt, die wirklich die Qualität von Software messen kann.
Also man kann schon was machen. So ist das nicht. Und das wird auch gemacht. Allerdings erschlägst Du damit halt nur ein Teil.
Kann man sich auch logisch selbst erschließen.
Denn wenn es so einfach wäre das man einfach ein Tool über ein Quelltext laufen lassen würde, um zumindest ein Großteil der Qualitätsprobleme in den Griff zu kriegen, dann hätten wir viele Baustellen die wir heute haben eben nicht.
Microsoft macht viel in dem Bereich. Und trotzdem dürfen wir jeden Patchday aufs Neue bewundern wie viel Bugs und Security-Löcher da drin sind und oft schon seit Jahren dort geschlummert haben.
Von den Bugs die noch offen sind fang ich ich da gar nicht erst an. :-)

Zhdun schrieb:
Na wenn du meinst.
Weißt Du, ich bin jetzt schon seit den 80er Jahren dabei. Ich will nicht von mir behaupten das ich ein guter Programmierer bin. Aber ich hab halt schon ne Menge gesehen und bilde mir ein gewisse Bullshit-Aussagen zu erkennen.
Und da hast Du ja nicht nur Eine vom Stapel gelassen. Ich erinnere nur mal an Objektorientierung und C und das C überhaupt eine völlig unbedeutende Sprache ist.
Und das jeder halbwegs begabte Programmier jede Programmiersprache, jede Bibliothek und jedes Framework innerhalb von kürzester Zeit beherrscht(!). Das ist Bullshit und hab ich auch noch nie bei irgendwem beobachten können.

Möglicherweise ist das ja bei Dir tatsächlich anders und Du bist die große Ausnahme. Sozusagen der Thomas Edison unter den Programmierern.
Dein Halbwissen und Dein ganzes Gehabe deutet aber eher darauf hin was Du ein Schwätzer bist.
 
C++
und
wenn du es als sprache siehst sql ($$$)
(sybase fast track 2 sql)
oder
m$ mfc

mit einem dba und dbe und sql + Unix-root (HP.Oracle,sun,) kannst in Banken/Versicherung gute $ machen.

und wieder ein aber:
Das kann einen Programmierer/Coder auf Dauer nicht befriedigen.
Geldmachen ist eine Seite, Zufriedenheit im Job eine ganz andere.

auch:
für mich spielt immer die moralische Seite eine Rolle. Mensch muss nicht alles programmieren nur weil er es kann.
 
Zuletzt bearbeitet:
andy_m4 schrieb:
Weißt Du, ich bin jetzt schon seit den 80er Jahren dabei. Ich will nicht von mir behaupten das ich ein guter Programmierer bin. Aber ich hab halt schon ne Menge gesehen und bilde mir ein gewisse Bullshit-Aussagen zu erkennen.
Scheint nur Einbildung zu sein, denn die Bullshitaussagen die du mir unterstellst habe ich so gar nicht gemacht. Vielleicht hast du es so interpretiert, aber das ist nicht meine schuld. Musst einfach besser lesen.

Ich habe echt keine Lust mich hier mit dir zu streiten. Du kannst dich gern bei uns in Merck Life Science bewerben wenn du so erfahren bist, und dann lernen wir uns beim Bewerbungsgespräch persönlich kennen. Nur sag ich gleich einen Bewerber der meint ein Spezialist für eine bestimmte Sprache zu sein bekommt von mir gleich eine Absage, weil wir eher an Allroundern interessiert sind die nicht vor einer Vielfalt von Technologien zurückschrecken und nicht nur eine Sprache beherrschen.
 
Zuletzt bearbeitet:
KitKat::new() schrieb:
Also mein Wissen über das Thema besagt, dass es keine Metrik gibt, die wirklich die Qualität von Software messen kann.

Doch klar geht das. Dazu gibt es einen Industriestandard ISO/IEC 25010 auch bekannt als SQuaRE. In jedem größerem Softwarehaus ist das ein ganz wichtiges Thema. Bei uns bekommst Codeänderungen nicht einmal in die Repo gepusht wenn sie nicht den von QA Management vordefinierten Qualitätsmerkmalen entsprechen.

Das ist nicht einfach ein einfaches Tool, das ist eine ganze Reihe von Testverfahren in der Produktionspipeline. Das fängt an mit so banalen Dingen Coding Standards, automatisierten Unit Tests, Integrationstests, Performancetests, GUI Tests (zb. Selenium), wird von einem zweiten Entwickler reviewt und endet letztendlich beim QA Team welche auch manuell testen in wie weit die Anforderungen erfüllt werden oder auch nicht. Es werden auch solche Dinge wie die Vollständigkeit der Dokumentation, Test Coverage, Code Style, Usability, Fehlerquote, Aktualität der verwendeten Bibliotheken und alles Mögliche bewertet und anhand von vordefinierten Regeln verrechnet. Am Ende hat man eine Zahl in % welche dann das Vergleichskriterium für Qualität einer Software dienen kann. Das ganze wird auch über längeren Zeitraum getrackt, so dass man praktisch sehen kann wenn die Qualität einer Software während der Entwicklung zunimmt oder abnimmt. Darüber hinaus kann die Qualität der abgelieferten Arbeit individuell für jeden Entwickler abgeleitet werden und davon hängt dann ab ob man eine Gehaltserhöhung oder eine Prämie bekommt oder eben nicht.

Du hast zum Beispiel um einen weiteren Use Case zu implementieren eine Methode geändert, aber der bereits vorhandene Test dafür ist zwar Grün, berücksichtigt den neuen Use case aber noch nicht. Dies würde schon beim pushen in die Build Pipeline auffliegen und sich negativ auf die Gesamtqualität auswirken.
 
Zhdun schrieb:
Vollständigkeit der Dokumentation, Test Coverage, Code Style, Usability, Fehlerquote, Aktualität der verwendeten Bibliotheken und alles Mögliche bewertet und anhand von vordefinierten Regeln verrechnet.
Wie wird denn Usability bestimmt?
Fehlerquote?
Die anderen sagen nichts darüber aus ob der Code eine hohe Qualität hat...

Z.b. Test-Coverage: 100% Testcoverage kannst du auch mit miserablen Code/Tests haben

Aber immerhin verlässt man sich nicht 100% auf sowas:
wird von einem zweiten Entwickler reviewt und endet letztendlich beim QA Team welche auch manuell testen in wie weit die Anforderungen erfüllt werden oder auch nicht
 
KitKat::new() schrieb:
Wie wird denn Usability bestimmt?
Da werden eine Reihe von Regeln und Kriterien definiert. Zum Teil durch eigene Ansprüche zum Teil durch den Kunden. Das macht die QA Abteilung welche auch ständig die Usability Rules in Absprache mit dem Kunden weiterentwickelt. Das kann verschiedene Aspekte betreffen und sowohl sehr konkret wie auch abstrakt sein im Frontend wie im Backend. Eine Testreihe wird mit diesen Regeln gefüttert und klappert sie durch. Am Ende steht ein Ergebnis in % fest in wie weit sämtliche Regeln eingehalten wurden.
KitKat::new() schrieb:
Das ist eine rein statistische Größe. Die gemeldeten Bugs werden in einem Bugtracking System erfasst und je nach Schweregrad in Gruppen eingeteilt, welche verschiedene Gewichtungen haben. Das wird dann anhand von definierten Formeln verrechnet und ergibt am Ende einen Punktwert welcher Aussagen zulässt wie sehr ein ganzes Produkt oder auch einzelne Komponenten oder einzelne Features verbugt sind und dies beeinflusst letztendlich auch die Gesamtqualitätsbewertung.
KitKat::new() schrieb:
Die anderen sagen nichts darüber aus ob der Code eine hohe Qualität hat...
Nicht verwechseln, Code Qualität und Software Qualität ist nicht das Selbe.
Code Qualität betrifft rein formal nur den Code. Z.b. ob alle Parameter in Code Docs erfasst wurden. Ob es stets immer nur einen return statement pro Methode gibt. Ob ungenutzte Variablen oder Toter Code existiert. Ob ungenutzte imports existieren. Ob die Zeilen nicht zu lang sind und die Einrückung korrekt ist. Solche rein formale Dinge, da helfen einem schon die gängigen IDE tools und plugins wird aber auch bei Qualitätssicherung automatisch nochmal geprüft was auch Auswirkung auf Gesamtqualität hat.

In die Softwarequalität fließt aber Alles mögliche ein. Unter Anderem auch Code Qualität, aber auch z.b. Performance, Komplexitätsgrad, Usability, Fehlerquote solche Sachen. Das ist Alles standardisiert, es gibt also fest vorgegebene Industriestandards was da Alles dazu gehört und es gibt eine Reihe von Verfahren die einem Erlauben dies Alles zu messen, zu verrechnen und im Zweifel auch nachzuweisen.


KitKat::new() schrieb:
Z.b. Test-Coverage: 100% Testcoverage kannst du auch mit miserablen Code/Tests haben

Sicher, das ist ja auch nur eines von vielen Kriterien die in die Gesamtqualität einfließen. 100% Coverage wird sowieso grundsätzlich vorausgesetzt. Ist das nicht gegeben hat es Einfluss auf die Gesamtqualität. Unter einem bestimmten Schwellenwert wird es nicht einmal gebaut, die Produktionspipeline würde es verweigern.

Fortgeschrittene Coverage Tools testen jedoch nicht nur ob eine bestimmte Methode ein Test durchlaufen hat, es wird auch geprüft ob Alle möglichen Cases für eine Methode abgedeckt sind. Z.b. wenn du in einer Methode etwas hast was zu einer Exception führen kann, und du hast diesen Fall nicht durch ein Test abgedeckt, ist das keine 100% tige Coverage.

KitKat::new() schrieb:
Aber immerhin verlässt man sich nicht 100% auf sowas:
Manuelle Acceptance Tests wie auch Code Reviews durch einen zweiten Entwickler sind natürlich auch unvermeidlich. Alles lässt sich nicht automatisieren, aber schon sehr Vieles.
 
@offtopic

Du kannst dich gern bei uns in Merck Life Science bewerben wenn du so erfahren bist
Da hab ich spaßeshalber mal geschaut was die alles suchen. Und auch gleich ein Fehlerchen gefunden, trotz aller Qualitätssicherungsmaßnahmen :cool_alt:

merck.JPG


Ja, mir ist klar das die Website kein GMP einhalten muss...
 
Zurück
Oben