Sollten Entwicklungsmethoden den Individualismus eines Entwicklers unterdrücken?

9

Ich bin in meinem letzten Semester am College und nehme an einem Software-Engineering-Kurs teil. In der Klasse lernen wir verschiedene Methoden der Softwareentwicklung kennen. Diejenige, auf die wir uns konzentrierten und die wir zur Entwicklung unseres Projekts verwendeten, war die Wasserfallmethode.

Ich habe das Gefühl, dass der Ausbilder es möglicherweise falsch implementiert hat. In unseren Klassendiagrammen mussten wir ALLE Eigenschaften und Methoden auflisten, einschließlich privater. Ich habe einige Bücher gelesen, nämlich Clean Code, die besagen, dass Funktionen so kurz und konzentriert wie möglich gehalten werden sollen. Es scheint mühsam, jede kleine Funktion in unseren Diagrammen aufzulisten, wenn sie anderen Entwicklern nicht hilft (sie sind privat, niemand anderes wird sie verwenden). Außerdem denke ich beim Entwerfen des Programms möglicherweise nicht an jede winzige Funktion, sondern möglicherweise beim Refactoring.

Hat uns der Ausbilder etwas Falsches gesagt, indem er uns gebeten hat, alle Funktionen aufzulisten? Und unterdrücken diese Entwurfsmethoden den Individualismus des Entwicklers, um Code so zu schreiben, wie er ihn am besten verstehen kann?

David Peterman
quelle
20
Das ist ziemlich schlimm, dass Ihre Klasse die Wasserfallmethode unterrichtet, ein kanonisches Beispiel für schlechte Prozesse bei der Softwareentwicklung.
Whatsisname
6
Ich würde sagen, diese Klasse hat dir viel beigebracht.
JeffO
7
Tatsächlich hat der ursprüngliche Wasserfall Iterationen, die sich gegenseitig beeinflussen. Es ist die falsche Lehre des Wasserfalls im Laufe der Jahre, die seine Nützlichkeit zerstört hat. Selbst mit etwas wie Scrum emulieren die Schritte, die eine Story in einem Sprint durchläuft, die eines Wasserfalls in sich. UML-Diagramme sind nur für das Design auf hoher Ebene nützlich. Sobald der Code geschrieben wurde, sind alle Dokumente, die vor diesem Code geschrieben wurden, veraltet. Dies ist die Realisierung der Technik. Am Ende muss der Code die Dokumentation sein.
Andrew T Finnell
10
So ziemlich jeder Entwickler hat Fälle von Individualismus des Entwicklers gesehen, die hätten unterdrückt werden müssen. (Obwohl wahrscheinlich nicht nach der Wasserfallmethode).
Psr
2
@whatsisname, ich bin absolut anderer Meinung. Jeder Entwickler sollte die Entwicklung von Wasserfällen lernen, damit er sie als kanonisches Beispiel für schlechte Softwareentwicklung VERSTEHEN und ERLEBEN kann. Außerdem sind viele Geschäfte immer noch Wasserfälle für richtig oder falsch, und es ist wichtig, dass die Absolventen darauf vorbereitet sind.
maple_shaft

Antworten:

10

Haben Sie den Ausbilder gefragt, warum Sie alle Methoden auflisten müssen?

Es ist möglich, dass, wie bei vielen Anforderungen in einer Unterrichtsumgebung, die Absicht nicht darin bestand, Ihre Klassendiagramme für Entwickler hilfreicher zu gestalten, sondern Ihnen und Ihren Klassenkameraden dabei zu helfen, darüber nachzudenken, wie Sie Ihre Klassen gestalten würden. Wenn die Schüler lernen, wie sie größere Probleme in kleinere Probleme zerlegen können, ist es wahrscheinlich hilfreich, darüber nachzudenken, welche privaten Methoden sie wahrscheinlich benötigen würden. Und es ist wahrscheinlich hilfreich für den Ausbilder, eine bessere Vorstellung davon zu bekommen, welche Methoden die Schüler implementieren möchten, um früher in den Prozess einzugreifen, wenn das Design einer Person schlecht durchdacht ist. Die Dokumentation in einer Unterrichtsumgebung ist oft viel komplizierter als die Dokumentation in einer realen Umgebung, da der Ausbilder

Natürlich ist es auch möglich, dass der Ausbilder glaubt, dass diese Dokumentationsstufe in einem realen Projekt hilfreich ist. In diesem Fall ist der Ausbilder wahrscheinlich entweder veraltet oder stammt aus einem bestimmten Nischenhintergrund, in dem diese Planungs- und Dokumentationsstufe angemessen ist. Wenn Sie beispielsweise das Navigationssystem für das Space Shuttle erstellen oder medizinische Geräte entwerfen, ist es im Allgemeinen weitaus angemessener, im Vorfeld stark in das Design zu investieren, als den Code während der Entwicklung neu zu gestalten. Wenn Sie dagegen eine Social-Networking-Site entwickeln, ist ein agilerer Ansatz angemessener.

Justin Cave
quelle
+1, um darauf hinzuweisen, wie unterschiedliche Designs für unterschiedliche Zwecke benötigt werden. Gute Punkte auch beim Klassendesign; Den Ausbilder zu fragen ist eine gute Idee
Ethel Evans
1
Denken Sie an die Regel für das Bestehen eines College-Kurses: Finden Sie heraus, was der Professor will, und geben Sie das ab.
Christopher Mahan
9

Nein, der Kursleiter fordert Sie zu Recht auf, alle Eigenschaften und Methoden im Voraus aufzulisten, wenn Sie die Wasserfallmethode verwenden. Wikipedia bemerkt eine Kritik am Wasserfall:

Viele argumentieren, dass das Wasserfallmodell in der Praxis eine schlechte Idee ist. Sie glauben, dass es für ein nicht triviales Projekt unmöglich ist, eine Phase des Lebenszyklus eines Softwareprodukts perfekt abzuschließen, bevor Sie mit den nächsten Phasen fortfahren und daraus lernen. Beispielsweise wissen Kunden möglicherweise nicht genau, welche Anforderungen sie benötigen, bevor sie einen funktionierenden Prototyp überprüfen und kommentieren. Sie können ihre Anforderungen ständig ändern. Designer und Programmierer haben möglicherweise wenig Kontrolle darüber. Wenn Kunden ihre Anforderungen nach Fertigstellung des Entwurfs ändern, muss der Entwurf an die neuen Anforderungen angepasst werden. Dies bedeutet effektiv, dass viele Arbeitsstunden ungültig werden, was höhere Kosten bedeutet, insbesondere wenn ein großer Teil der Projektressourcen bereits in Big Design Up Front investiert wurde.

Diese Entwurfsmethoden quetschen den Umsetzer des Individualismus des Entwurfs nicht, da noch Teile zu interpretieren sind und Möglichkeiten, die Struktur einzigartig zu gestalten, z. B. ein Bild mit einem Skelett und das Hinzufügen von Muskeln und anderen Geweben, um ein Tier zu erschaffen, das sich fragt, wie viel Freiheit mussten Sie dieses Tier entwerfen?

Sie haben einen Mangel an Wasserfall gefunden, aber alles hat seine Stärken und Schwächen.

JB King
quelle
4

In der Klasse lernen wir verschiedene Methoden der Softwareentwicklung kennen. Diejenige, auf die wir uns konzentrierten und die wir zur Entwicklung unseres Projekts verwendeten, war die Wasserfallmethode.

Sie haben wahrscheinlich das klassische Wasserfallmodell gelernt, das die Person, die es von Anfang an in die Welt der Softwareentwicklung eingeführt hatte, für die Entwicklung umfangreicher Softwaresysteme als ungeeignet bezeichnete. Sie würden wahrscheinlich daran interessiert sein, Winston Royces Artikel mit dem Titel "Verwalten der Entwicklung großer Softwaresysteme" zu lesen , um mehr über die Probleme mit dem zu erfahren, was viele Menschen als Wasserfallmodell betrachten.

Das Waterfall-Modell ist jedoch gut geeignet, um den Lebenszyklus der Softwareentwicklung während des Durchlaufs zu lehren, und kann Zeit damit verbringen, Anforderungs-Engineering, Architekturdesign, detailliertes Design, Implementierung, Testen und Wartung in sehr klaren, unterschiedlichen Phasen zu erlernen und durchzuführen.

In unseren Klassendiagrammen mussten wir ALLE Eigenschaften und Methoden auflisten, einschließlich privater. Ich habe einige Bücher gelesen, nämlich Clean Code, die besagen, dass Funktionen so kurz und konzentriert wie möglich gehalten werden sollen. Es scheint mühsam, jede kleine Funktion in unseren Diagrammen aufzulisten, wenn sie anderen Entwicklern nicht hilft (sie sind privat, niemand anderes wird sie verwenden). Außerdem denke ich beim Entwerfen des Programms möglicherweise nicht an jede winzige Funktion, sondern möglicherweise beim Refactoring.

Dies sind alles sehr gültige Punkte.

Das Auflisten aller Eigenschaften und Methoden während der Entwurfsphase, auch bei Verwendung von Waterfall, ist wahrscheinlich übertrieben. Sie sollten auf jeden Fall alles auflisten, was öffentlich ist, zusammen mit den wesentlichen Eigenschaften. In Wirklichkeit ist alles andere ein Implementierungsdetail, das Sie erhalten können, indem Sie Ihre Implementierung in Diagramme zurückentwickeln.

Der Rat von Clean Code (ich habe ihn nie gelesen - ich halte mich nur an das, was Sie gepostet haben) scheint fair und auch dann anwendbar zu sein, wenn Sie die Waterfall-Methode verwenden. Sie können Ihre Klassen und Methoden in Bezug auf das Design Einzel Prinzip Verantwortung , Trennung von Bedenken und anderen Prinzipien der SOLID . Der Wasserfall sagt Ihnen nicht, wie Sie entwerfen sollen, nur wenn Sie es tun müssen. Das heißt, es ist im Vorfeld schwieriger, wenn Sie lernen und überlegen, wie Sie dies während der Implementierung besser tun können.

Ich denke, dies weist darauf hin, dass es eine klare Iteration zwischen Design und Implementierung geben muss - ein Problem, das der traditionelle Wasserfall nicht berücksichtigt.

Thomas Owens
quelle
1
@pillmuncher So wenige Leute haben es gelesen, es ist irgendwie traurig.
Thomas Owens
3
Das Traurigste an diesem Papier ist, dass die meisten Menschen tatsächlich einen Wasserfall entdeckt haben, während es ein Papier ist, das die Praxis gründlich diskreditiert.
Joeri Sebrechts
3

Es scheint mühsam, jede kleine Funktion in unseren Diagrammen aufzulisten, wenn sie anderen Entwicklern nicht hilft (sie sind privat, niemand anderes wird sie verwenden).

Wenn Sie der Meinung sind, dass dies langwierig ist, warten Sie, bis Sie eine echte Jobprogrammierung erhalten. Bedenken Sie für einen Moment, dass Software für Sie möglicherweise keine tragfähige Karriere ist.

Außerdem denke ich beim Entwerfen des Programms möglicherweise nicht an jede winzige Funktion, sondern möglicherweise beim Refactoring.

So?

Hat uns der Ausbilder etwas Falsches gesagt, indem er uns gebeten hat, jede Funktion aufzulisten?

Nein, es ist eine häufige Anforderung.

Und quetschen diese Entwurfsmethoden den Implementierer des Design-Individualismus (des Entwicklers), um Code zu schreiben, wie er ihn am besten verstehen kann?

Ja. Die Seelenzerstörung von Individuen ist ein wichtiger Bestandteil der Softwareentwicklung. Alle Individualität wird von allen Programmierern jederzeit auf alle möglichen Arten geschlagen. Es heißt, dass irgendwo in den "Programmierregeln Gottes" von einem Berg an einen Propheten weitergegeben wurde.

Nein. Sie scheuen nur die Langeweile. Überwinde es und mach dich wieder an die Arbeit.

S.Lott
quelle
1
@FreshDaddy. "Sie werden (größtenteils) niemals private Funktionen sehen." Falsch. Nachdem Sie die Lotterie gewonnen haben, übernehmen andere Programmierer Ihren Code und sehen die privaten Funktionen. Ebenfalls. Einige Sprachen (z. B. Python) meiden diese Art von Privatsphäre.
S.Lott
2
@ S.Lott - Das Auflisten jeder privaten Funktion ist überhaupt keine allgemeine Anforderung. Es kommt vor, verstehen Sie mich nicht falsch, aber eine vollständige "Liste aller privaten Funktionen vor dem Schreiben von Code" ist sicherlich ziemlich selten. Es gibt "notwendigen Tedius" und dann gibt es "wertlosen Tedius". In Anbetracht der Tatsache, dass Programmierer "wertlosen Langeweile" beseitigen wollen, würden Kunden aus der realen Welt kaum etwas so Kostspieliges und Sinnloses wie dieses anfordern, es sei denn, es handelt sich um einen Code vom Typ "Leben oder Tod".
Morgan Herlocker
1
@ironcode: '"liste jede private Funktion auf, bevor du Code schreibst" ist sicherlich ziemlich selten.' Nach meiner Erfahrung nicht. So lernen Menschen, Design zu machen. Junior-Programmierer halten sich oft an diesen Standard, bis sie nachweisen können, dass ihre Arbeit dieses Maß an Kontrolle nicht erfordert. Im Allgemeinen weniger als ein Jahr. Eine Organisation, die n00bs von der Schule genommen und sie ohne Aufsicht auf das Programmieren geworfen hat, schafft meistens nur große Probleme. Dieses Maß an Kontrolle ist wichtig, um sicherzustellen, dass Code eine kämpfende Chance hat, zu funktionieren.
S.Lott
1
@S Lott - mein Motto lautet: Wenn die Softwareentwicklung langwierig ist, machen Sie es falsch. Wir sind Programmierer. Wir automatisieren die Langeweile. Wir wiederholen uns nicht im Code, und es gibt auch keinen Grund, uns in der Dokumentation zu wiederholen.
Kevin Cline
1
@ Kevin: Diese Antwort ist reiner Sarkasmus. Als solches ist es völlig unangemessen und ich habe es markiert.
Michael Borgwardt
1

Programmieren ist die Kunst, innerhalb von Einschränkungen zu arbeiten. Die CPU bietet einen begrenzten Befehlssatz; Die E / A wird durch das Design der Hardware eingeschränkt. Betriebssystem-APIs werden erstellt, um bestimmte Verhaltensweisen zu fördern und andere einzuschränken. Hochsprachen werden oft entwickelt, um eine Reihe von Redewendungen gegenüber anderen zu fördern ...

Und auch Methoden sind so konzipiert, dass sie einschränken.

Ihre Herausforderung in allen Aspekten des Entwicklungsprozesses besteht darin, Ihre Vision innerhalb dieser Grenzen zu verwirklichen . Wirst du deinen Kopf gegen jede Wand schlagen, die durch Hardware, Sprache, API und Methodik aufgeworfen wird? Oder werden Sie einen Weg finden, das, was Sie erreichen möchten, mit dem zu harmonisieren, was erlaubt und gefördert wird?

Glaubst du wirklich , dein Lehrer möchte endlose Seiten mit Kleinigkeiten durchlesen? Testen Sie dann diese Theorie: Brechen Sie ein Programm auf und dokumentieren Sie jedes Atom. Wenn sein Schreibtisch unter dem Gewicht durchhängt, werden Sie wahrscheinlich feststellen, dass sein wahrer Wunsch etwas anders ist als erwartet.

Oder bereiten Sie die Dokumentation , wie Sie für richtig halten. Machen Sie es klar, machen Sie es verständlich, lassen Sie es wie einen Dashiell Hammett-Roman lesen. Und dann setzen Sie sich und sprechen Sie mit ihm, zeigen Sie ihm, was Sie getan haben, überzeugen Sie ihn von seinem Verdienst.

Shog9
quelle
1

Ich denke, der Ausbilder ist hervorragend darin, Sie zu diesem Projekt zu bewegen und Ihnen so die Vor- und (meistens) Nachteile der Wasserfallentwicklung beizubringen.

Afeygin
quelle
1

Eine einfache Faustregel zur Beurteilung der Komplexität der Projektanalyse lautet: "Kann der Entwickler oder das Unternehmen, für das er arbeitet, für etwas verantwortlich gemacht werden, das dramatisch genug ist (im Allgemeinen einschließlich Tod oder großer Geldverlust), das mit der erstellten Software passiert?".

Ich hatte für einige meiner Kurse die gleiche Erfahrung wie Sie. Leute, die einen Hintergrund in der Militärindustrie hatten, würden uns Analyse beibringen. Und das wäre eine vollständige und umfassende Analyse, die den gesamten Projektverlauf bis ins kleinste Detail plant. Sie können sich mit dieser Art von Projekt nicht viele Iterationen leisten (auch das Explodieren von Bomben kann in Ordnung sein, das Explodieren von Budgets nicht), also gibt es hier keinen Platz für Kreativität, Sie müssen sich an den Plan halten.

Auf der anderen Seite, wenn Sie ein bisschen gelesen haben, lesen Sie sicherlich über agile Methoden. Im Allgemeinen gibt es weniger Dokumentation und mehr Raum für den Entwickler, um seine Kreativität einzusetzen und gleichzeitig eine Lösung für das Problem zu entwickeln, auf das er stößt.

Je mehr Erfahrung Sie sammeln, desto besser und was Ihr Ausbilder Ihnen zeigt, gilt in einem Teil der Branche. Beachten Sie jedoch, dass es mit Sicherheit so viele Möglichkeiten gibt, ein Projekt zu verwalten und zu entwerfen, wie es gibt, um sie zu codieren. Und Sie werden Verteidiger und Kritiker für alle finden. Testen Sie sie während des Studiums und wählen Sie die aus, mit der Sie zufrieden sind.

Matthieu
quelle
Und seien Sie vorsichtig mit "Kann es Menschen töten, wenn es abstürzt?" Es gibt einen anderen Typ namens "Kann jemand ins Gefängnis gehen, wenn dies falsche Daten druckt", und das kommt oft zu dem Mann zurück, der die Tastatur fingert, also ist es gut, sehr detailliert zu sein Anforderungen bis ins kleinste Detail.
Christopher Mahan
@ Christopher: habe meine Antwort entsprechend angepasst, danke für den Kommentar :)
Matthieu
0

Einige Software-Engineering-Kurse, wie der, den ich hatte, werden in einem seltsamen Stil unterrichtet, in dem „Misserfolg Erfolg ist“, Erfolg eine verpasste Gelegenheit ist, aus Misserfolg zu lernen, und mehr ist immer weniger ist mehr. Wenn dies einer von denen ist, dann bleiben Sie einfach bei den Aufgaben und genießen Sie die Verrücktheit.

Job
quelle
0

Ich denke, Ihr Lehrer ist nicht in Kontakt. Kommerzielle Software wird selten in diesem Umfang entwickelt oder dokumentiert. Es ist viel zu teuer und die resultierende Dokumentation kann nicht ohne noch mehr Kosten gepflegt werden. IMO solche Praktiken sind ein Erbe aus Tagen, als die Codierung oft in Assemblersprache durchgeführt wurde. Ihre Zeit wäre besser gewesen, um agilere Praktiken auszuprobieren: testgetriebene Entwicklung, Paarprogrammierung, kontinuierliches Refactoring.

Hat der Ausbilder "falsch gesagt"?

Ich glaube schon.

Es ist verschwenderisch, Arbeitern des geistigen Eigentums langweilige Arbeit zuzuweisen. In der Schule hat langweilige Arbeit wenig oder keinen pädagogischen Wert, außer vielleicht, um Schüler zu langweiliger Arbeit zu bewegen. Solche Übungen haben negative Konsequenzen sowohl für die Studenten als auch für die Industrie. Die Schüler werden verletzt, weil ihre Zeit verschwendet wird. Die Branche ist geschädigt, weil einige Studenten zu dem Schluss kommen können, dass eine solche Langeweile notwendig und nützlich ist. Es ist weder. In dreißig Jahren in der Software war die einzige Arbeit, die ich mir vorstellen konnte, sowohl langweilig als auch nützlich, das Wechseln von Sicherungsbändern. Es gab Roboter, die das konnten, aber sie waren unerschwinglich teuer.

Kevin Cline
quelle
2
Ich wage zu sagen, Sie haben noch nie für ein Unternehmen gearbeitet, das mit Regierungsaufträgen Geld verdient. (Bearbeiten) Sie haben Kommerzielle Software gesagt. Meine Aussage ist jetzt bedeutungslos.
Andrew T Finnell
@ Andrew Finnel: Die Wahrheit ist auf so vielen Ebenen so schmerzhaft.
Peter Rowell
2
@ Andrew - Ich habe an DOD2167 gearbeitet. Es war schrecklich und unproduktiv, als es praktiziert wurde. Später arbeitete ich für ein anderes Unternehmen, das mit häufigen Lieferungen eine agile Entwicklung für die Regierung durchführt. Der Kunde ist sehr glücklich. Sie hatten eine nützliche Anwendung in sechs Monaten und erhalten vierteljährlich neue Funktionen.
Kevin Cline
@ Andrew Ich habe über 2 Jahre Erfahrung in der US-DoD-Arbeit, als Regierungsangestellter und als Auftragnehmer. Agile Methoden werden übernommen. Ein Team, an dem ich gearbeitet habe, hat Scrum aktiv eingesetzt und "gerade genug" Dokumentation "just in time" erstellt. Ja, die Dokumentation (sogar "gerade genug" Dokumentation) ist wesentlich umfangreicher als an vielen anderen Orten, aber dies hängt in der Regel von der Anzahl der beteiligten Parteien ab (Verträge können den Besitzer wechseln, andere Parteien können andere Systeme entwickeln usw.) und / oder die Sicherheit oder Lebenskritikalität und Bedeutung der zu entwickelnden Systeme.
Thomas Owens
2
@ Andrew, es sind nicht nur Regierungen. Ich habe 40 Seiten Spezifikationen für "Produkte" gesehen; Normalerweise können Sie alles aus dieser Tabelle auswählen und mir bitte eine abgegrenzte Pfeife geben. Niemand kann sich jemals die Mühe machen, sie zu lesen ...
Ben