Danke fürs Feedback, muss dir in allen von dir erwähnten Punkten recht geben!
„Wer SW nach Diagrammen entwickelt, hat IME schon verloren.“
Wer ohne Design entwickelt verliert jeden Tag. Sehe ich an den sogenannten On-Fly-Entwicklern. In der Regel kommt nur Schrott bei raus. Sehe ich als QS Entwickler auch jeden Tag.
Früher, also man es sich noch leisten konnte, hierzulande qualitativ hochwertige SW zu schreiben war das Standard. (Bei mir z.B. im Praktikum in den Jahren 2007 / 2008)
Heutzutage kann man sich das scheinbar nicht mehr leisten - ein Trugschluss - und deswegen holt einem das Weglassen davon, früher oder später, oft wieder ein. Und am Ende wird
a.) Alles noch viel teurer
ODER
b.) Man lässt es bei der minderwertigen Software beliben. Minderwertig muss dabei nicht buggy oder mit Sicherheitslücken versehen heissen - nur ein komplettes Chaos, welches es de facto praktisch unmöglich machen wird die SW in Zukunft zu erweitern.
1 „Gefällt mir“
Schade dass du kein Entwickler bist, sonst koenntest du das ja besser machen, oder zumindest bunte Bilder zu einen nicht fertigen Projekt liefern.
Prioritaet ist funktionierende Software.
UML ist nett, aber eben zur Kommunikation.
Priorität heißt aber nicht 0 oder 1, sondern vielleicht auch mal 0.38 vs. 0.41. Du weißt auch, dass „funktioniert“ alleine nicht reicht. Ich hatte schon gelegentlich versucht, das als ein „Spektrum“ zu artikulieren:
- Software Engineering
- Software-Entwicklung
- Programmierung
- Code hinschreiben, der irgendwas macht
Auch letzteres „funktioniert“. Und ich habe schon zu oft zu viel Zeit damit verplempert, much durch irgendwelche Drecks-Müllprojekte zu wühlen, bei denen die einzige Frage, die der Chef immer gestellt hat, genau diese war: „Funktioniert’s?“. Irgendwann habe ich ihm mal klipp und klar gesagt, dass ich diese Frage nicht mehr beantworten werde (schön, wenn man nichts mehr zu verlieren hat - ich habe ihm im Zuge dessen auch auch mal einen Blick auf Des Kaisers neue Kleider – Wikipedia nahe gelegt…).
Ich bin nun kein UML-Fan. Kann irgendjemand irgendeine Information beschreiben, die in einem UML-Diragramm steckt, die man NICHT viel präziser, hilfreicher und „lebensnäher“ (!) mit ein paar Zeilen (compilierbarem!) code vermitteln kann, in dem nur interfaces vorkommen?
Das ist Quatsch. Wer es nicht kann, wird es auch mit einem UML Diagramm nicht können. Wer es kann, braucht kein UML Diagramm. IMO.
Wie gesagt, sind Diagramme nur unterstützende Kommunikationswerkzeuge, ein Nice-to-Have, ein Accessoire, ein schöner Schmuck. Sprich: ein Kann, kein Soll oder Muss…
Das Kommentar zeugt von Gedankenlosigkeit. Wie man lesen kann bin ich QS-Entwickler. Davon vielleicht schon mal gehört. Das gehört zu den Quality-Gates die unter anderem wie es üblich ist, Code anderer Entwickler reviewen.
Funktionierende Software entsteht am besten, wenn man Zeit und Hirn in das Design steckt. Ansonsten entsteht Software die zwar vielleicht funktioniert, aber bei jeder Anpassung zu einem Wackelkandidaten wird. 17 Jahre Entwicklungserfahrung haben bis jetzt nichts anderes gezeigt.
Die Realität zeigt hier schlicht anderes. Es ist auch nicht zwingend von UML die Rede. Auch wenn es das standardisierte Verfahren ist.
Es hat sich schlicht gezeigt, wer keine Zeit in Design steckt, erzeugt Code der oft dem Refactoring unterliegt oder gar komplett neu gemacht werden muss. Das hat mit Können nichts zu tun. Können bedeutet nicht Codezeilen schreiben zu können. Unittest und Regressionstest zeigen oft die Wahrheit in Kombination mit der Bugfixing-Quote.
Sich hier anzumelden fuer einen einzigen negativen Kommentar in dem du schlecht ueber deine Kollegen redest in einem alten Thread zeugt entweder von trolling, oder du bist wirklich so bitter. Warum sollte man sich „Schrott“ so lange an tun?
Deinen 17 Jahre „QS-Entwickler“ (Wie wird man das eigentlich? Hat es nicht zum richtigen Entwickler gereicht?) setzte ich meine 21 Jahren SW Entwickler Erfahrung in mehreren Laendern und Kontinenten entgegen, soviel mal schnell zum Penis vergleich.
Hier bei den Inhalten zu bleiben, fände ich gut.
Ich sehe es auch so (auch aus praktischer Erfahrung - wie lange die ist, sage ich jetzt nicht 
) dass (heutzutage?) viel zu wenig Wert auf „Design“ gelegt wird. Die Hämdsärmeligkeit, mit der „entwickelt“ wird, finde ich irritierend, auf allen Ebenen (ich könnte da viele Beispiele nennen, aber … es sind zu viele, deswegen wüßte ich nicht, wo ich anfangen sollte)
UML ist IMO einfach schrecklich ineffizient. Natürlich ist das ein Artefakt des Versuches, Dinge zu standardisieren - von Wikipedia:
- Class diagram
- Component diagram
- Composite structure diagram
- Deployment diagram
- Object diagram
- Package diagram
- Profile diagram
- Activity diagram
- Communication diagram
- Interaction overview diagram
- Sequence diagram
- State diagram
- Timing diagram
- Use case diagram
Jaaa, klar 
Das eine oder andere - z.B. Class- oder Activity-Diagram) kann geeignet sein, um in einem „Spezifikationsdokument“ ein Ergebnis „sprachunabhängig“ festzuhalten. Aber damit aktiv zu arbeiten ist sicher nicht sinnvoll.
jo, aber für ein gutes Design brauche ich doch nicht zwingend ein UML-Klassendiagramm…
Was hat es mit bitter zu tun, eine in der Praxis als erwiesener Maßen schlechte Vorgehensweise zu kritisieren ? – Schrott sehe ich immer wieder, auch von Leuten die schon 20 Jahre und länger „programmieren“. – QS Entwickler wird man, wenn man die entsprechende Qualifikation hat anderen Code zu reviewen bevor er in Produkte einfließt. Auch international. – Es geht darum nicht nur zu coden sondern möglichst gut zu coden und zu designen. Lernen kann jeder.
Es ist m.E. nicht einfach, die Aspekte aus den unterschiedlichen Betrachtungswinkeln leicht darzustellen. Es geht hier eigentlich mehr um ein gemeinsames Verständnis bevor Stunden, Tage, Wochen Arbeit für den Mülleimer produziert wird. Ein Architekt plant ja auch das Haus, bevor jemand anfängt die Bodenplatte zu betonieren. Es ist eher unverständlich, warum es manchen im Softwarebereich so schwer ist für manche. In UML kann ich mich mit einem x-beliebigen Entwickler über das Design unterhalten, egal, worin es letztlich gecodet wird.
Gute Alternativvorschläge sind gern gelesen. Meine Erfahrung in Teamarbeit ist, das man immer zu Visualisierungen greift um ein gemeinsames Verständnis zu schaffen und komplexere Zusammenhänge zu erklären.
Deine Kollegen so zu bewerten klingt sehr bitter IMO
Nun, ich haette keine Lust mit dir zu arbeiten, kann natuerlich sein dass du recht hast und bei dir in der Firma viele Pfuscher rumlaufen, aber dann haette ich auch keine Lust dort zu arbeiten.
Soweit ich das sehe, gibt es sehr wenige Entwickler die freiwillig in die QS gehen, wenn sie stattdessen Entwickler sein koennten. Viele grosse Firmen haben gar keine QS/QA „Entwickler“ mehr, das wird einfach von Entwicklern uebernommen, speziell bei MicroServices. Auch vermeidet man dadurch „Kollegen“ die nicht wirklich Dinge besser machen sondern nur motzen und verhindern das Code in Produktion kommt.
Dann wundere ich mich warum du auf der Seite der Entwicklung sitzt, in der nicht entwickelt wird…
Oder codest du selber etwa, zeigst Entwickler wie „guter Code“ auszusehen hat?
Malst du dann Klassendiagramme?
Also ich habe die Erfahrung gemacht, dass man im Team am Besten mit konstruktiver Offenheit redet. Kritik kann jeden Treffen und sollte man abkönnen. Befindlichkeiten sind am Arbeitsplatz eher kontraproduktiv. – Zum Glück sind diese Entwickler nicht in meiner Firma. Ein Mischung aus Freelancern und Dienstleistern anderer Firmen. – Und ja wenn Dir nicht gefällt, das ich gute Arbeit erwarte, wäre es wohl mit der Zusammenarbeit schwer. – Tja du hast das falsche Bild eines QS-Entwicklers. Ich arbeite aktiv im Team mit und zu definierten Quality-Gates gehört ein Vier-Augenprinzip. Das gilt also auch für mein Coding. Nach deiner Ansicht gäbe es keine Materialprüfer, keinen TÜV oder sonstiges, weil du zu meinen scheinst, die eigenen Fehler fallen jedem immer selbst auf. Clean-Code Developing und Pfadfinderprinzip sollten keine Fremdwörter sein. Keine Ahnung von welchen Firmen du sprichst, aber ich kenne keine Firma die in Produktion egal ob Software, Lebensmittel oder sonst was ohne QA arbeitet. Das wäre grob fahrlässig. Und Motzen musst du dir nunmal gefallen lassen, wenn Du Mist herstellst. Das gilt für mich ja genauso.
Also du nennst deine Kollegen „On the Fly Entwickler bei denen nur Schrott bei raus kommt“? Das sagst du ihnen so direkt ins Gesicht und nennst das „konstruktive Offenheit“?
All das weil sie kein Klassendiagramm gemalt haben?
Entwickler wuessten dass Refactoring normal ist.
Du aber nicht 
Die Ebene, auf der diese Unterhaltung gerade stattfindet, ist so hoch und so abstrakt, dass die Frage, ob man bei dem, was jemand sagt, zustimmt oder widerspricht, weniger von dem abhängt, was gesagt wird, als eher davon, was man selbst unter dem gesagten versteht - und da fließen dann viele Eindrücke und subjektive Präferenzen mit rein.
Ein Architekt plant ja auch das Haus, bevor jemand anfängt die Bodenplatte zu betonieren.
Der Architekt plant etwas, und dann kommt der Bauingenieur und schüttelt den Kopf, der Dachdecker sagt, wo man passende Ziegel beschaffen kann, und wenn es um ein Großprojekt wie einen Konzertsaal oder einen Flughafen geht, trifft sich zwischendrin immer noch mal ein Konsortium und streitet stundenlang trefflich über die Farbe des Fahrradschuppens.
Solche Analogien können hilfreich und unterhaltsam sein. Eine Analogie, die ich in diesem Zusammenhang schonmal gebracht hatte, ist der Vergleich zwischen jemandem, der Informatik studiert hat und seine tägliche Arbeit betrachtet, und einem KfZ-Mechaniker: Wenn letzterer von seinem Chef die Aufgabe bekäme, ein Lenkrad mit Leder zu beziehen, würde er schon sagen: „Äh, das ist eigentlich nicht meine Aufgabe“. Die Arbeit von Informatikern wäre übertragen auf diesen Fall aber so, dass der Chef sagen würde: „Hier ist ein Messer, da drüben steht eine Kuh, sieh’ zu dass das heute Abend erledigt ist“ 
Etwas konkreter bzgl. UML:
interface Customer {
String getFirstName();
String getLastName();
int getId();
List<Order> getOrders();
}
interface Order {
int getId();
Product getProduct();
Price getPrice();
Customer getOwner();
}
interface Product {
String getName();
}
Das habe ich in ~60 Sekunden hingeschrieben. Wie lange bräuchtest du, um ein UML-Diagramm dafür zu erstellen? Länger. Punkt. Nun ändere ich was:
interface Customer {
String getFirstName();
String getLastName();
int getId();
List<Order> getOrders();
}
interface Order {
int getId();
Procuct getProduct();
}
interface Product {
Price getPrice();
String getName();
Customer getBuyer();
}
(ja, muss nicht sinnvoll sein, der Punkt ist) : Das habe ich in ~20 Sekunden geändert. Wie lange hättest du gebraucht, um das UML-Diagram upzudaten? Und mit welcher Software wird das erstellt? Und ist das Dateiformat dafür proprietär? Und wie viele Lizenzen braucht man für die Software? Und was kosten die? Und welche Farbe haben die Boxen in dem UML-Diagramm?
Ich finde, die Planung ~„eines Softwaremoduls“ sollte genau auf dieser Ebene anfangen. Man kann da leicht Code dagegen schreiben:
Customer customer = null; // Fetch from DB
List<Order> orders = customer.getOrders();
Price total = null;
for (Order order : orders) {
total.add(order.getPrice());
}
Das kann compilierbarer code sein. Das können „Snippets“ für Tutorials werden. Oder Unit-Tests. Man sieht, ob das, was man damit machen will, „funkioniert“, und sich „richtig anfühlt“. Und wenn man feststellt, dass der Customer eine Methode getTotalOrderPrice() haben sollte, die das oben skizzierte macht, dann fügt man die Zeile in die interfaces ein. Das dauert 3 Sekunden. Ohne UML-Diagramm.
Zum Thema „Motzen“ oder „konstruktive Offenheit“ kann ich nicht viel sagen. Also, Motzen kann ich gut. Und das mache ich auch. Es steht jedem frei, zu versuchen, möglichst wenige Dinge zu machen, über die man motzen kann. Das wäre ja mal was…
Also, die Ecken der Boxen dürfen nicht rund/ gerundet sein. So viel steht fest. 
(Und, dass die UML-Werkzeuge alle was kosten, proprietär sind und obendrein keine „offene“ Lizenz besitzen.)
Außerdem, kein Mensch würde zu Heerscharen von Klassen ein UML-Diagramm erstellen. Der Nutzen würde den Nachteilen nicht überwiegen.
Dann bewegst du dich im falschen Umfeld. Dafür können wir selbstverständlich nichts, der Ball liegt bei dir. Du hast dich hier angemeldet, um deinen Frust loszuwerden, nicht umgekehrt.
Und ich hab mir jetzt nicht alles dazu durchgelesen, aber ist ein QS-Engineer nicht so etwas wie ein „gehobener Tester“? Also eine Person, deren Arbeit es ist, die Arbeit anderer zu kritisieren? Dann ist es kein Wunder, dass dich nicht jeder mag.
Stimmt, ich vergesse manchmal, dass Programmieren heutzutage bedeutet, dem Schwächsten der Schwächsten (also studierten Informatikern) zu helfen, anstatt ein Programm zu schreiben.
Du lässt außer Acht, das man UML nicht die Sprache kennen muss in der programmiert wird.
Ich wüsste nicht warum du in UML länger brauchen solltest bei deinem 60 Sekunden-Beispiel. Du tippst ja genau das Gleiche. Und mit passendem Tool, auch als Freeware, wird es ggfs. auch gleich in Code übersetzt.
Wenn du den Kostenaspekt reinbringst, garantiere ich das jede Minute in Designüberlegungen einen enorm hohen ROI hat. Bestimmte vom Entwickler gemachte Architekturfehler kannst du nicht so einfach ausmerzen. Und wenn Du Software beim Kunden hast, kannst du ihm nicht mal eben sagen : mach mal alles neu von der Grünen Wiese. Du müsstest also in deine Kostennutzenbetrachtung Bugfixing und Wartungsaufwände durch schlechtes Design hinzurechnen. Keine Lizenz ist wohl so teuer.