Zum Inhalt springen

Empfohlene Beiträge

In meinem letzten Unternehmen und im Probearbeiten ist mir aufgefallen, das die Vorgesetzten ohne richtige Struktur, schnell Ergebnisse wollten. Vielleicht liegt es daran das es mittelständische Unternehmen sind, aber ich habe keine Fakten um diese Aussage zu belegen.

Man hat also einfach so drauf losprogrammiert um schnell fertig zu werden, was wie man weiß, vielmals in die Hose geht.

Ist es i.O. sich hier einfach zu Beginn einen Tag Zeit für ein UML Klassendiagramm zu nehmen und sich Gedanken über die Architektur zu machen? Ich habe irgendwie das Gefühl, dass das beim AG nicht so gut ankommt.

Beim Probearbeiten hatte ich einen Wireframe als Vorlage und sollte eine UWP Anwendung mit diversen Funktionen Entwickeln. (8 Stunden Zeitbudget) Am Ende des Tages hatte ich 2 XAML Pages und eine Liste mit Echtdaten aus der Unternehmensdatenbank. Bei der Vorführung meines Ergebnisses hat man mir gesagt, dass sie dachten, das ich mehr schaffen würde.

Was wäre also wenn ich hier nur ein UML Klassendiagramm und ein UML für die Systemarchitektur vorgelegt hätte? 😅

Bearbeitet von InTheVoid

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Meiner Meinung nach: Kommt auf die Komplexität an. Viele haben halt schon für "Typische-Module" ein Schema X aufgebaut (mit abstrakten Klassen und Interfaces die Definieren wie ein Modul aufgebaut sein muss).

Auch bei mir sehen die meisten Module erstmal auf den ersten Blick sehr gleich aus vom "Aufbau". Sämtliche Komplexität kann dann noch hinzugefügt werden.

Architektur ist dann wichtig, wenn ein Programm komplett bei Null beginnt und man sich verschiedene Fragen stellen muss... z.B. welches Design Pattern könnte man anwenden (https://www.dotnettricks.com/learn/designpatterns).

Wenn das Grundgerüst erst mal da ist, dann kann man in der Tat recht schnell erste Dinge umsetzen.

Kommt natürlich auch darauf an, was es für ne Anwendung ist und welche Maße diese hat. Manche sind natürlich hier knallhart und machen erst ein UML, dann einen Test-Case, dann eine Doku und dann irgendwann nach X anderen Sachen wird mal programmiert. Das ist ja alles toll und sicher, aber in der Zeit würde ich vermutlich 2 Module schaffen. Für große Unternehmen die zusammen an Sache X arbeiten macht es natürlich Sinn.

UML usw. verwende ich nur bei sehr langen komplexen Algos oder langen Prozessketten ... da man hier oft Fehleranfälligkeiten auf den ersten Blick entdeckt oder gleich feststellt, dass man Dinge auf anderer Art evtl. schneller lösen kann etc.

Mach dir nicht so viele Gedanken ... du hattest mit UWP noch nicht viel zu schaffen ... der "wir dachten Sie schaffen mehr" ist ein typischer Spruch damit du mehr Gas gibts.

Bearbeitet von KeeperOfCoffee

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Das Problem beginnt viel früher.

Neuentwicklung oder Erweiterung?

Sind Tools vorhanden?

Sind dies UML-Malprogramme oder integrierte Tools mit Codegenerierung? Bidirektional?

Will die Unternehmensleitung schnell Gewinn oder plant man langfristig inklusive Wartung der Software?

Sind die Kollegen mit den Dokumentionsmöglichkeiten vertraut oder handelt es sich um schlecht angelernte Quereinsteiger?

...

 

 

Oder wollte man im Bewerbungsprozess nur sehen, wie du mit Stress umgehst?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Das Thema Software Engineering ist eines der üblichen, wenn es um Theorie vs. Praxis geht.

In der Theorie finden alle Design Patterns, ordentliche Planung/Vorgehensmodelle, Clean Code, die gang of 4, Unit Tests/Test Driven Development, usw. ganz toll und schwärmen davon. Sobald es dann an die reale Entwicklung geht und der Kunde/Projektleiter/Chef auf seine Anwendung wartet, wird all das gerne über den Haufen geworfen und es muss "schnell, schnell" und "viel, viel" Output generiert werden. Schließlich müssen Deadlines sowie Kosten gehalten werden, Bugs können gefixed werden, Code Quality kann immer noch später kommen (also nie) und die nächste Spaghetti-Software ist geboren.

Das habe ich bisher fast ausschließlich so erlebt, egal ob in der 5-Mann-Bude, dem 500 Mann KMU oder 5.000 Mann-Konzern. Der Grund ist auch ganz einfach: Quality Assurance und Code Quality kosten enorme Summen Geld und bringen vordergründig wenig Mehrwert. Das möchte kaum ein Kunde/Chef bezahlen, so dass es hinten rüber fällt. Und selbst die meisten Teamleiter klemmen sich kaum dahinter.

Von daher ist dies eine meiner wichtigsten Lektionen, welche ich lernen musste und gerne allen weiter gebe: Die berufliche Softwareentwicklung hat häufig wenig mit dem gemein, was man in der Ausbildung, Fachliteratur, hier im Forum oder auch im Studium vermittelt bekommt. Und am Ende entwickelt kaum ein Unternehmen nach den sinnvollen und schönen Prinzipien, worüber wir Techniker uns den lieben langen Tag streiten. 😎

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Nein, ich glaube es ist nicht das Thema Dev Qualitäten zu zeigen in einem frühen Stadium einer Entwicklung, sondern es geht um etwas "Anfassbares" also eher die Visualisierung eines Konzeptes.

Nehmen wir das Beispiel eines Architekten. Er muss über ein fundiertes Wissen verfügen über Bauvorschriften und auch technischen Background. Das alles aber interessiert einen Kunden nur im zweiten Schritte. Im ersten Schritt möchte er sehen, wie sein künftiges Haus aussieht, im zweiten Schritt muss er dann erklären, warum etwas so und nicht anders geplant werden muss (z.B. Statik oder Vorschriften).

Es ist wohl die Gratwanderung, die auch ein Entwickler hinbekommen muss. Auf der einen Seite ein guter Architekt (mit dem Wissen im Hinterkopf) und auf der anderen Seite ein guter Verkäufer. Ob der Käufer jetzt Kunde oder interne Fachabteilung ist, ist dabei erst mal egal.

Meine Erfahrung ist die, dass eine gute Vision und Visualisierung, Türen öffnen kann. Der Mensch ist nun mal so verdrahtet, dass er etwas anfassen möchte, auch wenn das bei virtuellen Produkten zunächst einmal schwierig scheint.

Aber genau aus dem Grund gibt es ja auch etwas wie Prototypen oder Mockups. Hier steht erst einmal eine Idee- oder Vision im Vordergrund. Der Ausbau kann dann im zweiten Schritt noch erfolgen.

Ob der Architekturansatz "Design First" als Pattern eine gute Möglichkeit ist (sich als Entwickler zu verkaufen), darüber kann man sicher streiten. Wenn es darum aber geht, Leuten, die nicht vom Fach sind, etwas greifbarer- und damit "begreifbarer" zu machen, könnte es helfen.

Praktisches Beispiel. Also wenn ich einem Kunden eine App zur Verwaltung seines Videobestandes verkaufen wollte, würde ich vermutlich mit einer Visualisierung eines digitalen DVD Bücherregals mehr Begeisterung hervorbringen, als mit einer Skizze des dahinter stehenden Datenbankdesigns. Und wenn dann eben noch nicht alle Funktionen implementiert sind, kann man an der Stelle immer noch sagen - "Okay der Rahmen der Vision steht erkennbar da" - auch wenn es an vielen Stellen erst einmal eine Hülle ist.

Bearbeitet von tkreutz2

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Desweiteren stellt sich die Frage, ob es überhaupt deine Aufgabe sein sollte ein UML usw. zu entwerfen. Wenn du bzw. dein Team  von deinem Vorgesetzten eine Aufgabe bekommst, dann sollten schon sämtliche Anforderungen definiert sein.

Bei mir gab es früher bei neuen Projekten, Modulen usw. Teambesprechungen in welchen man die neuen Projekte meist schon durch UMLs visualisiert hat.

Gerade die Vorgesetzten bzw. Abteilungen, die mit den Kunden in Kontakt stehen haben, evtl. bereits UMLs grob ausgearbeitet, um den Kunden visuell darzustellen, wie sein Projekt aufgebaut ist.

Bearbeitet von KeeperOfCoffee

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Deine Meinung

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich an , um mit Deinem Konto zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.


Fachinformatiker.de, 2020 SE Internet Services

fidelogo_small.png

if_icon-6-mail-envelope-closed_314900.pnSchicken Sie uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App


Get it on Google Play

Kontakt

Hier werben?
Oder senden Sie eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung