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

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?

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

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 .

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.

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.

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.

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.

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!

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.

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)

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.

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.