Verhindert die Wiederverwendung von Software die Wiederholbarkeit von Prozessen?

25

Wiederverwendung von Code als Problem

Ich habe über diese Frage zur Softwarebereitstellung nachgedacht und bin immer wieder auf das Thema Wiederholbarkeit und / oder Reproduzierbarkeit zurückgekommen . Sie spielen eine Rolle, denn wenn Sie ein Projekt nicht wiederholen, wird es schwieriger, den Prozess zu verbessern, mit dem Sie das Projekt erstellt haben. Das Engineering beinhaltet die ständige Verbesserung der mit dem Entwurf und der Konstruktion verbundenen Prozesse, um Projekte mit höherer Qualität zu produzieren.

Software kann aufgrund ihrer digitalen Form stark auf die Wiederverwendung angewiesen sein. Anstatt ein Modul neu zu schreiben, rufen wir es einfach erneut auf oder kopieren es auf das andere System. Einige Beispiele sind Authentifizierung / Anmeldung oder möglicherweise eine Protokollierungsfunktion. Es gibt viele bekannte Beispiele für diese Kategorien, und die übliche Weisheit besteht darin, das Vorhandene wiederzuverwenden, anstatt das Eigene zu verwenden.


Einige Vergleiche zu anderen Disziplinen

Konstruktion

Im Gegensatz dazu ist der Bau physischer Systeme (Gebäude, Brücken) bei weitem nicht so wiederverwendbar. Es ist wahr, dass die Blaupause eines Hauses viele Male wiederverwendet werden kann, um dieselbe Kopie des Hauses zu bauen, aber die Konstruktion muss jedes Mal durchgeführt werden. So funktioniert Ausschneiden & Einfügen in der analogen Welt nicht. Brückenentwürfe sind weniger wiederverwendbar als Häuser, da die Standortbedingungen variieren.

Baumeister sind Experten, die dafür bekannt sind, dass sie in ihrem Gebiet Dutzende, Hunderte oder Tausende von Dingen entworfen und / oder gebaut haben. Zum Beispiel Frank Lloyd Wright , ein weltbekannter Architekt und Designer designed more than 1,000 structures and completed 532 works. Vergleichen Sie das mit Anders Hejlsberg , der „nur“ fünf Sprachen entworfen hat (Turbo Pascal; Delphi; J ++; C #; Typescript). In vielerlei Hinsicht ist es ein unfairer Vergleich, da die Domänen unterschiedlich sind. Auf einer breiten Ebene ist die quantifizierbare Produktion zweier sehr intelligenter Menschen jedoch sehr unterschiedlich.

Kampfkunst

Kampfkünstler werden sagen, dass die Beherrschung eines Zuges nur aus Tausenden von Wiederholungen resultiert. Nachdem ein Großteil dieser Wiederholungen vorgenommen wurde, sind viele Kampfkünstler überrascht, wie einfach eine zuvor als komplex empfundene Kata oder Form geworden ist. Die Ausbilder dieser Schüler werden auch bemerken, wie die Bewegung flüssiger und zielgerichteter wird und eine Wirtschaftlichkeit der Bewegung aufweist. Ebenso sind erfahrene Kampfkünstler in der Lage, komplexere Katas schneller als weniger erfahrene Studenten aufzunehmen. Die Erfahrung aus Wiederholungen hat ihnen einen Rahmen oder Prozess gegeben, der es ihnen ermöglicht, schneller zu lernen.

Holzbearbeitung

Holzarbeiter erleben eine ähnliche Transformation. Hobby-Holzarbeiter verweisen immer auf ihr erstes Projekt, das viele Schubladen benötigte. Wenn sie das Projekt abschließen, gewinnen sie eine neue Wertschätzung für die Effizienz, die Montagelinien erzielen. Es gibt noch weitere Vorteile, z. B. ein besseres Verständnis der Anordnung der Schubladenteile auf dem Plattenmaterial, um die Holznutzung zu maximieren. Im Vergleich zu Bastlern können professionelle Holzarbeiter Gegenstände, die sie schon oft hergestellt haben, schneller entwerfen, herstellen und herstellen. Sie erlangen auch die Fähigkeit, in der Konstruktion eines anderen Menschen inhärente Probleme zu erkennen, die diesen Fehler in ihrer Arbeit gemacht haben.


Verhindert die Wiederverwendung von Software, dass Softwareentwickler kompetenter werden?

In vielerlei Hinsicht ist Software-Design und -Konstruktion immer neu. Wir wiederholen keine früheren Arbeiten, denn wenn wir ein Modul, eine Bibliothek oder ein System wiederverwenden können, tun wir das auch. Wir werden ein bestehendes System vorzugsweise erweitern, bevor wir das Ganze von Grund auf neu schreiben . Aber Wiederholung ist es, was es uns ermöglicht, Effizienz im Design und in der Konstruktion zu finden. Jeder, der eine Sportart oder körperliche Aktivität ausgeübt hat, wird Ihnen sagen, dass Wiederholung der Schlüssel ist, um ein guter Praktiker zu werden.

Meine Frage: Verhindert die Wiederverwendbarkeit von Software die notwendige Prozessverbesserung und Effizienz, die sich aus der Wiederholung eines Projekts ergibt?

Gemeinschaft
quelle
Wenn Sie einen Code geschrieben haben, haben Sie im Wesentlichen ein Problem gelöst. Wenn Sie gut darin sind, löst dieses Stück eine KLASSE von Problemen. Wenn Sie wirklich gut sind, ist es erweiterbar auf eine Metaklasse von Problemen. Und dann verlieren Sie das Interesse: Es ist nicht erforderlich, ein Fahrrad zu perfektionieren, wenn ungelöste Designprobleme auftreten. Der Nervenkitzel beim Lösen von Problemen liegt nicht darin, alte Probleme zu perfektionieren, sondern darin, neue Dinge zu leuchten.
Deer Hunter
2
Gute Softwareprojekte "verlagern" viel Wiederholbarkeit in die Qualitätssicherung. Als ich ein Tester in einem 1,5-jährigen Projekt war, haben wir Testzyklen an wöchentlichen "Checkpoint" -Veröffentlichungen durchgeführt, insgesamt etwa 70 Mal während des Projekts. Das war ... leise gesagt ziemlich wiederholbar (es ändert sich nicht viel in einer Woche). Das Testen nächtlicher Builds war natürlich noch wiederholbarer - etwa 500 Mal während des Projekts (wenige unterhaltsame Showstopper-Fehler waren zu selten, um einen Unterschied zu machen). Nun sagen Sie mir eine Baufirma , die 500 Brücken gebaut hat - alle mit dem gleichen Team
gnat
@gnat - das ist ein hervorragender Einblick und eine Perspektive, über die ich noch nicht nachgedacht hatte. Andere Aspekte des SDLC werden aufgrund dieser Wiederholung viel effizienter.
1
@ GlenH7 erweitert es in die Antwort , vor allem Bilder von Brücken enthalten :)
Mücke
Wie viele Probleme hatte Frank Lloyd Wright in seinen 1000 Strukturen gegenüber Anders Hejsberg bei der Definition seiner fünf Sprachen zu lösen? Wright musste per Dekret Entscheidungen treffen, Anders musste Entscheidungen vielen Menschen rechtfertigen, die genauso klug und sachkundig waren wie er. Ich wette, dass Anders viele, viele weitere Probleme lösen musste. Ihre geworfenen Zahlen im Mix sind also nur das, was Sie zählen möchten, und keine WIRKLICH quantifizierbaren vergleichbaren Zahlen. Also mag ich die Frage, ich mag einfach nicht die Argumente / Beispiele, die die Frage inspirieren. Die Effizienz von SW hat sich im Laufe der Jahre enorm verbessert.
Dunk

Antworten:

10

Die Möglichkeit, Software wiederzuverwenden, verhindert keine Prozessverbesserung.

Wenn Sie über die Prozesse nachdenken, die beim Erstellen von Software erforderlich sind - Entwickeln von Anforderungen, Entwerfen des Systems, Implementieren des Systems, Bereitstellen des Systems, Verwalten von Anforderungen, Verwalten von Konfigurationen, Überprüfen und Validieren des Arbeitsprodukts, Nachverfolgen von Änderungen und eine Reihe anderer (siehe CMMI-Prozessbereiche für eine mögliche Aufschlüsselung von Schlüsselaktivitäten in der Softwareentwicklung - diese werden bei jedem Projekt wiederholt, unabhängig davon, wie viel Wiederverwendung Sie haben. Darüber hinaus verfügt jedes Unternehmen über eine Art von quantitativen und qualitativen Maßstäben, anhand derer bestimmt werden kann, wie gut der jeweilige Prozess oder die jeweilige Aktivität ist und wie gut der gesamte Entwicklungsprozess ist.

An einem Ende des Extrems können wir von einer robusten Software-Produktlinie ausgehen. Auf der anderen Seite können Sie von einer Entwicklung auf der grünen Wiese ausgehen. All diese Prozesse müssen immer noch in unterschiedlichem Maße ausgeführt werden, obwohl sie mit unterschiedlichen Raten oder vielleicht sogar in unterschiedlichen Sequenzen ablaufen können. Beispielsweise kann bei einem hohen Wiederverwendungsaufwand ein größerer Prozentsatz der zugewiesenen Zeit für Integrations- und Verifizierungs- / Validierungsaktivitäten auf Systemebene aufgewendet werden (Anforderungen V & V, Integrationstests, Systemtests, Abnahmetests). Bei neuen Entwicklungsbemühungen kann ein größerer Prozentsatz der Zeit für Entwurf und Implementierung erforderlich sein. Solange Sie einen Prozess mindestens einmal im Verlauf eines Projekts durchführen, können Sie ihn messen (quantitativ und qualitativ). Sobald Sie Anpassungen vorgenommen haben und sehen, wie sich diese Anpassungen auf einen Teil des Prozessbereichs oder auf die allgemeine Fähigkeit zur Bereitstellung von Software auswirken,

Der Schlüssel zur Prozessverbesserung besteht darin, eine logische Aufschlüsselung Ihrer Aktivitäten und Prozesse vorzunehmen, zu bestimmen, wie diese gemessen werden sollen (vorzugsweise konsistent) und wie diese Messungen zu verstehen sind, um Prozessänderungen zu einem bestimmten Zeitpunkt vorzunehmen. Es geht nicht darum, das Projekt zu wiederholen, sondern darum, wie Sie den Vorgang wiederholen.

Thomas Owens
quelle
Je nachdem, was tatsächlich wiederverwendet wird, kann es sogar zu einer CMMI-Erfassung kommen, dh nicht zu Entwicklungsarbeiten.
Imel96
1
CMMI ist dies jedoch in keiner Weise gelungen. Keine der "Killerapplikationen" des 21. Jahrhunderts wurde von Leuten entwickelt, die sich mit der CMMI-Reifematrix befassen. Einige brillante Leute hatten eine Idee und setzten sie um und stellten dann brillantere Leute ein, um den Umfang der Lösung zu erhöhen. Im Gegensatz dazu sind Projekte, die wahrscheinlich Standards wie CMMI zumindest Lippenbekenntnisse abverlangt haben, kläglich gescheitert, z. B. der Versuch des US-Verteidigungsministeriums, eine neue Gehaltsabrechnungsanwendung zu erstellen.
Kevin Cline
1
@ kevincline Es ist egal, ob CMMI erfolgreich war oder nicht. Ich bin in der Luft- und Raumfahrt- / Verteidigungsindustrie tätig und sehe CMMI in meiner Organisation und in den Unternehmen, mit denen wir zusammenarbeiten, bei denen wir Subunternehmer sind und bei denen wir Subunternehmer sind. Mein Punkt ist jedoch, dass Sie Ihre Prozesse identifizieren müssen, um eine Prozessverbesserung zu erzielen. CMMI ist ein einziges Tool, um genau das zu tun. Es gibt andere, und Sie können Ihre eigenen definieren. Sobald Sie Prozesse haben, können Sie diese definieren, messen und verbessern.
Thomas Owens
1
@ Kevin: "Killer Applications" sind von Natur aus "außerhalb des Mainstreams". Kein Wunder also, dass der größte Teil der neuen und innovativen Arbeit durch Experimentieren und Hacken und nicht durch einen disziplinierten Prozess entstanden ist. Obwohl "Killerapplikation" der eigenen Definition entspricht. Ist eine Anwendung, die zu einer Modeerscheinung wird, wirklich eine "Killeranwendung" oder das DoD-Programm, mit dem Jet Fighters sicher fliegen und verhindern können, dass ihre Verbündeten eher auf eine "Killeranwendung" schießen. Modeerscheinungen erfordern häufig überhaupt keine Fertigkeiten / Innovationen (z. B. Pet Rock, Hula-Hoop).
Dunk
... einschließlich vieler sehr beliebter "Mode" -Anwendungsprogramme. Während große DoD-Projekte fast immer ein enormes Maß an Geschick und Prozess erfordern. Darüber hinaus sagt Ihre Einschätzung des Versagens von CMMI wahrscheinlich mehr über Ihre Erfahrung (oder das Fehlen von Erfahrungen) in Branchen aus, in denen CMMI verwendet wird, als über CMMI selbst. CMMI ist nicht perfekt und wahrscheinlich auch nicht gut, aber zumindest veranlasst es Unternehmen, zumindest zu versuchen, einen Prozess aufzuschreiben und zu verfolgen und sogar zu versuchen, ihn zu verbessern. Wenn das alles ist, ist CMMI ein Erfolg.
Dunk
5

Ich denke, die Idee, dass andere Ingenieurdisziplinen die Wiederverwendung nicht nutzen, ist falsch. Auch beim Entwerfen von Gebäuden / Maschinen stehen Ihnen Komponenten zur Verfügung, die von vielen anderen Projekten verwendet werden. Entwerfen Sie zum Beispiel Ihre eigenen Schrauben? Motoren? Türen oder Fenster? Natürlich nicht. Diese werden oft von verschiedenen Personen entworfen, die sie dann in verschiedenen Produkten verwenden. Und sie sind häufig standardisiert, was eine noch stärkere Wiederverwendung fördert.

Ich denke, das Problem mag in der Komplexität. Sie können die Komplexität selbst komplexester Gebäude einfach nicht mit komplexer Software vergleichen. Es ist eine allgemein akzeptierte Idee, dass Softwarekomplexität es schwierig macht, sich von der Engineering-Seite her zu nähern. In dem Moment, in dem Sie über einen Prozess verfügen, mit dem Sie Software von akzeptabler Qualität erstellen können, stellt sich heraus, dass die Komplexität der Software, die Sie zum Erstellen von Sprüngen benötigen, in der Größenordnung liegt. Der Prozess kann also nicht verwendet werden. Wenn wir also einen Teil der Software mehrmals wiederholen müssten, bis wir mit dem Ergebnis zufrieden sind, würden wir diese Software niemals fertig stellen.

Deshalb wird für sauberen Code geworben. Die Fähigkeit, früheren Code basierend auf neuen Erfahrungen zu ändern, kann als Form der Wiederverwendung von Designs bezeichnet werden. Anstatt also mehrere Male unterschiedliche Software zu erstellen, überarbeiten und verfeinern wir einzelne Softwareteile, indem wir neue Erfahrungen wiederverwenden und alte Probleme weiterentwickeln. Während Sie versuchen, Software dazu zu bringen, dasselbe zu tun.

Euphorisch
quelle
Es ist nicht so, dass andere Disziplinen das Design nicht wiederverwenden, der Unterschied ist der Umfang der Wiederverwendung. Alle Objekte, die Sie erwähnt haben, müssen für jede Instanziierung physisch konstruiert werden. Ich kann zum Beispiel nicht einfach eine Tür kopieren und einfügen. Die Wiederholung, die aus der Konstruktion resultiert, führt dazu, dass Effizienzsteigerungen und Verbesserungen identifiziert werden, die zu Beginn nicht offensichtlich sind. Bauen Sie eine Reihe von Küchenschränken und Sie werden zwischen dem 1. und dem letzten neue Dinge entdeckt haben. Sie haben einen Punkt mit der Gesamtkomplexität, da die virtuelle Natur der Software es uns ermöglicht, Komplexität unwissentlich anzuhäufen.
1
@ GlenH7 Die Sache ist, Softwareentwicklung baut nicht. Sein Entwerfen. Mit dem Bauen macht man immer wieder dasselbe. Aber mit Design haben Sie immer andere Ziele und Probleme. Sie sollten es nicht mit dem Bau eines Gebäudes vergleichen, sondern mit der Erstellung eines Bauplans.
Euphoric
2
Ich bin mir nicht sicher, ob ich Ihrem Standpunkt zur Softwareentwicklung voll und ganz zustimme. SW-Entwicklung ist sowohl Design als auch Konstruktion. Die Konstruktion sollte eine Rückkopplungsschleife zum Entwurf liefern. Sowohl im analogen als auch im digitalen Bereich lassen sich gute Architekten "die Hände schmutzig machen" und bauen, um die Rückkopplungsschleife zu vervollständigen. Selbst wenn wir uns nur auf das Design konzentrieren, kann die Wiederholung des Designs meiner Meinung nach die Effizienz steigern, die zu einem besseren Design führt. SW wiederholt sich nicht wie andere Felder. Jede Brücke muss von einem allgemeinen Ansatz geändert werden, der sie an den Standort anpasst, in dem sie sich befindet.
SW dev ist nicht so komplex im Vergleich zu dem Entwurf, den der Architekt erstellen würde. Es ist nur so, dass wir es für schwierig halten, weil wir Software nicht als richtige technische Disziplin betrachten und weil wir die Dinge immer wieder neu erfinden. Wenn Sie nur wüssten, was in das Design von anderen
Dingen fließt,
Um mit der Brücke zu vergleichen - Sie haben Recht, Brücken sind ein gelöstes Problem. Sie wollen eine neue Brücke, entfernen die alten Entwürfe und nehmen einige Änderungen vor, und Sie haben eine neue Brücke (ich übertreibe natürlich die Einfachheit hier). Warum ist ein Webservice in Software nicht ähnlich aufgebaut? Das ist der Grund, warum Software IMHO nicht konstruiert, wir behandeln sie eher wie ein Handwerk (oder eine Kunst), bei dem jedes Projekt Maßarbeit ist.
Gbjbaanb
2

Software ist anders als die meisten anderen Disziplinen, so die Wirtschaftlichkeit von wo wir am besten verbringen unsere Zeit oft anders ist.

Während des Baus investieren Sie eine gewisse Menge Zeit und Geld in eine Blaupause (und Software ist weitaus mehr mit dem Erstellen einer Blaupause als mit dem Bauen eines Gebäudes vergleichbar). Es lohnt sich also, eine Menge Arbeit in die Erstellung des richtigen Entwurfs zu stecken. Genauer gesagt zu Ihrer Frage - es lohnt sich, die Anstrengungen zu wiederholen, die erforderlich sind, um das Endprodukt ein wenig zu verbessern.

In Software ist es viel billiger, das Produkt zu erstellen, als es für die Erstellung des Entwurfs war, wenn Sie den Entwurf haben. Zumindest die meiste Zeit - wenn die Software in einen Schrittmacher eingebettet wird, sind Sie in gewisser Weise der Situation eines Brückenbauers viel näher. Im Allgemeinen können durch die Wiederverwendung von Software 90% der Kosten Ihres größten Budgets eingespart werden, im Gegensatz zu 90% eines viel kleineren Budgets für den Bau einer Brücke. Wiederverwendung gewinnt also viel häufiger.

Was die Produktivität angeht - wenn Sie beispielsweise eine Brücke bauen, sehen Sie sich erheblichen realen Einschränkungen ausgesetzt. Stellen Sie sich vor, Architekten bekämen viel Geld, um Brücken für massive Multiplayer-Online-Spiele zu entwerfen, bei denen die Baukosten nahe Null lagen und die Beschränkung erheblich geringer war als in der realen Welt. Sie würden Brücken entwerfen, die nach realen Brückenstandards verrückt komplex sind. Die Blueprint-Phase kann etwas länger dauern.

Außerdem muss nur eine begrenzte Anzahl von Brücken gebaut werden, und da Design nur einen geringen Teil der Kosten ausmacht, können Sie für das Beste zahlen, und einige der Besten können den größten Teil des Designs übernehmen. Es gibt Hunderttausende von Software-Entwicklern, und im Grunde haben alle einen riesigen Rückstand auf Dinge, die sie tun würden, wenn sie Zeit hätten. Sie werden nicht einen Mann finden, der einen massiven Teil von all dem macht - es ist ein bisschen überraschend, dass es Leute gibt, die sich wirklich annähern.

Ihr eigentlicher Punkt scheint zu sein, dass wir durch die Wiederverwendung möglicherweise etwas verlieren, anstatt zu versuchen, Dinge zu wiederholen und zu verbessern. Ich denke du hast einen Punkt. Das Problem ist, dass, obwohl es höchstwahrscheinlich effizienter wäre, einige der grundlegenden Dinge neu zu schreiben und zu verbessern, jeder, der das übernimmt, das gesamte Risiko trägt und wahrscheinlich nicht den größten Teil der Belohnung. (Es gibt auch ein riesiges praktisches Problem der Abhängigkeitshölle, das wahrscheinlich einen Teil des Gewinns beim Umschreiben von Dingen mit sich bringt, aber nicht bis zu dem Punkt, an dem es sich nicht lohnen würde, zumindest wenn man sich das globale Bild ansieht. Copyright und Patente können auch Erzwingen Sie einen geplanten Neuentwicklungsaufwand, indem Sie einiges an Neuentwicklungsarbeit unterbinden, um kleinere Teile des vorhandenen Codes zu wiederholen.

In Bezug auf dem von Wiederholung zu lernen - in allen Disziplinen geschieht dies weniger im Design als in der Konstruktion, weil es ist weniger Wiederholungen, so dass weniger Chance zu lernen, und vielleicht weniger Nutzen. Auch der Prozess wahrscheinlich von Design einfach ist das nicht wiederholbar. Es ist ein bisschen wie ein Prozess zum Schreiben eines Romans. Ein guter Prozess kann mit ziemlicher Sicherheit helfen, und Software ist in der Regel weitaus kollaborativer als ein Roman. Es ist jedoch problematisch, einen Prozess zu wiederholen, wenn das Ziel darin besteht, etwas Neues zu erfinden. Sogar Schriftsteller lernen aus der Vergangenheit, aber ein wiederholbarer Prozess ist ein sekundärer Faktor für kreative Bemühungen. Und wenn ein Teil der Softwareentwicklung wirklich reproduzierbar ist, warum macht das dann kein Computer?

bA
quelle
2

Verhindert die Wiederverwendbarkeit von Software die notwendige Prozessverbesserung und Effizienz, die sich aus der Wiederholung eines Projekts ergibt?

Ich habe in den letzten 17 Jahren als System- und Softwareingenieur im selben großen Projekt gearbeitet, nebenbei bemerkt (unter Berücksichtigung der Airbus A380-Referenz in Ihrem ersten Link) in der Flugzeugindustrie, obwohl meine Zuständigkeiten im Bereich Militärflugzeuge liegen. Geschichten wie diese sind im Grunde genommen reine Fiktion und eigentlich sehr lustig anzusehen, wenn man Insider-Einsichten hat.

Aber für Ihre kurze und prägnante Frage: Aus meiner Erfahrung würde ich sowohl Ja als auch Nein sagen.

Lassen Sie mich zunächst sagen, dass ich alles für Software-Recycling in allen Formen bin (na ja, vielleicht nicht alle ...). Die Vorteile der Wiederverwendung von fast allem, von Code-Snippets und -Algorithmen zum Ausschneiden und Einfügen bis hin zu ganzen Codemodulen und Funktionsbibliotheken, sind im Großen und Ganzen weitaus besser, als immer wieder von vorne zu beginnen (um es ein wenig voranzutreiben).

Der Nachteil ist, wie Sie betonen (oder zumindest schließen), dass Sie sich, wenn Sie Funktionalität hinzufügen, indem Sie einfach einen bestimmten Satz von Komponenten zusammenstellen (und ich vereinfache dies bis zum Äußersten), nicht wirklich als ein Mensch entwickeln Programmierer, Ingenieur oder was auch immer.

Wenn ich mir nur die Software-Ingenieure ansehe, die mich bei der Arbeit umgeben, weiß ich aus langjähriger Erfahrung, dass die meisten von ihnen nichts über das Produkt wissen, das wir konstruieren, und dass sie kein Interesse daran haben, etwas anderes zu lernen, als das Nötigste, was sie produzieren müssen das Dokument oder den Code, dem sie zugewiesen sind.

Ich schwanke hier ein bisschen vom Thema ab, aber mein Punkt ist, dass, wenn die Programmierer nicht lernen müssen , wofür der Code, den sie erstellen, wirklich verwendet wird, und sie nicht das Innenleben des Systems lernen müssen , da sie es können Verwenden Sie bereits geschriebene und getestete Komponenten wieder. Die meisten von ihnen werden sich einfach nicht darum kümmern.

Zugegeben, dies ist auch auf andere Umstände zurückzuführen, zum Beispiel, dass das Produkt, das wir konstruieren, unglaublich komplex ist und es unmöglich ist, dass eine Person alles erfährt (und ich spreche nur von einem der Computer im Flugzeug - der komplexeste von ihnen, aber immer noch).

Wenn unsere Softwareingenieure nicht die Möglichkeit hätten, so viel Code wiederzuverwenden, dann wären sie meiner Überzeugung nach im Allgemeinen besser in ihrem Beruf und im Besonderen viel besser für das Projekt.

Oh, und Sie haben vielleicht bemerkt, dass ich hier viel über sie spreche. Zu diesen Software-Ingenieuren gehöre natürlich auch ich. Die Ausnahme ist, dass ich viel neugieriger und lernbegieriger bin als die anderen :-) Wenn ich vor einer neuen Aufgabe stehe, nehme ich es immer auf mich, so viel darüber zu lernen, wie ich kann, sowohl in der Schule als auch in der Schule Form von Fakten und durch das Studium des Quellcodes (ja, das gefällt mir auch).

Ah - verdammt, wieder auf der Seite ... Meine Entschuldigung ist, dass ich 32 Stunden nicht geschlafen habe, also ist meine Konzentrationsfähigkeit ein bisschen ... was habe ich gesagt?

Wenn noch jemand liest, lautet mein Fazit:

Ja , zu viel Wiederverwendung von Software führt dazu, dass weniger sachkundige Softwareingenieure deutlich weniger effizient sind, wenn sie tatsächlich wissen müssen, wie das Zeug funktioniert. Die Problemanalyse ist ein gutes Beispiel, oder sie kann auch nur feststellen, ob eine vorgeschlagene Entwurfslösung realisierbar ist. Und natürlich ist eine Prozessverbesserung auch schwieriger zu erreichen, wenn Sie nicht genau wissen, was Sie tun :-)

und Nein . Wenn Sie Software sorgfältig wiederverwenden , haben Sie möglicherweise viel Zeit, um Prozessverbesserungen zu erwägen und zu planen.

Boise
quelle
Ist die Tatsache, dass die meisten SW-Entwickler auskommen können, ohne die Funktionsweise des Systems zu kennen, nicht ein starker Indikator für eine umfassende Wiederverwendung? Ich finde es auch witzig, wie Regierungsprojekte so schrecklich klingen, aber wenn Sie etwas über Regierungsarbeit wüssten, würden Sie verstehen, wie ahnungslos der Autor ist. Die 1500-Dollar-Hämmer usw. ... Alle werden verständlich, wenn Sie erkennen, dass in Regierungsprozessen 10 Personen erforderlich waren, um vor dem Kauf wettbewerbsfähige Angebote zu überprüfen und zu erhalten.
Eintauchen
Ich tröste mich nicht mit dem Wissen, dass ein Software-Ingenieur, der an "dem komplexesten" Computersystem in einem Flugzeug arbeitet, in 32 Stunden nicht geschlafen hat. =)
RubberDuck
2

Wie in der akzeptierten Antwort in einer anderen Programmiererfrage ausgeführt, sind Analogien zur Konstruktion mit Sorgfalt zu behandeln:

Eine empfohlene Lektüre hierfür ist The Software Construction Analogy is Broken

Software wird oft mit Konstruktion verglichen. Leider ist diese Analogie fehlerhaft und die Lehren aus der Bauindustrie sind verdächtig ...

Was ich beobachtet habe, ist, dass gute Softwareprojekte viel Wiederholbarkeit in die Qualitätssicherung "verlagern".

Als ich ein Tester in einem 1,5-jährigen Projekt war, haben wir Testzyklen an wöchentlichen "Checkpoint" -Veröffentlichungen durchgeführt, insgesamt etwa 70 Mal während des Projekts. Das war ... leise gesagt ziemlich wiederholbar (es ändert sich nicht viel in einer Woche). Das Testen nächtlicher Builds war natürlich noch wiederholbarer - etwa 500 Mal während des Projekts (wenige unterhaltsame Showstopper-Fehler waren zu selten, um einen Unterschied zu machen).

Sagen Sie mir jetzt anhand dieser "verdächtigen" Analogie eine Baufirma, die 500 Brücken gebaut hat - alle mit demselben Team.

  • Sagen Sie mir im Anschluss, dass ein Unternehmen an jeder seiner neuen Brücken zumeist die gleichen Steine ​​und Eisen verwendet hat (hier verweise ich auf die Tatsache, dass die von uns getesteten Releases Tag für Tag und Woche zumeist die gleichen Codeteile aufwiesen) Woche - "nicht viel ändert sich").
    http://upload.wikimedia.org/wikipedia/commons/thumb/0/0c/GoldenGateBridge-001.jpg/220px-GoldenGateBridge-001.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Ponte25Abril1.jpg/220px-Ponte25Abril1.jpg

Baumeister sind Experten, die dafür bekannt sind, dass sie in ihrem Gebiet Dutzende, Hunderte oder Tausende von Dingen entworfen und / oder gebaut haben.

Gut, nach Ihrer oben zitierten Erklärung der Wiederholbarkeit kann ich also was sagen? Damals hat unsere kleine, nicht sehr spezielle Gruppe von Testern überprüft, siehe oben ("etwa 500") Hunderte von Dingen in unserer Region.

Projektentwickler haben buchstäblich gebaut ("Nightly Builds") - siehe, das Wort ist das gleiche und die Bedeutung stimmt in diesem Zusammenhang - Hunderte Dinge in ihrer Region.

Wenn man diese "verdächtige" Analogie bis hin zu "Tausenden von Dingen" fortsetzen will, sind diese Beträge wiederum nichts Spektakuläres in der Softwareentwicklung, wenn man sich die richtigen Dinge ansieht.

  • Als Beispiel, ein weiteres meiner vergangenen Projekte (wieder nichts Spektakuläres, eher reguläres), diesmal als Entwickler, läuft seit mehr als 5 Jahren (8 Hauptversionen, mehrere Dutzend Nebenversionen). Es gab ähnliche wöchentliche Checkpoints ( 5x52~=250von ihnen), ähnliche nächtliche Releases ( 5x365~=1800von ihnen) und ähnliche Entwickler- / QA-Teams, die daran arbeiteten. Tag für Tag, Woche für Woche, Monat für Monat, meistens sich wiederholende Dinge (nicht viel Wechsel zwischen zwei nächtlichen Builds) - wie versprochen, im Bereich von Tausenden von Malen (1800).

Langlebigere Projekte wie Windows oder Java oder AutoCAD können eine Laufzeit von 10, 20 oder 30 Jahren haben, was leicht dazu führt, dass so viele "Tausende" nächtliche Builds und nächtliche Tests wie möglich wiederholt werden.


Das Konzept der Verlagerung der Wiederholbarkeit auf die Qualitätssicherung wird durch die kontinuierliche Integration noch wichtiger ...

die Praxis ... alle Entwickler-Arbeitskopien mehrmals am Tag mit einer gemeinsamen Hauptzeile zu verschmelzen ... CI kann als Intensivierung der Praktiken der periodischen Integration angesehen werden.

Zusätzlich zu automatisierten Komponententests verwenden Unternehmen, die CI verwenden, in der Regel einen Build-Server, um kontinuierliche Prozesse zur Durchführung der Qualitätskontrolle im Allgemeinen zu implementieren . Zusätzlich zum Ausführen der Unit- und Integrationstests führen solche Prozesse zusätzliche statische und dynamische Tests durch, messen und profilieren die Leistung, extrahieren und formatieren die Dokumentation aus dem Quellcode und erleichtern manuelle QA-Prozesse. Diese kontinuierliche Anwendung der Qualitätskontrolle Ziele , die zur Verbesserung der Qualität der Software , und die Zeit genommen zu reduzieren zu liefern, durch die traditionelle Praxis der Anwendung der Qualitätskontrolle zu ersetzen nachAbschluss aller Entwicklung. Dies ist sehr ähnlich zu der ursprünglichen Idee, häufiger zu integrieren, um die Integration zu vereinfachen, und gilt nur für QS-Prozesse ...

Wiederholbarkeit? Es ist genau dort, so viel wie man sich vorstellen kann.

Bei häufiger / kontinuierlicher Qualitätssicherung gehen die Probleme schnell zu den Entwicklern zurück, die gezwungen sind, die Versuche zu wiederholen, bis die fehlgeschlagenen Tests erfolgreich bestanden wurden. In gewisser Weise ähnelt dieser Zyklus des Wiederholens bis zum Durchlauf der Code-Cata ,

eine Übung in der Programmierung, die einem Programmierer hilft, seine Fähigkeiten durch Übung und Wiederholung zu verbessern ...

Mücke
quelle
1
Hervorragende Punkte, und ich denke, dass die Fluchten, die dann in die automatisierte Testsuite zurückgeführt wurden, einige der Erfahrungen einfangen, auf die ich anspiele. In Bezug auf die Behauptungen des "gleichen Teams" schiebe ich mich auf Wrights Erfahrung zurück. Mit über 500 gebauten Gebäuden war er ein gemeinsames Element für alle. Aber es wird darauf hingewiesen, und ich stimme einigen Prämissen zu.
@ GlenH7 Ja, die Auswirkungen von Wiederholungen waren wirklich tiefgreifend und gingen weit über Testsuiten hinaus. Wissen hat sich überall dort angesammelt, wo es zu Wiederholungen gekommen ist - wissen Sie, nach 20 ... 30 ... 50-maligem Ausführen des Vorgangs hat sich alles zum Optimum entwickelt. Checkpoint / nächtliche Vorbereitungen, Fehlerübermittlungen (und das gesamte "Fehlerleben"), Kommunikation mit Entwicklern / Qualitätssicherern / Systemadministratoren, Dokumentation usw. usw. Ich habe mich nur auf die Wiederholbarkeit konzentriert, weil ich mich mit Fragen der Wissensakkumulation befasste, die sich natürlich daraus ergaben habe einen feuerschlauch effekt auf die präsentation meines point
gnat
-1

Einiges von dem, was Sie sagen, ist wahr: z. B. Bibliotheken lösen Funktionen, die nicht von Hochsprachen gelöst wurden, die Probleme lösen, die nicht von der Assembly gelöst wurden, die Probleme lösen, die nicht vom Maschinencode gelöst wurden. Wenn Sie in Java System.out.println () aufrufen, verlieren Sie aus den Augen, wie eine CPU auf ein Gerät ausgibt.

Also ja, du verlierst etwas. Was Sie gewinnen, ist die Fähigkeit, sich auf ungelöste Probleme zu konzentrieren. Möglicherweise müssen Sie sich jetzt mit einigen anderen Aspekten der Technologie befassen (z. B. der Funktionsweise von Netzwerken), um ein Problem zu lösen. Sie müssen jedoch kein Experte für Maschinensprache sein, wenn Sie nur eine Webseite erstellen möchten.

Ebenso lösen Brückenbauer jedes Mal ein etwas anderes Problem (es ist ein anderer Fluss). Sie kümmern sich nicht darum, wie Stahlträger mit einer bestimmten Zugfestigkeit hergestellt oder Schrauben mit einer bestimmten Toleranz bearbeitet werden können. Das überlassen sie Spezialisten, die dieses Problem gelöst haben.

Wenn Sie genau hinschauen, werden Sie feststellen, dass unsere gesamte Gesellschaft und Infrastruktur zu 99% auf Wiederverwendung und nur zu 1% auf echtem Fortschritt basiert. Die meisten neuen Dinge sind nur alte Dinge, denen ein kleines Extra hinzugefügt oder entfernt wurde. Es ist die Anhäufung von menschlichem Wissen. Sie können Code in einer höheren Programmiersprache mit anständigen Bibliotheken schreiben, weil jemand all die umwerfend komplizierten Dinge herausgefunden hat, die erforderlich sind, um an diesen Punkt zu gelangen. Es ermöglicht Ihnen, neue und interessante Probleme zu lösen.

Um dies alles zusammenzufügen und auf Kommentare zu antworten: Sie müssen keine Probleme lösen, die bereits gelöst wurden, um die Kompetenz zu entwickeln. Außerdem wird vieles, was Sie tun, das Rad neu erfinden. Kurz gesagt lautet die Antwort also "Nein". Sie müssen die Funktionen von Bibliotheken nicht erneut implementieren, um kompetent zu werden. Es gibt viele Gelegenheiten, einige davon sind kreativ, um Ihr Handwerk zu verbessern.

Amot
quelle
1
Ich denke, Sie berühren einige potenziell gültige Punkte, aber ich sehe nicht, dass sie zusammenpassen, um die Frage zu beantworten. Und ich bin nicht mit Ihrem 99: 1-Verhältnis für die Wiederverwendung einverstanden. Ich denke, das überschätzt den Wiederverwendungsaufwand bei weitem. Selbst innerhalb der Softwareentwicklung sind die Wiederverwendungsraten bei weitem nicht so hoch.
-2

Es geht nur um Ressourcen. Wenn Sie vor Jahren Softwareprojekte für große Mainframe-Computer entwickelt haben, gibt es diese möglicherweise seit etwa 15 Jahren mit einer weitgehend statischen Entwicklungsumgebung. Das zur Berechnung der Gehaltsabrechnung geschriebene FORTRAN-Programm oder das COBOL-Programm wurde über Jahrzehnte hinweg perfektioniert, da es ständig verwendet wurde. Es gab Ressourcen, um zu sehen, wie dies verbessert werden könnte. Wir haben keine so langsame Umgebung mehr, um die Fähigkeiten für ein bestimmtes Projekt zu verfeinern und zu verbessern. Aber wir nehmen die Fähigkeiten und passen sie an die nächsten Projektressourcen an, sofern dies möglich ist. Aber am Ende wird es zu einer Auswahl von Geldern, die für das neue Projekt ausgegeben werden, um den Job zu erledigen, oder um den neuen Job mit einer großen Menge an Vergoldung zu erledigen. Vergolden eines Projekts bedeutet, es bis zum n-ten Grad zu verbessern und eine Menge Schnickschnack hinzuzufügen, selbst wenn der Benutzer dies nicht getan hat.

Das Beste, was wir tun können, ist das Gesamtdesign eines neuen Projekts zu betrachten und zu sehen, wie es basierend auf den Erfahrungen des Teams in der Vergangenheit verbessert werden kann. Es ist jedoch eine echte Erfahrung, wenn ein Softwarearchitekt eine Vorstellung davon hat, was tatsächlich als Verbesserung des Designs zur Verbesserung der Fähigkeiten angesehen wird, anstatt einfach das neueste Schlagwort in der Entwicklung wie Agile, OOP usw. zu verwenden.

Edward
quelle
3
Ich verstehe einige der Punkte, die Sie ansprechen wollen, aber sie beruhen auf Vermutung und Unbekanntheit. Früher habe ich für Großrechner entwickelt, und ich kann Ihnen versichern, dass die Entwicklung genauso schnell war wie auf offenen Systemen. Der Prozess war anders, aber das Tempo war gleich. Ihre Antwort wäre klarer, wenn Sie sich auf die übertragbare Kompetenzkomponente konzentrieren und mögliche Effizienzgewinne erläutern würden.
Sie müssen sich die Geschichte ansehen, es gab nicht jedes Jahr neue Technologien für Großrechnersysteme, zum Beispiel für CDC 6600 Kronos OS. Es war im Grunde 15 Jahre lang statisch. Jetzt geht es viel schneller und es fehlt die Zeit, um über 15 Jahre lang tiefes Wissen zu erlangen. Es gibt keine Flash-Programmierer mit 15 Jahren Erfahrung, die zum Beispiel nur Flash machen. Nachdem ich meinen Beitrag erneut gelesen habe, stehe ich zu meinem ursprünglichen Beitrag.
Edward