Laden...

Arbeitsweise beim beruflichen Programmieren: akademisch vs. simple aber tut was es soll

Erstellt von M@TUK vor 8 Jahren Letzter Beitrag vor 8 Jahren 3.293 Views
M
M@TUK Themenstarter:in
402 Beiträge seit 2005
vor 8 Jahren
Arbeitsweise beim beruflichen Programmieren: akademisch vs. simple aber tut was es soll

Hi...

bei uns ist grade eine "gut/schlecht" Diskussion im Gange bezüglich der Arbeitsweise der Entwickler.

Es gibt bei uns Entwickler die ihre Entwicklungen vom Aufbau und der Komplexität her relativ simple halten aber qualitativen, wartbaren und lesbaren Code liefern und die Entwicklungen tun genau das was sie sollen. Aufgaben werden daher relativ schnell erledigt und sie haben eine gute Produktivität.

Bei einem neuen Mitarbeiter ist es nun aber so, dass jedes noch so kleine Feature zu einer Masterarbeit mutiert. Es gibt im Web teilweise so "Spielchen" wo es darum geht z.B. "Hello World" auf die höhst aufwändigste Weise zu programmieren. Genauso arbeitet er im beruflichen Umfeld. Da entsteht statt einer einfachen Klasse gleich mal ein eigenes Assembly mit duzenden Klassen und dem Einsatz von jedem erdenklichen Entwurfsmuster. Die Produktivität im Vergleich zu den anderen Mitarbeitern ist daher kaum vergleichbar weil Aufgaben teilweise ein vielfaches der normalen Zeit benötigen.

Nur wird natürlich deswegen vor allem auch in der "Führung" diskutiert. Manche halten diese Arbeitsweise für gar nicht so schlecht andere wiederum sehen dies aber als verschwendete Zeit.

Wie läuft das bei euch so? Legt ihr oder eure Firma Wert auf eine einfache, schnelle aber dennoch qualitative Arbeitsweise oder wird der "akademische" Weg mit (teilweise gar nicht notwendigen) hochkomplexen Architekturen bevorzugt?

lg

C
2.121 Beiträge seit 2010
vor 8 Jahren

Warum sollte eine Firma die annähernd Wert auf Produktivität legt statt nur Leute beschäftigen zu wollen damit sie keine Dummheiten machen, an viel zu aufwändigen Lösungen interessiert sein? Was findet die Führung gut daran wenn ein gleiches Ergebnis - nämlich das was es tun soll - mit viel mehr Zeit und praktisch keiner Wartbarkeit erreicht wird?
(ohne Berücksichtigung der Tatsache dass manche Führungsperson sich lieber von Geschwafel statt von Inhalten begeistern lässt)

5.657 Beiträge seit 2006
vor 8 Jahren

Hi M@TUK,

ich halte das ja für eine sehr merkwürdige Frage. Hast du diese Frage schonmal einem Architekten oder einem Autohersteller gestellt...?

Letztendlich sollen wir ja die Arbeitsweise deines Kollegen beurteilen, den wir nicht kennen, und von dem du uns nur eine sehr negative Einschätzung wissen läßt.

Andererseits schreibst du auch:

Manche halten diese Arbeitsweise für gar nicht so schlecht

Da wär's schon ganz interessant zu wissen, was sie daran "nicht so schlecht" finden.

Wie sollte man auch einschätzen können, ob eine bestimmte Herangehensweise angemessen ist, wenn man nichts über die zu erledigenden Aufgaben oder die Anforderungen an die Software weiß. Oder was auch immer du unter "jedes noch so kleine Feature zu einer Masterarbeit mutiert" verstehst. Solche Statements verhindern doch eigentlich nur, daß man hier auf sachlicher Ebene über das Für und Wider von Abstraktion und über Software-Architektur diskutieren kann.

Christian

Weeks of programming can save you hours of planning

C
1.214 Beiträge seit 2006
vor 8 Jahren

Das ist nicht so einfach zu beantworten. Vieles davon ist Interpretationssache. Wie MrSparkle geschrieben hat, kennen wir weder den Code noch die Anforderungen noch die möglichen Anforderungen.
Mit Design Patterns usw. sollte man es wohl nicht übertreiben. Es gibt wohl tatsächlich (kenne ich persönlich nicht, arbeite aber im C++ Umfeld) diese Entwickler, die bei jeder Aufgabe möglichst viele Design Patterns einsetzen wollen, weil die eben meinen, Design Pattern wären gut und die muss man überall reinzwingen. Sowas sollte man eher vermeiden.
Ansonsten kann man aber viele Aufgaben entweder möglichst pragmatisch und direkt (und dabei von mir aus auch produktiv und gut lesbar) umsetzen, oder eben mit ein paar Abstraktionsebenen mehr, die evtl. nicht nötig wären. Da gibt es auch die Fraktion, die gleich rumbrüllt, OMG, alles mit OOP und abstrakt, ich versteh gar nichts mehr. Aber welche Lösung auf lange Sicht die bessere ist, kann man von vornherein oft nicht sagen. Wir arbeiten seit 20 Jahren an einer sehr umfangreichen Software und ich kann aus Erfahrung sagen, dass da an sehr vielen Stellen einfach Abstraktionsebenen fehlen. Da denke ich mir oft, ok, das ist jetzt klar und einfach umgesetzt, aber wiederverwenden kann ichs nicht, jetzt muss ich alles umbauen. Und oft genug kann man was nicht mal ohne weiteres umbauen, weils zu viele Abhängigkeiten hat. Ich würde sowas also nicht pauschal beurteilen, ohne das System und die Umstände näher zu kennen.
Kontrolle in irgendeiner Form gibts bei uns eigentlich nicht. Es gibt ab und zu Code Reviews und die meisten wissen auch, was die anderen so in etwa machen und wie, aber es gibt keinen übergeordneten Architekten (es gibt aber Senior Developer, die Entscheidungen treffen, was wie grundsätzlich gemacht wird) und der Chef schaut sich den Code auch nicht an. Die meisten Lösungen sind mittlerweile ziemlich pragmatisch. Es wird mit den Design Patterns usw. nicht übertrieben, es wird aber auch darauf geachtet, keine ungewollten Abhängigkeiten einzubauen und den wiederverwendbar zu halten. Passiert aber schon ab und zu, dass man bei irgendwelchen kleineren Projekten Overengineering betreibt, wenns einem grad Spass macht und man ausprobieren will.

M
M@TUK Themenstarter:in
402 Beiträge seit 2005
vor 8 Jahren

Hi MrSparkle,

ich wollte keine Beurteilung meines Kollegen. Ich nur mal kurz dargestellt wie die Situation bei uns ist.

Die Frage war welche Arbeitsweise generell in anderen Firmen bevorzugt wird.

lg

5.657 Beiträge seit 2006
vor 8 Jahren

Ich nur mal kurz dargestellt wie die Situation bei uns ist.

Nein, du hast deinen Kollegen als einen Pedanten beurteilt, der ohne Not "jedes erdenkliche Entwurfsmuster" "auf höchst aufwändige Weise" implementiert, und dadurch mehr Zeit benötigt als andere.

Die Frage war welche Arbeitsweise generell in anderen Firmen bevorzugt wird.

Fähige Software-Entwickler entwerfen eine _geeignete _Software-Architektur, die sich möglichst einfach testen und weiterentwickeln läßt, und verwenden Entwurfsmuster, wo es erforderlich ist. Mit wesentlich mehr als solchen Allgemeinplätzen kann man aber auf eine so allgemein gehaltene Frage nicht antworten. Eine generelle "Arbeitsweise" gibt es sowieso nicht. Das unterscheidet sich von Firma zu Firma und von Entwickler zu Entwickler. Aber letztendlich gibt es bestimmte Anforderungen an eine Software-Architektur und für den Einsatz der einzelnen Entwurfsmuster. Also welche Antwort erwartest du dir da? Kannst du das evtl. ein bißchen konkreter formulieren?

Christian

Weeks of programming can save you hours of planning

16.807 Beiträge seit 2008
vor 8 Jahren

Ich muss da MrSparkle schon zustimmen; es wirkt wie ein wenig an den Pranger stellen.
Stell Dir vor der Kollege liest das und erkennt sich wieder.

Kollegen, die nicht immer die "optimalen" Wege wie Interfaces gehen - klar die gibts immer.
Ich "reg" mich auch gern auf wenn ich hör "wieso denn testen?" "wieso den dokumentieren, das sieht man doch" oder "wieso soll ich Interfaces nutzen? Was bringt mir das?".
Aber dann muss man das den Kollegen halt beibringen. Die meisten machen das doch gar nicht aus Absicht, sondern weil sie es halt so machen / gewohnt sind - und man ihnen evtl. einfach mal wieder die Augen öffnen muss.

Ich gehör ehrlicherweise auch zu denen, die sich bei sowas "aufregen" können und da manchmal selbst aufbrausender bin als ich es eigentlich meine (was zu meiner Art gehört); aber man muss sich einfach die Kämpfe aussuchen - und gerade Software-Prinzipien gehören zu den Themen, die man Kollegen näher bringen kann, wenn man es ihnen einfach erklärt und anhand von eigenen Implementierungen zeigt und die bessere Art und Weise schmackhaft macht.
Aber ja, der Thread hier bzw. die Art und Weise ist nicht so lecker.

Ich kenne keine Firma, die schmutzige und oft damit unwartbare Ergebnisse bevorzugt.
Sowas entsteht, wenn keiner die Übersicht hat und die "Macht" sauberen Code durchzusetzen.

M
M@TUK Themenstarter:in
402 Beiträge seit 2005
vor 8 Jahren

Hi...

vielleicht hab ich die Situation am Anfang etwas zu drastisch beschrieben und zu viele persönliche Emotionen reingebracht.

Dass es eine passende Architektur benötigt und eine gewisse Komplexität sicher notwendig ist, ist mir klar und das wird auch so gemacht.

Dass man sich wie Coder007 schreibt in einem kleinen Projekt oder Prototypen wenn Zeit ist mal "austobt" ist auch kein Thema.

Aber ich finde eben dass "so einfach wie möglich und/aber auch (nur) so komplex wie notwendig" zu entwickeln besser ist als permanent so komplex wie möglich zu arbeiten.

lg

A
350 Beiträge seit 2010
vor 8 Jahren

Hier gilt die Antwort: It depends

Es kommt drauf an, klar gibt es Aufgaben wo ich pragmatisch rangehe, aber auch viele wo Pragmatismus einfach nicht angebracht ist. Es hängt von der Anforderung und der Wartbarkeit etc. ab. NUR Pragmatisch zu entwickeln empfinde ich genauso falsch wie immer nur komplex zu entwickeln. Der gesunde Mittelweg sollte immer richtig sein, welcher aber oft schwer zu finden ist. Nach deinen Formulierungen gehe ich aber auch von einer gewissen BEtriebsblindheit aus und ich denke Ihr/Du werdet nicht objektiv über die Arbeitsweise von dem Kollegen urteilen können.

Mein Tipp an euch: Redet mit ihm und lasst euch erklären warum sein Weg evtl. der bessere ist oder auch nicht. Ihr müsst als Team zusammenkommen und da muss jeder Kompromisse eingehen bzw. noch einiges vom anderen lernen.

Viel Erfolg !

K
71 Beiträge seit 2005
vor 8 Jahren

Hi...

Aber ich finde eben dass "so einfach wie möglich und/aber auch (nur) so komplex wie notwendig" zu entwickeln besser ist als permanent so komplex wie möglich zu arbeiten.

lg

Auf jeden Fall. Einfachheit sehen wir mittlerweile als einer der wichtigsten Faktoren im Projekt.

Gerade bei grösseren Projekten, welche 10-15 Jahre im Produktiv-Betrieb sind ist das wichtig.
Die gleichen Entwickler welche zu komplexe Lösungen aufbauen schreien als erstes "das muss man neu Schreiben" (nach 3 Jahren).

Gewisse Grundlagen gehören natürlich dazu (DI/Interfaces/SoC/usw.). Aber einiges kann man getrost weglassen.
Wir lassen mittlerweile auch Elemente weg welche wohl "normalerweise zu einer sauberen Architektur" gehören. Natürlich nur je nach Projekt.

T
2.219 Beiträge seit 2008
vor 8 Jahren

Ich bevorzuge sowohl bei meinen Code als auch bei fremden Projekten immer eine einfache und funktionale Lösung.
Auch wenn dies heißt mit gewissen Grundsätzen zu brechnen.

Ich verzichte für einfache und effiziente Lösungen auch gerne mal auf das einhalten gewisser Grundsätze.
Dies können gerne mal saubere relationen in der DB sein oder im Code die Einhaltung von gewissen "Standards".

Ich halte einfache Umsetzungen immer für besser als hoch komplexe Lösungen.
Auch wenn lezteres korrekt umgesetz ist, so ist der spätere Folgeaufwand meistens größer als durch eine einfachere Lösung.

Insgesamt ist es aber auch wieder Situationsabhängig.
So kann es auch mir passieren, dass durch die Umsetzung teils komplexe Strukturen aus einfachen Lösungen werden.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

5.657 Beiträge seit 2006
vor 8 Jahren

Hi M@TUK,

das einzige, was man mit ziemlicher Sicherheit sagen kann, ist, daß bei euch in der Firma eine Stimmung herrscht, die dazu führt, daß man bei Meinungsverschiedenheiten erstmal in einem Internetforum über einen Kollegen redet, anstatt im Büro mit dem Kollegen. Auf Dauer wirkt sich das allerdings viel nachteiliger aus als eine Uneinigkeit über die "richtige" Arbeitsweise.

Christian

Weeks of programming can save you hours of planning

M
M@TUK Themenstarter:in
402 Beiträge seit 2005
vor 8 Jahren

Hi MrSparkle...

das ist so nicht richtig, es wurde und wird im Team darüber diskutiert.

Das Forum nutze ich um andere Meinungen dazu (zur Vorgehensweise nicht den Kollegen) zu bekommen.

lg

1.696 Beiträge seit 2006
vor 8 Jahren

Normalerweise hat ein Team bestimmte Konventionen einzuhalten, welche durch den Abteilungs-/Projektleiter festgelegt wurde, also wenn der Vorgesetzte sein Teammitglied nicht dazu bewegen kann, nach Vorschrift zu arbeiten, dann ist er einfach unfähig.

Das Problem, was ich hier sehe ist mehr die Fürungsqualität des Teamleiters als die Art wie der Entwickler sein Job macht. Wenn keiner ihn hinter die Schränken verweisen kann/will und stattdessen immer den Netten spielen und nur drüber diskutieren, ist die Stimmung im A***, da sich jede über ein bestimmtes Mitglied aufregt; die Produktivität leidet drunter und irgendwann hat die Firma keine Lust mehr, dann wird jemand oder mehrere dran glauben müssen.

Ich bin verantwortlich für das, was ich sage, nicht für das, was du verstehst.

**:::

742 Beiträge seit 2005
vor 8 Jahren

@vbprogger: Das ist aber sehr pauschal. Es gibt ja unterschiedliche Führungsstrategien. Im Kontext von sich selbstorganisierenden Teams könnte das Team selbst seine Guidelines festlegen.

Zum Thema: So weit ich mich erinnere gibt es einige Studien zum Thema Wartbarkeit. Das einzige wiederholbare Ergebnis ist, dass bei mehreren Implementierungen der gleichen Anforderungen das Projekt mit den wenigsten zeilen Quellcode die höchste Wartbarkeit hat, falls grundlegende Qualitätsrichtlinien eingehalten werden (nicht alles in eine Datei). Das ist ja auch nachvollziehbar und meiner Meinung nach sollte das die oberste Prämisse sein: Verringer die LOC.

Vielleicht sogar in der Reihenfolge:

  • Verringere die LOC
  • Verwende gute Namen
  • Dont repeat yourself (DRY)
  • Single Responsibility Principle (SRP)
  • Teste dein Code automatisch

Und dann führt das normalerweise auch zu den richtigen Pattern. Vielleicht solltet ihr euch über solche Regeln einige werden. Clean Code Developer ist da ein guter Anhaltspunkt.

2.207 Beiträge seit 2011
vor 8 Jahren

Bei selbstorganisierenden Teams sollte sowas wie die Wartbarkeit durch eine Definition of Done (Das ist jetzt sehr durch die Scrum-Brille, bitte keine Scrum-Diskussion. Kann ja auch was anderes sein) geregelt werden. Wenn solche Sachen durch das Team geregelt und vor allem regelmässig hinterfragt, überprüft und angepasst werden, steht das Team dahinter und jeder ist (mehr oder weniger) damit einverstanden. Dann sollten solche Probleme eigentlich kaum auftreten. Der Abteilungsleiter sollte gar nicht mitmischen, sofern das Ergebnis für ihn i.O. ist.

"Harte" Verstösse kann man durch FxCop, ArchiCop etc. ja schon abfangen. Vier-Augen-Prinzip kann auch nicht schaden bei sowas.

Gruss

Coffeebean

I
45 Beiträge seit 2012
vor 8 Jahren

Was mir aufgefallen ist, gleich im Startbeitrag: Wieso schreibst Du "Führung" in Anführungsstrichen ?
Führt sie oder nicht ? Wenn sie führt hat sie auch die Pflicht und Kompetenz (hoffentlich) Euren "Kulturkampf" zu schlichten.
Und wir aus der Ferne können zu dem was Besser ist, gar nichts sagen.

C
2.121 Beiträge seit 2010
vor 8 Jahren

und Kompetenz (hoffentlich)

Je höher die Führung angesiedelt ist, umso weniger Kompetenz in diesen Dingen. Dann gewinnt der mit den lautesten Argumenten, nicht der mit den sinnvollsten.

F
10.010 Beiträge seit 2004
vor 8 Jahren

Das ist etwas das SW Entwickler meist nicht verstehen.
Die meisten Chefs sind Kaufleute, denen muss man also mit kaufmännischen Argumenten kommen.
Wenn man denen was von KISS und YAGNI erzählt verstehen die es nicht, wenn man denen aber vorrechnet das die SW durch Überarchitektur 3 mal so lange braucht, und der Wartungsaufwand dadurch verdoppelt wird, dann fangen die an aufzuhorchen.

A
764 Beiträge seit 2007
vor 8 Jahren

das die SW durch Überarchitektur 3 mal so lange braucht, und der Wartungsaufwand dadurch verdoppelt wird

Ich habe es bisher nur anders herum erlebt. Das heißt: quasi keine Architektur -> hoher Wartungsaufwand. Ich kenne es auch nur so, dass die BWLer möglichst schnelle eine billige Lösung haben wollen und das Architektur nicht interessiert.

C
2.121 Beiträge seit 2010
vor 8 Jahren

Es gibt beides. Genauso schlimm wie keine Architektur ist es wenn jemand mit vermeinlichem Wissen glaubt, man müsse nur genügend Zeichnungen und Beispielmasken usw. erstellen und alles wäre schon so gut wie fertig.