Aus reiner Neugier möchte ich eine nicht repräsentative Umfrage zur Softwarequalität in eurem Unternehmen machen. Vorweg sollte ich noch dazusagen, dass ich kein professioneller Entwickler bin, d.h. ich weiß natürlich nicht, was von dem hier Aufgelisteten wie stark zur Codequalität beiträgt. Die Umfrage ist bewusst subjektiv, d.h. ich möchte wissen, wie ihr selbst als Entwickler die Qualität eurer Software einschätzt.

Ich würde mich freuen, wenn ihr bei einer Aussage "Nein, X machen wir nicht" angeben könntet, warum ihr das nicht macht. Zudem wäre es interessant zu wissen, in welchem Kontext ihr entwickelt:

• Was für ein Produkt entwickelt ihr?
• Wer ist die Zielgruppe davon?
• Wieviele Mitarbeiter/Standorte habt ihr?
• arbeitet ihr international?
• welche Sprache, welche Frameworks verwendet ihr? (Damit meine ich sowohl technische, als auch organisatorische wie z.B. Scrum)
• Welches Versionskontrollsystem verwendet ihr?

Codereviews

• Macht ihr überhaupt Codereviews?
• Wie regelmäig?
• Wie umfangreich? (Welche Themenbereiche werden reviewt : Performance, Lesbarkeit, Skalierbarkeit, Sicherheit, etc. pp)
• Wie viel Erfahrung haben die Personen, die die Codereviews durchführen?
• Ist das (positive) Codereviews eine zwingende Voraussetzung, dass der Code akzeptiert wird? Oder ist das nur optional?

Statische Codenanalyse

• prüft ihr mit statischer Codeanalyse euren Code?
• Wie regelmässig?
• Wird die Umsetzung der Vorschläge erzwungen?

Testing

• Mit welchen Testarten testet ihr? (Unit tests, Regressionstests, etc.)
• wie häufig fuehrt ihr als Entwickler eure Unit tests aus?
• Wie hoch ist die Abdeckung der Unit Tests?
• Praktiziert ihr irgendwelche bestimmte Entwicklungsmethoden, z.B. Testdriven Development?

Code Conventions

• Habt ihr Code conventions festgelegt? (z.B. https://google.github.io/styleguide/javaguide.html,  https://www.python.org/dev/peps/pep-0008/ oder eigene)
• Wie wird die Einhaltung geprüft?

Build System

• wie stark ist euer Buildsystem automatisiert?
• Praktiziert ihr Continous integration?
• Ist euer Buildsystem 100% reproduzierbar?

Refaktoring

• wie häufig wird euer code refaktoriert?

Auditing

• prüft ihr euren Code speziell auf  Sicherheitslücken?

Programmiersprachen

• wie häufig upgraded ihr eure verwendete Sprachversion? (z.B. java 7 vs java 8)
• wie häufig refaktoriert ihr euren code in diesem zug? (z.B. in Java, java 8 lambdas anstatt anonymen funktionen verwenden, welche lesbarer sind)

Ticket system

• welches Ticket system benutzt ihr?
• wird gekennzeichnet, welcher Entwickler an welchem Ticket arbeitet?
• ist das Ticket system öffentlich zugänglich?
• Gibt es eine Möglichkeit, Fehler vertraulich zu melden? (z.B. Sicherheitslücken)

Weiterbildung

• inwiefern werdet ihr im Unternehmen weitergebildet?
• werdet ihr zu bestimmten Konferenzen eurer verwendeten Technologien geschickt? (DockerCon, JavaLand, PyCon, Chaos Communication Congress, etc.)

Deployment

• auf welchem Weg wird eure Software zu dem Kunden gebracht? Ist das automatisiert?
• wir eure fertige Version kryptografisch signiert?

Hardware Aussattung

• wie lange brauchen eure Unit Tests ungefähr zum durchlaufen?

 

Gibt es sonst noch etwas was euch in Bezug auf die Qualität der produzierten Software sehr wichtig erscheint?

Bearbeitet 15. Mai 20169 j von Legislaturperiode

du hast hier ja schon mehr als genug faktoren aufgezeigt, die da reinspielen und direkt klar machen sollten das man mit einer einzigen 1-5 Auswahl hier keine echte auch nur ansatzweise Verwertbare Antwort geben kann. Wenn du wirklich was darüber wissen willst solltest du in nem Online Umfragen Tool eine Große umfrage bauen und jeden der hier genannten Punkte als eigenen Punkt den man mit 1-5 Bewerten kann reinnehmen, dann kann man vielleicht drüber reden. So ist die Umfrage leider eher sinnbefreit.

Vor allem kommt dazu, dass wenn jeder seinen eigenen Maßstab für 10 als best mögliche z.B. ansetzt, dass da eh nix bei rum kommen kann.
Für mich wäre ein 10 vor 3 Jahren noch etwas ganz anderes gewesen, als eine 10 heute.
Alleine weil ich damals viele Techniken und Verfahren gar nicht kannte.

Ich denke ein Unternehmen, dass nicht fünf von fünf Sternen hat kann sich nur schwer am Markt halten.

Denn wenn die Softwarequalität nicht stimmt meldet sich der Kunde schnell mit recht harten Worten.

Moin!

Hier dazu ein alter(16 Jahre) aber immer noch brandaktueller Artikel aus Joel Spolskys(StackExchange, Trello, ehemals Microsoft) Blog:

The Joel Test: 12 Steps to Better Code

 

Zum konkreten Inhalt: Ich finde die Fragen, die du stellst, ziemlich gut. Allerdings daraus ein "1-5 Punkte"-System abzuleiten war eine nicht so gelungene Aktion.
Da bin ich bei meinen Vorrednern. Wir sind aber zwischen 4 und 5, mit starker Tendenz zur 5. Amüsanterweise sind unsere "Patterns & Practices" und unser Tooling im Bereich Softwareentwicklung bedeutend besser als im Bereich Data Warehousing und Data Science, obwohl unsere Kernkompetenz eigentlich die Datenverarbeitung ist.

Aber das ist ein Posten, an dem grade akut gearbeitet wird.

Gruß, Goulasz  

vor 16 Stunden schrieb Studin:

Ich denke ein Unternehmen, dass nicht fünf von fünf Sternen hat kann sich nur schwer am Markt halten.

Sollte man denken, ist aber nicht so. Kann ich aus eigener Erfahrung so sagen. In meinem Betrieb ist an sowas wie TDD nicht einmal zu denken. Sogar einfache Unit Tests sind die große Ausnahme. Das liegt zum Großteil an den älteren Entwicklern, die das "schon immer so gemacht" haben.

Trotzdem sind wir recht erfolgreich und das seit mittlerweile 30+ Jahren.

Viele der "neuen" Entwicklungen erleichtern einem das Leben als Entwickler ungemein und vereinfachen die Prozesse (gerade so etwas wie Releasemanagement, QA, ...) einer Softwareentwicklung. Das heißt aber nicht, dass man nicht auch ohne sie kann - schwerer, schmerzhafter, aber auch irgendwie.

Ich denke ehrlich gesagt sogar, dass die neuen Dinge wie Scrum, TDD, DevOps und Co. zwar fast überall irgendwo mal präsent sind oder waren, aber wirklich in die Praxis Einzug gehalten hat es doch eher in den wenigsten Firmen.

Bei kleineren Teams, Abteilungen und Firmen, welche sich rein auf IT / Entwicklung spezialisieren.
Da wird die Quote relativ hoch sein, vermute ich.

Aber sobald es mehr als nur reine IT ist.
Sobald die Teams / Abteilungen größer werden und sobald die Firma gewachsen ist, wird das alles ganz anders aussehen.
Zumindest ist es so, was ich bisher mitbekommen habe und was sich fast immer deckt.

Wenn Scrum, TDD, etc. so weit verbreitet wären, gäbe es ja auch fast keinen Bedarf mehr für Consultants bzw. Externe. 

vor 27 Minuten schrieb Errraddicator:

[...]Wenn Scrum, TDD, etc. so weit verbreitet wären, gäbe es ja auch fast keinen Bedarf mehr für Consultants bzw. Externe. 

Ich denke der Bedarf rührt auch daher, dass Anforderungen an Software mittlerweile einfach dynamischer und flexibler sind als das vor ein paar Jahren noch der Fall war. Grade im IT-Bereich geht der Fokus weg von riesigen Applikationen hin zu kleineren, schlanken, leicht zu bedienenden Tools("Apps"), die ganz spezifische Probleme lösen und nicht den Anspruch haben, die eierlegende Wollmilchsau zu sein. Dafür aber schnell verfügbar und einsatzfähig.

Zumindest ist das meiner Einschätzung nach außerhalb der ganz großen Konzern-Enterprise-Welt immer mehr so. Auch Menschen, die ich jetzt eher nicht als "Digital Natives" bezeichnen würde, kriegen über Ecken und Endprodukte für den Consumermarkt(iPhone etc.) mit, was an leichtgewichtigen Lösungen mittlerweile möglich ist. Wenn es aber stärker Richtung "Leicht bedienbare Software zur Lösung konkreter Probleme" geht und der Fokus weniger auf "SAP-Klon, der von Haus aus einfach ALLES kann aber garstig zu bedienen ist" liegt, kommt man mit den altgedienten tayloristischen Management-Methoden und Wasserfall-Planung nicht mehr so weit. Meine Beobachtung hier ist, dass sich diese Erkenntnis langsam aber sicher verbreitet, und vor allem dass agile Methoden keine hippen Buzzwords sind, mit denen man Mitarbeiter zieht, sondern, dass sie für manche Anforderungen spürbaren Mehrwert(time to market) bringen. Ein iteratives Vorgehen und ein Herantasten an die bestmögliche und effizienteste Lösung(über MVPs) werden wichtiger. Und das bringt implizit Anforderungen an Software und Architektur mit sich.

Wenn ich schnell Feedback brauche, kann ich es mir nicht leisten, jedes Feature komplett manuell durchzuklicken und durch die QA/Test-Abteilung zu jagen. Es kommt der Punkt, wo Entwickler gefühlt schneller Features entwickeln, als getestet werden kann. Also wird das automatisiert. Zack, hat man ne CI-Pipeline. Damit es mit dem Hosting klappt, hat man auf einmal nen Admin im Team. Und weil man ja auch irgendwie nahe beim Kunden sein will und das ganze auch irgendwie abrechnen möchte, landet man logischerweise in so einem Vorgehen oft bei einem crossfunktionalen Team, das die gesamte Wertschöpfungskette abbilden kann.

Gruß, Goulasz  

Bearbeitet 17. Mai 20169 j von Goulasz