Ist es möglich, Software zu schreiben, die nicht ständig geändert werden muss?

23

Ich habe viel Software in vielen verschiedenen Sprachen geschrieben und Hardware für die Verwendung mit FPGAs mit Verilog und VHDL "geschrieben".

Ich schreibe lieber Hardware als Software, und ich denke, einer der Hauptgründe ist, dass es möglich ist, Hardware zu schreiben, die "fertig" ist und nie geändert werden muss: Sie definieren die Schnittstellen und die Funktionalität, schreiben einen Prüfstand , implementieren Sie das Hardwaremodul und testen Sie es mit einem Simulator. Dann können Sie sich darauf verlassen, dass dieses Hardwaremodul ein Baustein ist, um etwas Größeres und Besseres zu erstellen: Wenn Sie diesem Modul ein Feature hinzufügen müssen, erstellen Sie ein zweites Modul und fügen die Funktionalität dort hinzu. Sie werfen das Originalmodul niemals weg, da es einwandfrei funktioniert und dennoch nützlich sein kann.

Eine meiner größten Frustrationen mit Software ist, dass sie niemals "gemacht" wird. Es gibt immer eine weitere Funktion, die hinzugefügt werden muss. Oft führt das Hinzufügen einer Funktion zu einem Fehler an einer anderen Stelle, der zuvor einwandfrei funktioniert hat. Dies ist bei Hardware nicht der Fall, solange die Schnittstellen nicht verletzt werden.

Um es klar auszudrücken, ich befürworte nicht, eine Version von etwas mit einer Liste von Funktionen zu erstellen, und das ist alles für immer: Ich bin für Iterationen und mehrere Releases im Laufe der Zeit, um neue Funktionen hinzuzufügen. Ich möchte einfach nicht den Code auf der linken Seite stöbern und einen Fehler auf der rechten Seite finden, und dies scheint zu geschehen, nachdem ich eine neue Funktion hinzugefügt habe.

Ist es möglich, Software auf ähnliche Weise zu schreiben, wie Hardware "geschrieben" wird? Gibt es eine gute Softwareentwicklungsmethode, mit der immer Fortschritte erzielt und neue Funktionen hinzugefügt werden können, ohne dass vorhandener Code neu geschrieben und neue Fehler eingeführt werden müssen?

Nathan Farrington
quelle
8
Sie scheinen OCP
Oded
Das Open-Closed-Prinzip-Zeug sieht toll aus! Hat jemand dies erfolgreich eingesetzt?
Nathan Farrington
2
@ NathanFarrington: Die meisten Designmuster (wie von GOF beschrieben ) folgen der OCP. Ein Beispiel wäre das Template Method Pattern .
Spoike
2
@ NathanFarrington Das Open-Closed-Prinzip ist ein allgemeines Prinzip, das von Softwareentwicklern beim Entwerfen von Software verwendet wird.
Jesper
1
Ich kann mir vorstellen, dass viele der Programme, die wir heute verwenden, aus Einzelteilen bestehen, die Kopien des vor 20 Jahren geschriebenen Codes sind.
Mallow

Antworten:

16

Vielleicht hat es etwas mit genau definierten Schnittstellen und Tests wie Hardware zu tun?

Genau meine Gedanken!

Gut gestaltete Module mit klaren Schnittstellen sind im Wesentlichen perfekt. Denken Sie an etwas wie StringJava-Klasse. Es ist ein Computerprogramm, aber es hat eine kristallklare Oberfläche. Es sind keine Bugs bekannt. Es macht das, was es machen soll, perfekt. Sicher, es wurde in den letzten 15 Jahren ausgiebig getestet und da praktisch alle Programme Strings als Grundbausteine ​​verwenden, würde jeder Fehler darin schnell bemerkt werden. Jegliche "Macken" - nicht nur Bugs, sondern Design-Details, die es wert sind, beachtet zu werden - wie die hier beschriebenen http://www.jwz.org/doc/java.html sind mittlerweile bekannt und können daher berücksichtigt werden Konto.

Buggy-Software ist teilweise ein kulturelles Problem: Die Leute sind daran gewöhnt, Software zu buggeln, und im Gegensatz zu Hardware kann Software normalerweise einfach nachträglich repariert werden, sodass sie anfangs nicht perfekt sein muss (oder überhaupt, denn hey, wir müssen sie jetzt versenden, lassen Sie uns reparieren) es in der nächsten Version). Aber zum großen Teil handelt es sich um ein echtes Problem der Komplexität: Die Software-Komplexität hat in den letzten 50 Jahren stetig zugenommen, aber das menschliche Gehirn ist dasselbe. Wenn die zunehmende Schwierigkeit, Perfektion zu erreichen, und die zunehmende Leichtigkeit, Dinge später zu reparieren (schnelle, automatische Builds, Internet-Verteilung) mit Termindruck und mangelnder Disziplin einhergehen, ist das Ergebnis das, was es ist.

Gibt es eine gute Softwareentwicklungsmethode, mit der immer Fortschritte erzielt und neue Funktionen hinzugefügt werden können, ohne dass vorhandener Code neu geschrieben und neue Fehler eingeführt werden müssen?

Wahrscheinlich keine Silberkugel, aber eine gute Kombination von Best Practices, einschließlich, aber nicht beschränkt auf:

  • Einfache, autonome Module. Mit anderen Worten, niedrige Kopplung und hohe Kohäsion.
  • Unveränderlichkeit. Besonders wichtig bei wachsender Nebenläufigkeit.

Es ist erwähnenswert, dass beide Punkte auf eine Reduzierung der Komplexität abzielen. Das ist der entscheidende Punkt. Die Entropie nimmt immer mehr zu, und wenn wir nicht dagegen ankämpfen, werden wir bald in Komplexität ertrinken. Es ist auch interessant zu sehen, dass sich die Programmiersprachen in den letzten Jahren dahingehend entwickelt haben, die oben genannten Praktiken zu fördern oder sogar durchzusetzen. Insbesondere der Aufstieg der funktionalen Sprachen ist genau das: Reine Funktionen geben immer den gleichen Wert für die gleiche Eingabe zurück, es gibt keinen Zustand in ihnen. Dann komponieren Sie einfach reine Funktionen, die unveränderliche Werte annehmen und zurückgeben , und beschränken die unvermeidliche Veränderbarkeit auf kleine, genau definierte Stellen, anstatt sie zu verteilen. Überprüfen Sie dies aus: http://clojure.org/state

Joonas Pulakka
quelle
1
jwz ist sich nicht ganz einig, dass die String-Klasse fehlerfrei ist - jwz.org/doc/java.html
1
Es kann so funktionieren, wie es entworfen wurde. Die Frage ist also, ob das zugrunde liegende Design defekt ist. Ich stimme jedoch zu, dass String eine sehr zuverlässige Klasse ist.
1
Hervorragende Antwort. Ich programmiere jetzt fast ausschließlich in Python und versuche, die funktionalen Programmierkonstrukte auszunutzen. Ja, ich denke Sie haben Recht, dass Unveränderlichkeit der Schlüssel ist. Wenn ich zum ersten Mal ein Softwaremodul erstelle, obwohl ich es teste, habe ich wahrscheinlich die Benutzeroberfläche durcheinander gebracht, oder vielleicht hat es die falsche Verantwortung oder zu viele. Also mache ich ein zweites Modul und lasse das erste in Ruhe! Wenn ich möchte, kann ich das erste Modul auch in Zukunft verwenden, es jedoch nie ändern, da es zwar nicht perfekt ist, aber funktioniert. Funktionale Sprachen mit Unveränderlichkeit könnten also helfen, wie Sie vorschlagen.
Nathan Farrington
1
@JoonasPulakka: Ja, wenn es eine einzeilige Zusammenfassung der Software gibt, könnte es sein, dass "es immer einen anderen Fehler gibt". :-) Und ich denke, das ist einer von Nathans Punkten.
Ross Patterson
1
Joonas, du gewinnst. Ich habe angefangen, Clojure zu lernen. Es scheint der beste Weg zu sein, um wieder Spaß am Programmieren zu haben.
Nathan Farrington
9

Der Unterschied ist, wie viel einfacher und billiger es ist, Software im Vergleich zu Hardware zu modifizieren. Wenn Hardware so einfach und billig zu modifizieren und an Kunden zu versenden wäre, würden sie es tun.

Ich denke, wenn ich meine schlecht formulierte Frage zusammenfassen könnte, wäre es so etwas wie: "Wie kann ich mehr Spaß daran haben, Software zu schreiben, indem ich keine Fehler in den Arbeitscode einführe und immer Fortschritte mache?" Vielleicht hat es etwas mit genau definierten Schnittstellen und Tests wie Hardware zu tun?

Sie sollten auf jeden Fall die testgetriebene Entwicklung überprüfen .

RCE
quelle
Viele Antworten auf meine Frage scheinen Folklore zu enthalten. Ist es notwendigerweise einfacher, Software-Fehler zu finden und zu beheben, als die Fehler von Anfang an zu entwerfen? Was kostet es wirklich, Software zu modifizieren? Wahrscheinlich weiß es niemand so genau. In Bezug auf die testgetriebene Entwicklung ist es sinnvoll, Software zu testen, die wiederverwendet werden kann. Die Software wird dann eher zu einem eigentlichen Baustein als zu einem Schlammballen. Aber es macht keinen Sinn, Software zu testen, wenn sie sich erst morgen ändert. Ich denke, ich habe mich gefragt, ob wir tatsächlich Software aus Bausteinen und nicht aus Schlamm machen können.
Nathan Farrington
1
@ NathanFarrington: Ich glaube, es gibt einen großen Unterschied in der Art und Weise, wie die Hardware- / Software-Spezifikation und das Design hergestellt werden. Die meisten Hardwarehersteller haben höchstwahrscheinlich bessere Spezifikationen für das, was sie herstellen, als ein Softwareentwickler, dessen Kunde nur sagen kann: "Ich möchte ein Programm, das dies tut!" Es ist so gut wie garantiert, neue Funktionen zu erhalten und was nicht.
RCE
Sicher, wenn es viele Änderungen gibt, müssen möglicherweise auch einige Tests geändert werden, aber es ist nicht so, als würde sich die Software von einem Textverarbeitungsprogramm zu einem Webserver ändern. Ihre Funktion "Neues Dokument" erstellt weiterhin eine neue Funktion und ihre Tests sollten weiterhin gültig sein.
RCE
Sie wiesen auf ein anderes Schlüsselprinzip hin: Je besser die Spezifikationen sind, desto weniger Änderungen sind später erforderlich. Dies war jedoch nicht genau das, worauf ich bei meiner Frage gekommen bin, da Sie der Hardware Funktionen hinzufügen können, bevor dies wie bei der Software erfolgt. Ich denke, OCP war die richtige Antwort. Leider ist es ein Kommentar, daher kann ich ihn nicht als Antwort markieren. Ein weiterer Punkt war, immer vorwärts zu kommen, und ich denke, dass TDD dies durch die Bereitstellung von Regressionstests unterstützen kann.
Nathan Farrington
Das Wechseln der Software scheint einfacher und kostengünstiger zu sein als das Wechseln der Hardware. Aber ist das wirklich so? Ja, ich kann eine Änderung vornehmen und fast augenblicklich mit dem Fingerdruck einen neuen Build erstellen. Der Build muss jedoch noch einer Validierung / Qualitätssicherung unterzogen werden. Was waren die Opportunitätskosten? Was hätte ich getan, anstatt diesen Fehler zu beheben? Was hätte QA getan, wenn sie die Software nicht erneut validieren müssten? Wurden verschiedene Projekte verschoben, um diesen Fix auf den Markt zu bringen? Es gibt viele "versteckte" Kosten, über die die Leute nicht nachdenken. Es ist vielleicht einfacher, aber nicht unbedingt billiger.
Pemdas
6

Ich werde einige Ihrer Bemerkungen kommentieren, in der Hoffnung, dass Sie die Antwort aus diesen Kommentaren erhalten.

Eine meiner größten Frustrationen mit Software ist, dass sie niemals "gemacht" wird.

Dies liegt daran, dass die Lösungsspezifikation unvollständig ist oder der Plan zur Bereitstellung von Verbesserungen nicht korrekt ist. Dies kann bei jeder Projekt-Software, Hardware oder anderen passieren.

Gibt es eine gute Softwareentwicklungsmethode, mit der immer Fortschritte erzielt und neue Funktionen hinzugefügt werden können, ohne dass vorhandener Code neu geschrieben und neue Fehler eingeführt werden müssen?

Das Erstellen unabhängiger Module sollte die Abhängigkeit natürlich erheblich verringern. Dies muss beim Entwerfen der Software berücksichtigt werden. Sie müssen Bedenken, Ebenen, Ebenen, Controller-Objekte, Schnittstellen usw. berücksichtigen und trennen.

"Wie kann ich mehr Spaß beim Schreiben von Software haben, indem ich keine Fehler in den Arbeitscode einführe und immer Fortschritte mache?"

1-Anforderungen sorgfältig verstehen. Möglicherweise müssen Sie in Betracht ziehen, die Anforderungen vor dem Entwurf zu schließen. Wenn Sie eine iterative Entwicklung durchführen, ist dies nicht möglich. Einige Methoden unterstützen dies, aber ich persönlich denke, dass dies nicht für alle Projekttypen geeignet ist. Das Erstellen von Software auf soliden Anforderungen ermöglicht ein besseres Design.

2-Machen Sie Ihren Benutzern diese langfristige Philosophie verständlich.

3-Planen Sie die Implementierung sorgfältig

4-Design vor Code.

5-Gegebenenfalls generisches Design verwenden.

6-Verwenden Sie Prototypen als Designbestätigungswerkzeug.

Keine Chance
quelle
Dies sind alles hervorragende Ratschläge. Um meine Gedanken bis zu diesem Punkt zusammenzufassen: (1) Machen Sie Releases zu einem BIG DEAL und führen Sie viele Tests und Qualitätsprüfungen vor einer Veröffentlichung durch Schnittstellen und Zusicherungen, um festzustellen, ob die Schnittstelle verletzt ist und ein Modul, sobald es "freigegeben" ist, niemals geändert wird (OCP).
Nathan Farrington
4

Wie die Leute in der Regel sehr schnell darauf hinweisen, besteht einer der Vorteile von Software darin, dass sie im Vergleich zu Hardware einfach und relativ billig zu ändern sein soll. Dies ist besonders wichtig, wenn Sie zu spät feststellen, dass etwas grundlegend falsch ist. Machen Sie dasselbe mit Hardware, und Sie verlieren eine Million Dollar. Wie Sie gesagt haben, verwenden Sie Ihre Simulatoren usw. und testen die Bazinga daraus. Ich denke, hier schlägt das Paradigma etwas fehl, wenn Sie auf Software umsteigen.

Kommen Sie in den Kopf eines durchschnittlichen Software-Entwicklers, und was Sie haben, ist eine sehr beschäftigte Person mit einer unglaublich engen Frist. Sein Manager sagt, dass es in Ordnung ist, ein paar Fehler zu hinterlassen, da Sie diese später jederzeit beheben können. Tests sind oft ein nachträglicher Gedanke, aber selbst in einem testgetriebenen Szenario werden die Tests minimal gehalten und der Code auf das Minimum der Tests beschränkt. Oft werden Verknüpfungen verwendet, damit viele der Grenzfälle übersehen werden. Das System kann gründlich getestet werden, wird jedoch selten als Ganzes rigoros getestet und ebenso selten in hohem Maße einem Stresstest unterzogen. Hinzu kommt, dass Sie Software von Grund auf neu schreiben und es kaum Gelegenheit gibt, die Software zu simulieren, bevor Sie sich zum Schreiben verpflichten. Dies liegt hauptsächlich daran, dass wir selten Software aus denselben feinkörnigen Bausteinen schreiben, die Sie in Hardware finden würden.

Zurück zur Frage des OP. Können Sie ein System von Bausteinen definieren, aus denen Sie Ihre gesamte Software ableiten können? Möglicherweise. Wäre es sehr kostengünstig? Wahrscheinlich nicht, denn bis Sie ein robust genuges System aus Komponenten, Tests und anderen Utensilien entwickelt haben, um dieses Ideal zu unterstützenSystem der Programmierung, würden Sie feststellen, dass Ihre Konkurrenz Sie bereits auf den Markt geschlagen hätte, und noch schlimmer, aus der Sicht des durchschnittlichen Programmierers würden Sie wahrscheinlich einen "Ausstecher" -Stil des Programmiersystems als sehr einschränkend und wahrscheinlicher als sehr empfinden langweilig. Ich persönlich arbeite an einer API, bei der der Großteil des Modulcodes so vollständig verfeinert und standardisiert wurde, dass ich jetzt nur noch eine Codevorlage generiere und die Lücken ausfülle. Die meiste Zeit kann ich damit verbringen, einfachen Steckercode zu schreiben und die Module so schnell wie möglich aus der Tür zu holen. Es ist ernsthaft betäubend. Es gibt kaum eine Möglichkeit, mehr zu tun als nur die gleichen Dinge immer und immer wieder zu programmieren. Wenn sich also eine andere Möglichkeit für ein Projekt ergibt, ergreife ich die Chance, etwas anderes zu tun.

Wie können Sie also qualitativ hochwertige und gut faktorisierte Software liefern und es dennoch genießen, dies zu tun? Ich glaube, das hängt von Ihrer Wahl der Tools und Methoden ab. Für mich bestand die Antwort darin, die Verwendung einer guten BDD-API zu verwenden, da ich damit sehr einfach zu lesenden und dennoch hochgradig granularen Code erstellen konnte. Ich kann aus einer minimalen Anzahl wiederverwendbarer Methoden eine Testsuite erstellen und meine Tests in der Sprache der Spezifikationen beschreiben. Auf diese Weise komme ich einem stärker komponentenbasierten Entwicklungsansatz nahe, abgesehen von der Tatsache, dass ich für das Entwerfen und Überprüfen der Bausteine ​​verantwortlich bin. Darüber hinaus zeigt der Testausgang den genauen Teil des Tests an, an dem der Fehler auftritt, sodass ich nicht erraten muss, ob die Fehler im Setup oder in der Behauptung liegen.

Das Optimieren Ihrer Methodik hilft ebenfalls. Ich bin ein großer Verfechter der Anwendung von Lean Development-Prinzipien und deren Kombination mit vielen anderen Techniken und Prinzipien, mit denen sich die Agile-Bewegung seit vielen Jahren beschäftigt. Die meisten der verschwenderischen Praktiken, die ich früher als so frustrierend empfunden habe, zu eliminieren, hat mir sehr geholfen, die Entwicklung zu einer angenehmeren Aktivität zu machen. Ich habe immer noch das Problem, dass manchmal - aber hoffentlich nicht zu oft - Fehler in meinem Code auftreten. Jetzt habe ich jedoch mehr Zeit und noch mehr Ansporn, mehr Zeit damit zu verbringen, robustere Tests zu schreiben und 100 anzustreben % Testabdeckung. Noch besser, es fühlt sich wirklich toll an, all diese grünen Lichter am Ende meines Tages zu sehen.

S.Robins
quelle
Ich bin neugierig, Sie schreiben, dass Testen wichtig ist, aber auch nervenaufreibend.
Nathan Farrington
@ NathanFarrington Vielen Dank für den Hinweis. Mein Ziel war es, positiv über das Testen zu sprechen, aber ich habe darüber nachgedacht, während ich etwas anderes geschrieben habe, also kam es in diesem Absatz völlig falsch heraus! Ich habe korrigiert, um dem tatsächlichen Punkt zu entsprechen, den ich zu beleuchten versuchte!
S.Robins
3

Eine meiner größten Frustrationen mit Software ist, dass sie niemals "gemacht" wird. Es gibt immer eine weitere Funktion, die hinzugefügt werden muss.

Wenn Sie das frustriert, ziehen Sie eine andere Karriere in Betracht. Ernst.

Der Sinn der Software ist es, Funktionen hinzufügen zu können. Der ganze Grund für die Erfindung von "Software" war, dass wir Funktionen hinzufügen konnten.

Oft führt das Hinzufügen einer Funktion zu einem Fehler an einer anderen Stelle, der zuvor einwandfrei funktioniert hat.

Das ist ein QA-Problem.

Dies ist bei Hardware nicht der Fall, solange die Schnittstellen nicht verletzt werden.

Das gilt auch für Software.

Gibt es eine gute Softwareentwicklungsmethode, mit der immer Fortschritte erzielt und neue Funktionen hinzugefügt werden können, ohne dass vorhandener Code neu geschrieben und neue Fehler eingeführt werden müssen?

Ja. Sie müssen tatsächlich die Qualitätssicherung üben.

S.Lott
quelle
1
Ich versuche übrigens nicht zu trollen, und ja, vielleicht bin ich nicht für Software geeignet. Aber Sie sagen, der "Sinn der Software ist es, Funktionen hinzufügen zu können." Ist das wirklich? von Neumann hat die Software erfunden, um einen Computer zu bauen, der mehr als eine mathematische Funktion berechnen kann, ohne seine logischen und arithmetischen Einheiten neu zu verdrahten. Ich bin gespannt, woher diese Software-Feature-Philosophie kommt. Hardware verfügt über Funktionen, aber der Zweck der Hardware besteht nicht darin, Funktionen hinzuzufügen.
Nathan Farrington
Unter Qualitätssicherung verstehe ich das Testen. Ja, meine Intuition besagt, dass umfangreiche Tests erforderlich sind, um Qualitätssoftware herzustellen. Aber ich denke, es geht darüber hinaus. In der Hardware kann ein Modul einen Fehler enthalten. Wenn Sie jedoch neue Hardware hinzufügen, führt dies nicht zu neuen Fehlern in einem vorhandenen Hardwaremodul. Schließlich können alle Fehler in allen Modulen gefunden und behoben werden. Aber in der Software wird häufig Code geändert (Module werden geändert), anstatt hinzugefügt, was zu Fehlern führen kann. Ich habe nach einer Softwareentwicklungsmethode gesucht, die rein additiv ist.
Nathan Farrington
Ich habe jetzt einen intelligenteren Kommentar zu Ihrer Antwort. Der Grund, warum ich befürchtet habe, dass Software niemals "fertig" ist, ist wahrscheinlich, dass ich bei Releases immer einen sehr lockeren Ansatz gewählt habe. Eine neue Funktion ist gleichbedeutend mit der nächsten Version, ohne Regressionstests und mit sehr geringer Qualitätssicherung. Wenn Releases eine GROSSE SACHE wären, dann wette ich, dass meine Beherrschung, dass Software niemals fertig wird, verschwinden würde.
Nathan Farrington
@ NathanFarrington: Turing hat Software erfunden, um die sich ständig ändernden Enigma-Codes zu brechen. "Mit Qualitätssicherung meinen Sie Testen". Falsch. Ich meine Qualitätssicherung - jeder Aspekt der Entwicklung sollte Qualitätsstandards haben, die eingehalten werden sollten. Testen ist eine (eingeschränkte) Möglichkeit, die Qualität einer Art von Artefakten zu bewerten. msgstr "Code wurde geändert ... was zu Fehlern führen kann". Richtig. Das ist ein Fehler in der Qualitätssicherung - kein inhärentes Merkmal von Software.
S.Lott
Wir kommen definitiv vom Thema ab. Laut diesem Link war Turings Colossus nicht universell (im Computersinne) und verwendete keine gespeicherten Programme (Software).
Nathan Farrington
2

Ist es möglich, Software auf ähnliche Weise zu schreiben, wie Hardware "geschrieben" wird? Gibt es eine gute Softwareentwicklungsmethode, mit der immer Fortschritte erzielt und neue Funktionen hinzugefügt werden können, ohne dass vorhandener Code neu geschrieben und neue Fehler eingeführt werden müssen?

Ich empfehle Ihnen, sich mit " formalen Methoden " zu befassen, um die Richtigkeit von Designs und Software zu überprüfen. Die Simulator-Tools, die Sie für das Hardware-Design verwenden, versuchen, etwas Nahes zu tun. Ich glaube nicht, dass Tools für formale Methoden derzeit in der Industrie von Nutzen sind, und die einzigen Branchen, die einen starken Anreiz haben, fehlerfrei zu sein, sind Avionik und Medizin (interessanterweise sagt die FDA eindeutig, dass "Software anders ist von Hardware "auf diesem Link). Wenn Sie mit Verilog / VHDL entwickeln, bleiben Sie außerdem bei der Binärlogik. Dies reduziert die Komplexität drastisch. Es wird keine Hardware geben, die einem Jahr-2000-Problem entspricht.

Das große Problem ist, dass die Dinge komplex sind. Und Sie können Komplexität nicht beseitigen, Sie können sie nur bewegen.

Tangurena
quelle
1

Es ist möglich, Hardware zu schreiben, die "fertig" ist und niemals modifiziert werden muss: Sie definieren die Schnittstellen und die Funktionalität, schreiben einen Prüfstand, implementieren das Hardwaremodul und testen es dann mit einem Simulator. Dann können Sie sich darauf verlassen, dass dieses Hardwaremodul ein Baustein ist, um etwas Größeres und Besseres zu erstellen: Wenn Sie diesem Modul ein Feature hinzufügen müssen, erstellen Sie ein zweites Modul und fügen die Funktionalität dort hinzu. Sie werfen das Originalmodul niemals weg, da es einwandfrei funktioniert und dennoch nützlich sein kann.

In der Software-Welt nennen wir dieses "Modul" eine Bibliothek und verwenden es genauso. Viele Bibliotheken sind so aufgebaut, dass sie gut funktionieren, und erledigen ihre Arbeit zufrieden und unverändert, bis etwas Wichtiges zur nächsten Überarbeitung führt. Betrachten Sie sie als Software, die mit Epoxidharz vergossen wurde :-)

Eine meiner größten Frustrationen mit Software ist, dass sie niemals "gemacht" wird. Es gibt immer eine weitere Funktion, die hinzugefügt werden muss. Oft führt das Hinzufügen einer Funktion zu einem Fehler an einer anderen Stelle, der zuvor einwandfrei funktioniert hat. Dies ist bei Hardware nicht der Fall, solange die Schnittstellen nicht verletzt werden.

Hogwash. Vielleicht sind Sie persönlich besser als viele andere Leute ohne Lötkolben, aber ich habe eine Reihe von schlechten Schaltungsdesigns gesehen, bei denen die Chips versagten ( z. B. das berühmte Intel "f00f" -Problem), aber das tut es nicht Sprich mit dem ganzen Feld. Und da faux-hard ware "weicher" wird, werden die Probleme schwieriger zu verhindern.

Ist es möglich, Software auf ähnliche Weise zu schreiben, wie Hardware "geschrieben" wird? Gibt es eine gute Softwareentwicklungsmethode, mit der immer Fortschritte erzielt und neue Funktionen hinzugefügt werden können, ohne dass vorhandener Code neu geschrieben und neue Fehler eingeführt werden müssen?

Ja. Wir wenden diese Methoden nur selten an. Sie sind in der Regel extrem teuer in der Bedienung, und die meisten Programmierer arbeiten nicht gern im Rahmen ihrer Beschränkungen. Aber wenn es zum Beispiel um menschliches Leben geht, versuchen wir, die Benutzer nicht zu töten.

Ein letzter Punkt: Software hat ein anderes Finanzmodell als Hardware, sogar programmierte Hardware. Die meisten Nicht-Konsumenten-Softwareprodukte und einige Konsumenten-Softwareprodukte werden auf eine Weise verkauft, die Veränderungen fördert. Wenn Sie einem Unternehmen sagen "Zahlen Sie uns jetzt 10.000 USD plus 18% pro Jahr", können Sie das Produkt im Wesentlichen alle paar Jahre weiterverkaufen. Um diese Gebühr zu rechtfertigen, müssen Sie dem Kunden die gewünschten Änderungen mitteilen. Hmm ... wenn man an die Hardware-Obsoleszenz-Kurve von Apple denkt, ist das vielleicht doch kein Unterschied - Hardware bringt Sie nur dazu, es wirklich neu zu kaufen!

Ross Patterson
quelle
Ich habe nie gesagt, dass ich besser bin als jeder andere. ;-) Wenn Hardware einen Bug hat, wird es neu. Wenn Software einen Fehler aufweist, ummm, wartet, dass die Software immer Fehler aufweist. Welche Methoden verwenden wir nicht, weil sie zu teuer sind und keinen Spaß machen?
Nathan Farrington
0

Wie kann ich mehr Spaß beim Schreiben von Software haben, indem ich keine Fehler in den Arbeitscode einführe und immer Fortschritte mache?

Ich würde gerne eine endgültige Antwort auf Ihre Frage finden. Die Realität ist jedoch, dass es keinen einfachen Weg gibt, weshalb extreme Programmier- und TDD-Techniken immer beliebter werden. Sie müssen sich auf Veränderungen einstellen, denn das wird passieren. Ich weiß nicht, ob es auf diese Weise lustiger ist, aber auf jeden Fall viel weniger stressig ;-)

http://en.wikipedia.org/wiki/Extreme_Programming

Wenn Sie mit Hardware interagieren, benötigt die Hardware einen x-Wert und das ist alles (theoretisch), aber wenn Sie mit Menschen heutzutage interagieren, brauchen sie x und morgen können sie y usw. Es ist so, wie es ist, Bussines und Menschenanforderungen ändern sich . Weil Personen! = Maschinen, ist Code, der sich die meiste Zeit NIE ändert, nicht möglich.

Versuchen Sie auch, wie in meiner vorherigen / gelöschten Antwort erwähnt, Änderungen zu vermeiden, die nicht wichtig sind, indem Sie die Leute zum Nachdenken anregen, bevor Sie mit dem Codieren beginnen. Binden Sie die Benutzer stärker in die Entscheidungsfindung ein usw. Klären Sie die Kosten für Änderungen, planen Sie mehr usw. Dies sind keine "Codierungsmethoden", sondern Methoden zum "Nicht-Codieren", da bei mehr Anforderungen weniger Änderungen vorgenommen werden und mehr Spaß gemacht wird.

H27studio
quelle
1
Gute Antwort. Ich habe Extreme Programming gemacht. Es scheint genau das Gegenteil von dem zu sein, wonach ich gesucht habe, wobei sich die gesamte Projektrichtung je nach Wunsch des Kunden wöchentlich ändern kann. Ich bin nicht gegen iterative Veröffentlichungen, ich möchte nur nicht, dass die 2. Version Fehler einführt, die in der 1. Version nicht vorhanden waren. Und Sie haben Recht, dass durch das Design von vornherein auf lange Sicht Aufwand gespart werden kann.
Nathan Farrington
Wie ich immer sage, ist der beste Code kein Code. :-)
H27studio
0

Ist es möglich, Software auf ähnliche Weise zu schreiben?

Ja ist es. Seien Sie genauso vorsichtig, als ob Sie Hardware entwickeln, testen Sie alles, was Sie können, und Ihre Software wird von ähnlicher Qualität sein.

Übrigens, haben Sie noch nichts von HW-Fehlern gehört? Viel schlimmer als jeder SW-Fehler und schwerer zu beheben (nicht nur das Aktualisieren der Software)

BЈовић
quelle
1
Ja, Hardware hat auch Fehler, sogar ausgereifte Hardware wie Prozessoren. Gute Hardware ist so konzipiert, dass die Hardware-Fehler in der Software behoben werden können! Der Grund für meine ursprüngliche Frage ist, dass ich viel Software geschrieben habe, aber ich war immer bestürzt darüber, wie einfach es ist, Fehler einzuführen und wie chaotisch das System insgesamt war. Ich bin ein aufgeräumter Mensch, daher erschien mir die Hardware-Entwicklungsmethode immer natürlicher. Es könnte auch etwas mit dem Geltungsbereich zu tun haben.
Nathan Farrington
1
@ NathanFarrington Die Software ist normalerweise komplexer als eine HW. HW wird eingehender getestet. SW kann sich leichter ändern, daher neigen die Leute dazu, nicht so viel Aufmerksamkeit zu schenken.
BЈовић
0

Ich möchte auch darauf hinweisen, dass Softwarefehler in der Hardware oft Menschen töten können. Es wird daher mehr Wert darauf gelegt, die Anforderungen genau zu bestimmen und sie vorab ausgiebig zu testen. Und diese Anforderungen müssen sich erst ändern, wenn die Hardware dies tut. Und da für neue Hardware möglicherweise ein Umschreiben erforderlich ist, wird die Cruft vermutlich auch nicht so stark aufgebaut.

Geschäftsanforderungen ändern sich hingegen ständig, manchmal kann man kaum eine Anforderung in die Produktion bringen, bevor eine Änderung verlangt wird. Manchmal wurde die Anforderung mehrmals geändert, bevor sie in Produktion geht. Dies ist eine Folge mehrerer Dinge. Erstens ist der Projektbeteiligte auf der Unternehmensseite oft weniger daran interessiert, die Zeit zu verbringen, um genau zu definieren, was er will, weil er "beschäftigt" und "wichtig" ist und die Menschen nicht sterben und die Familien ihn verklagen oder ihn ins Gefängnis werfen, wenn er bläst seinen Teil des Prozesses ab. Zweitens haben die Projektbeteiligten in der Regel eine bessere Vorstellung davon, was die Hardware tun soll, da sie für sie weniger abstrakt ist. Sie wissen wirklich nicht, was sie wollen, bis sie es sehen. Welches ist weniger ein Problem mit Hardware.

HLGEM
quelle
Sie haben einen gültigen Punkt. Die Arten von Dingen, die wir traditionell in der Hardware herstellen, sind gut bekannt: Prozessoren, USB-Controller, PCI Express-Endpunkte, Speichercontroller usw. Dann übertragen wir die gesamte Geschäftslogik dieser Anwendung in die Software. Vielleicht werden die Dinge beim Hocharbeiten des Software-Stacks unordentlicher und weniger gut verstanden?
Nathan Farrington
-1

Es gibt hochrangige Werkzeuge mit vielen fertigen "Bausteinen", wie Sie sie nennen, die Sie zu Anwendungen kombinieren können. Die Steine ​​sind fertige Teile, die Sie verwenden können. Sie müssen sie nur miteinander kombinieren. Vielleicht denken Sie, dass das einfacher ist ... bis Ihr Kunde Sie nach seltsamen und unerwarteten Änderungen fragt.

AndSoYouCode
quelle