it-swarm.com.de

Warum glauben einige Programmierer, dass es einen Kontrast zwischen Theorie und Praxis gibt?

Beim Vergleich von Software-Engineering mit Tiefbau war ich überrascht, eine andere Denkweise zu beobachten: Jeder Bauingenieur weiß, dass man, wenn man eine kleine Hütte im Garten bauen möchte, einfach die Materialien holen und sie bauen kann, während man bauen möchte In einem 10-stöckigen Haus (oder z. B. this ) müssen Sie einige Berechnungen durchführen, um sicherzugehen, dass es nicht auseinander fällt.

Im Gegensatz dazu finde ich beim Sprechen mit einigen Programmierern oder beim Lesen von Blogs oder Foren oft eine weit verbreitete Meinung, die mehr oder weniger wie folgt formuliert werden kann: Theorie und formale Methoden sind für Mathematiker/Wissenschaftler, während es beim Programmieren mehr darum geht, Dinge zu bekommen fertig.

Was hier normalerweise impliziert wird, ist, dass Programmieren etwas sehr Praktisches ist und dass, obwohl formale Methoden, Mathematik, Algorithmus-Theorie, saubere/kohärente Programmiersprachen usw. interessante Themen sein können, sie oft nicht benötigt werden, wenn man nur will erledige Dinge .

Nach meiner Erfahrung würde ich sagen, dass Sie, obwohl Sie nicht viel Theorie benötigen, um ein 100-Zeilen-Skript (die Hütte) zusammenzustellen, für die Entwicklung einer komplexen Anwendung (das 10-stöckige Gebäude) ein strukturiertes Design benötigen -definierte Methoden, eine gute Programmiersprache, gute Lehrbücher, in denen Sie nach Algorithmen suchen können usw.

IMO (die richtige Menge an) Theorie ist also eines der Werkzeuge, um Dinge zu erledigen .

Meine Frage ist, warum einige Programmierer glauben, dass es einen Kontrast zwischen Theorie (formale Methoden) und Praxis (Dinge erledigen) gibt.

Wird Software Engineering (Bausoftware) von vielen als einfach im Vergleich zu beispielsweise Tiefbau (Bau von Häusern) wahrgenommen?

Oder sind diese beiden Disziplinen wirklich unterschiedlich (abgesehen von unternehmenskritischer Software ist ein Softwarefehler viel akzeptabler als ein Gebäudefehler)?


Ich versuche zusammenzufassen, was ich aus den bisherigen Antworten verstanden habe.

  1. Im Gegensatz zum Software-Engineering ist im Tiefbau viel klarer, wie viel Theorie (Modellierung, Design) für eine bestimmte Aufgabe benötigt wird.
  2. Dies ist teilweise auf die Tatsache zurückzuführen, dass das Bauingenieurwesen so alt wie die Menschheit ist, während es das Software-Engineering erst seit einigen Jahrzehnten gibt.
  3. Ein weiterer Grund ist die Tatsache, dass Software eine volatilere Art von Artefakt ist, mit flexibleren Anforderungen (es kann zum Absturz kommen), unterschiedlichen Marketingstrategien (gutes Design kann geopfert werden, um sie schnell auf den Markt zu bringen) usw.

Infolgedessen ist es viel schwieriger zu bestimmen, welche Menge an Design/Theorie in der Softwareentwicklung angemessen ist (zu wenig -> unordentlicher Code, zu viel -> ich kann nie fertig werden), da es keine allgemeine Regel gibt und nur (viel) Erfahrung kann helfen.

Wenn ich also Ihre Antworten richtig interpretiere, trägt diese Unsicherheit darüber , wie viel Theorie wirklich benötigt wird, zu den gemischten Liebes-/Hassgefühlen bei, die einige Programmierer gegenüber der Theorie haben.

63
Giorgio

Ich denke, der Hauptunterschied besteht darin, dass die Physik der realen Welt beim Bauingenieurwesen als konstante, leistungsstarke Realitätsprüfung fungiert, die die Theorie vernünftig hält und auch schlechte Praktiken einschränkt, während es in der Softwareentwicklung keine ebenso starke Kraft gibt, unpraktische Elfenbeinturmkonzepte beizubehalten als miese Verarbeitung in Schach.

Viele Programmierer haben schlechte Erfahrungen damit gemacht, dass die außer Kontrolle geratene Theorie ein aktives Hindernis für die Erledigung von Aufgaben darstellt (z. B. "ausführbare UML", super-bürokratische Entwicklungsprozesse). Umgekehrt können schmutzige Hacks und Patches dich verdammt weit bringen, wenn auch am Ende langsam. Und wie Sie in Ihrem letzten Absatz bemerken: Fehler sind normalerweise nicht so endgültig und daher nicht so problematisch.

61

Software Engineering und Tiefbau haben wenig gemeinsam. Der Tiefbauaufwand wird durch die physikalischen Eigenschaften ihrer Materialien und der Umwelt begrenzt. Bauingenieure verbringen viel Zeit damit, sich über Bodeneigenschaften und Materialeigenschaften zu informieren. Die Softwareentwicklung ist physisch nur durch die Geschwindigkeit der Prozessoren und den verfügbaren Speicher begrenzt. Beide sind leicht zu verstehen und wir verbringen nicht viel Zeit damit, sie zu studieren. Die Hauptbeschränkung für die Softwareentwicklung ist der menschliche Intellekt. Und keine zwei Entwickler sind gleich. Ist dieser Code wartbar? Von wem? Eine dreizeilige Implementierung von Quicksort in Haskell mag für einige offensichtlich korrekt sein, für andere jedoch unverständlich. Ein Team von zwei Personen kann einen Antrag in einem Monat ausfüllen, während ein anderes Team von zehn Personen Schwierigkeiten hat, innerhalb eines Jahres zu liefern.

Softwareentwicklung ist alles Design, die Artefakte, die entworfen werden, sind um Größenordnungen komplexer als jeder hergestellte Artikel, und jeder ist einzigartig.

29
kevin cline

Als mehr oder weniger ehrlicher Maschinenbauingenieur (mit einigen zivilen) wurde er Programmierer, dann CS (AI) PhD, dann Lehrer, dann wieder Programmierer (entschuldigen Sie, Software Engineer ), ich habe eine Schimpfe über dieses allgemeine Thema.

In der traditionellen Technik

  • du musst deine Mathematik und Naturwissenschaften kennen, weil alles, was du tust, darauf basiert
  • die "Helden" auf dem Gebiet sind Menschen, die neue Dinge erfinden, neue Ideen entdecken und Probleme lösen, die als unlösbar gelten

Es gibt eine "Physik", die für Software gilt - Informationstheorie, aber Softwareentwickler sind wenig damit vertraut, und sicherlich wird nichts angewendet. Die meiste Theorie, die sie bekommen, ist Berechenbarkeit und Big-O.

Außerdem bin ich immer wieder erstaunt über Leute, die denken, dass Programmieren genug ist und sie das Thema ihrer Programme nicht verstehen müssen .

Erfindungsreichtum wird nicht gefördert. Es wird davon abgeraten, Gruppendenkmethoden mit dem kleinsten gemeinsamen Nenner zu verwenden, die als "Lesbarkeit" getarnt sind. (Stellen Sie sich vor, Luftfahrt- oder Nuklearingenieure würden ermutigt, nichts zu tun, was für ihre Nachwuchskollegen schwer zu verstehen sein könnte.)

Die Dinge, die sie lernen, wie das Programmieren von Web-Apps, sind von großem Wert. So ist die Fähigkeit eines Klempners oder Elektrikers, aber es ist keine Technik.

17
Mike Dunlavey

Wenn ich bei den meisten Software eine Ecke abschneide und etwas mache, das nicht das beste Design ist, aber die Arbeit erledigt, wird niemand sterben. Es ist der gleiche Grund, warum eine Hütte im Garten nicht die gleichen Standards benötigt wie ein 10-stöckiges Gebäude. Ich kann jedoch eine sehr große App wie Facebook erstellen, und wenn sie Fehler macht und Daten verliert oder was auch immer, ist das keine große Sache. Es ist auch einfacher, das Fundament einer großen App nachträglich zu reparieren, als das Fundament eines 10-stöckigen Gebäudes zu ersetzen. Alles hängt vom Kontext und der Berechnung des Risikos ab.

Ich kann auch sicher und einfach weiter zu einer App hinzufügen. Sie können nicht einfach in einen neuen dritten Stock eines 10-stöckigen Gebäudes werfen (also 11). Ich kann einer großen App jeden Tag eine neue Funktion hinzufügen, wenn ich möchte.

Gutes Design erleichtert das Programmieren. Aber mit schlechtem Design ist es nicht unmöglich, und die Risiken sind ... fehlerhafte Software. Normalerweise nicht der Tod.

13
CaffGeek

Tragen Sie mit mir auf diesem. Ich habe einen Punkt.

Ein Professor hat mir einmal gesagt, dass Zaudern zu Zögern führt, obwohl sich die meisten Leute nach einer Nacht voller Papierschreiben/Pauken/Programmieren sagen: "Ich werde das nie wieder tun. Das nächste Mal werde ich früh anfangen und früh fertig werden. " In meiner Erfahrung als vollendeter Zauderer habe ich festgestellt, dass dies wahr ist, und hier ist die Erklärung des Professors, warum: Egal wie unangenehm die Erfahrung des Zauderns ist, in den meisten Fällen werden Sie fertig, wenn Sie einen relativen Erfolg erzielt haben. Dies ist ein Verhalten mit hohem Risiko und hoher Belohnung. Nach einer Weile vergessen Sie all die Unannehmlichkeiten und erinnern sich nur noch an die Belohnung. Daher ist die nächste Versuchung, etwas aufzuschieben, umso verlockender, als Sie das letzte Mal erfolgreich waren.

Ich denke, hier kann eine Analogie zu der Programmiertechnik "Dinge erledigen" gemacht werden, die wir allzu oft sehen. Ein Programmierer oder ein Team von Programmierern, möglicherweise aus Unwissenheit, Faulheit oder aus Zeitgründen, nimmt den Ansatz "Dinge erledigen" beim Programmieren und wirft all Ihre Theorie, Mathematik und bewährten Praktiken aus dem Fenster. Und weisst du was? Sie erledigen Dinge. Es ist nicht elegant, hübsch oder wartbar, aber es erledigt den Job. Vielleicht gibt ihnen ein nicht-technischer Vorgesetzter, der kein Semikolon aus einem Semaphor kennt, ein großes Lob dafür, dass er "Dinge erledigt". Wenn der Programmierer das nächste Mal versucht ist, diesen lockeren Programmieransatz zu wählen, ist dies umso einfacher, als es beim letzten Mal funktioniert hat, nicht wahr? Es ist der "einfache" Ausweg, es sei denn, Sie sind die arme, unglückliche Seele, die eine solche Anwendung Jahre später erbt und sie pflegen muss.

Ich war diese arme, unglückliche Seele und wahrscheinlich auch viele von Ihnen. Ich flehe euch alle an. Nehmen Sie nicht den einfachen Ausweg! :) :)

11
FishBasketGordo

Ihre Prämisse ist fehlerhaft. Der Hauptgrund, warum Bauingenieure bei der Planung großer Gebäude, Brücken, Tunnel usw. Ingenieurwesen einsetzen, besteht darin, sicherzustellen, dass sie eine Mindestmenge an Material (Beton, Baustahl usw.) verwenden, die den erforderlichen Sicherheitsstandards entspricht. Es ist durchaus möglich, ein hohes Gebäude ohne viel Mathematik zu bauen (z. B. die Pyramiden der alten ägyptischen und Maya-Zivilisationen), wenn die Material- und Arbeitskosten keine Rolle spielen, aber wenn sie einmal gebaut sind, macht es normalerweise keinen Sinn, sie zu ändern sie, damit sie Material effizienter nutzen können.

Es gibt eine etwas andere Dynamik beim Entwerfen großer Softwaresysteme. Wenn überhaupt, sind sie normalerweise zu wenig geplant. Dies liegt jedoch daran, dass das Design im Verlauf der Arbeiten dynamisch geändert werden kann, was bei Tiefbauprojekten einfach nicht so einfach möglich ist.

Der gemeinsame Faktor sind die Kosten. Das Design eines traditionellen Tiefbauprojekts reduziert die Kosten (sowohl tatsächlich in Bezug auf Material als auch in Bezug auf das Haftungspotenzial), während es in der Softwareentwicklung einen Punkt gibt, an dem die Kosten für Design über den zurückgegebenen Wert hinaus steigen.

9
James McLeod

Ich möchte auch darauf hinweisen, dass die Menschheit neben einigen anderen hervorragenden Antworten seit der Zeit der Ägypter das Äquivalent von "Tiefbau" getan hat, so dass wir viel Zeit hatten, die allgemeine Theorie zu perfektionieren, wie die Dinge sein sollten getan werden. Wir entwickeln seit ungefähr 70 Jahren Software (je nachdem, was Sie als erste "Software" betrachten). Ich meine, wir hatten nicht die gleiche Zeit, um die gleiche Art von Erfahrung zu entwickeln.

7

Die Pläne eines Architekten/Bauingenieurs sind praktisch nie identisch mit den Plänen "wie gebaut". Etwas ändert sich IMMER. Warum? Weil es "unbekannte Unbekannte" gibt und immer geben wird. Es gibt Dinge, die Sie kennen und die Sie planen können, Dinge, die Sie kennen, die unbekannt sind und die Sie recherchieren und schätzen können, und dann gibt es Dinge, von denen Sie nicht wissen, dass Sie sie nicht kennen. "Überraschungen". Sie möchten diese in den meisten Systemen beseitigen, indem Sie alles lernen, was Sie können, aber alles, was Sie tun müssen, ist eine kleine Verletzung der Bauvorschriften (die möglicherweise auf einer Regel basiert, die vor 2 Jahren bei der Konzeption Ihres Gebäudes nicht existierte) und alles -umfassender Masterplan muss sich ändern, manchmal ziemlich drastisch.

Software ist sehr ähnlich; Es gibt immer ein unbekanntes Unbekanntes. Im Gegensatz zum Bau- oder Hochbau ist die Softwareentwicklung jedoch aufgrund der Probleme, die durch unbekannte Unbekannte entstehen, wesentlich toleranter gegenüber Änderungen. Wenn Sie ein 10-stöckiges Gebäude bauen und die Tragfähigkeit des Fundaments, das Sie in Ihren Entwurf eingefügt haben, überschätzt haben, können Sie das Gebäude entweder nicht auf 10 Stockwerke bauen oder Sie müssen einen erheblichen Arbeitsaufwand aufbringen Gehen Sie zurück zum Fundament und verstärken oder bauen Sie es wieder auf. Wenn Sie jedoch in der Software die Anforderungen an eine bestimmte Ebene der gesamten Lösungsstruktur unterschätzt haben, gibt es viele Optionen zum Beheben dieser Ebene, bei denen nicht alle anderen Arbeiten ungültig gemacht werden. Sie können einen einzelnen DB-Server durch einen leistungsstärkeren oder einen Replikations-/Failover-Cluster oder einen Lastausgleichs-/verteilten Cluster ersetzen. Gleiches gilt für den Webserver. Wenn Sie einen Algorithmus codiert haben, der ineffizient, aber einfach ist und auf fehlerhaften Annahmen zur Eingabegröße basiert, können Sie die Implementierung fast immer einfach auf relativ chirurgische Weise entfernen und neu schreiben, ohne anderen Code zu beeinflussen, der den Algorithmus kennt (Aufrufe und Weitergabe an es oder erwartet eine Ausgabe davon).

Diese relative Leichtigkeit der Änderung ermöglicht es einem Softwareentwickler, basierend auf dem, was er weiß, zu codieren, ohne sich übermäßig Gedanken darüber zu machen, was er nicht weiß. Dies ermöglicht eine lockere Anwendung der Theorie und ein vorzeitiges Konzeptdesign. Sie tauchen ein und erledigen es, und auf dem Weg finden Sie die Dinge, die Sie codiert haben und die sich ändern müssen, und ändern sie. Sie müssen die Konzepte und die Theorie noch kennen, denn wenn ein Problem aufgedeckt wird, helfen Ihnen diese Dinge, die Ursache zu identifizieren und eine Lösung zu finden. Sie dürfen jedoch eine schnelle Entscheidung treffen, ohne einer "Analyse-Lähmung" zu erliegen, denn wenn sich herausstellt, dass Sie die falsche Entscheidung getroffen haben, basierend auf etwas, das Sie nicht kannten oder bei Ihren "Berechnungen" nicht berücksichtigt haben Fehler ist leichter zu korrigieren.

6
KeithS

Der Unterschied ist hauptsächlich auf die bekannten Anforderungen zurückzuführen:

  • Auf der theoretischen Seite wird alles im Voraus definiert, sodass Sie genau wissen, was Sie benötigen, bevor Sie beginnen.
  • In der Praxis sind sie oft nicht alle vorhanden, oder Sie entdecken mitten in der Implementierung etwas, das dazu führt, dass Sie etwas neu entwerfen müssen. Es ist also viel besser, mit zumindest rudimentären Designs zu springen, damit Sie diese Probleme frühzeitig erkennen können.

Wenn man von "Theorie" spricht, bedeutet dies normalerweise eher die theoretische Seite der Informatik als die Softwareentwicklung. Dies ist der Teil der Informatik, in dem es hauptsächlich darum geht, bessere und effizientere Algorithmen zu finden, zu beweisen, ob etwas möglich ist oder nicht (z. B. P und NP) und so weiter. Es ist zwar gut, diese im Hinterkopf zu haben, aber sie kommen in der Softwareentwicklung nicht sehr oft vor.

Wir benutzen Bibliotheken so oft wie möglich.

5
Izkata

Es gibt tatsächlich einige Ebenen der Softwareentwicklung, je nachdem, was die von Ihnen erstellte Software tut.

Die NASA benötigt Software zur Steuerung bemannter Shuttles im Weltraum, sodass der Entwicklungsprozess natürlich viel strenger ist als der Aufbau einer Website zur Darstellung von Raketenbildern.

Einer meiner Mitarbeiter, der für die NASA gearbeitet hat, beschrieb seinen Software-Engineering-Prozess zuvor als das Schreiben von Hunderten von Begründungsseiten und Hunderten von Stunden von Besprechungen, um das Schreiben einer einzelnen Codezeile zu rechtfertigen!

Versteht mich nicht falsch, weil ich nicht versuche, respektlos zu klingen, wenn ich das sage, aber selbst nach all den Kosten für Zeit, Ressourcen und Milliarden von Dollar ist das Space Shuttle immer noch in die Luft gesprengt.

Sogar Bauingenieure wissen, dass, egal wie viel Theorie sie in ein Design stecken, etwas es irgendwann brechen wird, also müssen sie auch Notfallpläne entwickeln.

Wenn Sie Software erstellen, verursachen die Kosten eines Absturzes selten Todesfälle. Daher ist es viel einfacher, Dinge schnell wegzuwerfen und zu testen. Lassen Sie uns zustimmen, dass eine schnelle Erledigung zu schwachem Code führt. Selbst wenn dies immer der Fall ist, ist es für einen Entwickler am besten, Software in Aktion zu sehen, um festzustellen, wo sie schwach ist und stärker gemacht werden muss, wo sie schwach und immer noch um ein Vielfaches stärker ist, als es sein muss, um Schritt zu halten die Ladung.

Um zusammenzufassen, Premature optimization is the root of all evil oder wie mein Chef immer sagen würde Shipping is a feature!

5
Albert Lang

Viele gute Antworten hier, aber ich denke, der Vergleich zwischen Informatik und Bauingenieurwesen ist fehlerhaft.

Genau genommen ist das, was professionelle Softwareentwickler tun, eher Software-Engineering als Informatik. Eine bessere Analogie ist, dass Informatik die Physik für Software Engineering ist. In ähnlicher Weise ist Civil Engieering eine Sammlung von Vereinfachungen und Annäherungen an die Physik, um praktisch Dinge zu bauen.

Ich stelle mir vor, dass Bauingenieure bei ihrer Arbeit selten die allgemeine Relativitätstheorie berücksichtigen müssen. Ein Großteil des Bauingenieurwesens kann sicher in der Newtonschen Mechanik gebaut werden. In ähnlicher Weise kann Software Engineering sehr erfolgreich mit einem ungefähren Verständnis der theoretischen Informatik durchgeführt werden.

Der große Unterschied besteht darin, dass Brücken, Wolkenkratzer und andere Produkte des Bauingenieurwesens einigermaßen gut verstanden werden. Softwareentwickler erstellen häufig neuartige Konstrukte oder verwenden neuartige Methoden, um gut verstandene Dinge zu erstellen. Software Engineering ist weit weniger ausgereift als Civil Engineering, und das wird wahrscheinlich auf absehbare Zeit auch weiterhin so bleiben.

TL; DR: Theorie und Praxis unterscheiden sich in der Softwareentwicklung wie überall sonst. Die richtige Analogie ist Software Engineering: Bauingenieurwesen :: Informatik: Physik. Aber in der Praxis ist es etwas komplexer als das :)

5
ObscureRobot

Meine Frage ist also, warum einige Programmierer glauben, dass es einen Kontrast zwischen Theorie (formale Methoden) und Praxis (Dinge erledigen) gibt.

Das Erstellen von Software unterscheidet sich vom Erstellen einer Brücke. In der Software müssen viele Objekte erstellt werden, die zu Beginn definiert werden können oder nicht. Es gibt Standards, um die Wartung und die Zusammenarbeit der Entwickler zu vereinfachen und nicht um willkürliche mathematische Formeln oder andere solche Ideale einzuhalten. Wenn Sie beispielsweise ein Verhalten basierend auf einer Variablen auswählen, ist es manchmal sinnvoll, einen Schalter zu verwenden, manchmal ein Factory-Muster. Dies hängt von der Wartungsfreundlichkeit und den erkannten Schwachstellen wie Leistungsproblemen ab.

Ein weiteres Beispiel kann die Datenmanipulation sein. Es ist oft sinnvoll, Delegaten im Kontext von .NET zu verwenden. In Java ist dies nicht so einfach, da es nicht die Framework-Unterstützung für den funktionalen Programmierstil von .NET bietet. Mit anderen Worten, im allgemeinen Fall ist es einfach nicht möglich, X in auszuführen Situation Y. Dies liegt an der Tatsache, dass X und Y von N Anzahl variabler Faktoren abhängen.

Wird Software Engineering (Bausoftware) von vielen als einfach empfunden, beispielsweise im Vergleich zum Bauingenieurwesen (Bauen von Häusern)?

Ich bin mir nicht sicher, ob "einfach" der richtige Begriff ist. Ein Mangel an konkreten Beweisen kann zu der Annahme führen, dass keine Arbeit geleistet wird. Oder in ähnlicher Weise kann die vorhandene Arbeit leicht geändert werden.

Oder sind diese beiden Disziplinen wirklich unterschiedlich (abgesehen von unternehmenskritischer Software ist ein Softwarefehler viel akzeptabler als ein Gebäudefehler)?

Traditionelles Engineering und Software Engineering unterscheiden sich aus den bereits genannten Gründen erheblich.

3
P.Brian.Mackey

Ihre Wahrnehmung ist hier möglicherweise falsch oder enthält viele Ressourcen von Personen, die keine ausreichend komplexe Software geschrieben haben.

Ihre Erfahrung stimmt mit dem überein, was die meisten mir bekannten Personen (die ausreichend komplexe Software entworfen und geschrieben haben) sagen würden.

Das heißt, wenn es um die meisten geht Programmierer, wenn die Aufgabe, etwas zu schreiben, sie erreicht, wurde das Design ("die Mathematik", wie Sie es ausdrücken) bereits vom Architekten/Leiter/etc. vor der Aufgabe des Schreibens kommt es zu ihnen. So kann es von der Front-Line-Ebene aus so aussehen.

1
Steven Evers

Ich denke, der Grund für diesen Kontrast ist, dass der Lebenszyklus eines Softwareprojekts und eines Hardware- oder Architekturprojekts unterschiedlich ist. Die meiste Software entwickelt sich schrittweise weiter, sie ist nicht von Anfang bis Ende geplant. Softwareentwickler können einen iterativen Ansatz für die Entwicklung anwenden: Planen, Implementieren und Abhören von Feedback. Wenn das Feedback positiv ist, machen Sie weiter, nicht - treten Sie einen Schritt zurück und überdenken Sie Ihre Strategie. Aus diesem Grund haben Softwareentwickler Dinge wie agile Entwicklung, minimal lebensfähige Produkte und so weiter.

Bauingenieure haben keinen solchen Luxus. Sobald etwas geplant ist, können Sie es nicht mehr so ​​einfach ändern wie mit Software, da die Kosten für solche Änderungen sehr hoch sein können. Für die Softwareentwicklung hingegen kostet es nicht so viel, und dies kann zu ihrem Vorteil genutzt werden.

Aber nicht jeder Zweig der Softwareentwicklung kann sich einen solchen Ansatz leisten. Die Herstellung von Software zum Beispiel für Luftfahrt- oder medizinische Dienstleistungen erfordert eine sehr sorgfältige Planung und viele vorherige Berechnungen.

1
v-star

Mir kommt es genauso vor. Sie bauen ein großes Gebäude aus Standardblöcken, Beton mit Standardfestigkeit und Standardstahl. Sie erstellen eine große App aus Standardbibliotheken.

Sie versuchen nicht, eine große App mathematisch formal korrekt zu beweisen, genauso wie Sie nicht versuchen, die Wellenfunktion für ein 100-stöckiges Gebäude zu schreiben

1
Martin Beckett

Ich war Maschinenbau- und Fertigungsingenieur, bevor ich vor etwa 20 Jahren entdeckte, dass meine Fähigkeiten in Software lagen. Ich sympathisiere mit vielen der Elemente, die Sie dargelegt haben.

Ich vermute, dass die wahre Natur des Problems darin besteht, wie wir Dinge zu erledigen. Wir haben jetzt ungefähr zehn Jahre agile Entwicklung hinter uns, und die Botschaft ist klar. Gehen Sie nicht schichtweise voran. Fortschritt nach Funktionen. Sicher - es wird Projekte geben, bei denen Sie nach Schichten vorankommen müssen (z. B. Erstellen Sie Ihren Netzwerkstapel vor Ihrem Webserver), aber für die überwiegende Mehrheit der realen Projekte haben wir die Lektion gelernt, dass Sie funktionierende Funktionen bereitstellen können, eine oder mehrere Eine Zeit ist viel effektiver, wenn man riesige, noch nicht getestete Theorien aufbaut und dann versucht, sie umzusetzen.

Nehmen wir also Ihr Hüttenbeispiel (ich spreche normalerweise davon, eine Brücke zu bauen, indem ich einen Baumstamm über einen Bach gegen eine kilometerlange Hängebrücke werfe ... was auch immer!) Und bringen Sie ihn in die Welt der Softwareentwicklung. Der Hauptunterschied, den ich sehe, besteht darin, dass der größte Teil der Arbeit in der Software so umfangreich ist, dass keine große Vorabmodellierung erforderlich ist, um erfolgreich zu sein. Der Fehler des Anfängers besteht oft darin, anzunehmen, dass die Dinge mehr davon benötigen als sie tatsächlich tun, und für die meisten von uns, die diesen Fehler einige Male gemacht haben, ist es uns ein Anliegen, ihn zu oft erneut zu machen.

Kein Argument - es gibt Projekte, die mit einem Komitee von 17 Softwarearchitekten beginnen müssen. In Wahrheit sind sie ungefähr so ​​selten wie 20 Karat Diamanten.

1
Dominic Cronin

Ich denke, die Analogie ist fehlerhaft. Soweit mir bekannt ist, hat das Bauingenieurwesen nicht die gleiche theoretische Grundlage wie die Informatik. Die Informatik wurde aus der theoretischen Mathematik geboren - wie Turing-Maschinen. Beim Bauingenieurwesen geht es darum, Strukturen zu schaffen, die der Natur widerstehen und vielleicht sogar schön aussehen. Auch hier weiß ich wirklich nicht viel über Bauingenieurwesen, aber ich glaube nicht, dass es Entsprechungen für Bauingenieure von P gegen NP, dem reisenden Verkäufer und anderen lustigen Dingen gibt, gegen die Sie Ihr Gehirn schlagen können. Und es gibt definitiv einen Platz für unsere Informatik-Theorie - wenn jemand den reisenden Verkäufer oder das Halteproblem löst, stehen wir vor vielen fantastischen neuen Fortschritten. Aber für einen Softwareentwickler, dessen Aufgabe es ist, Software zu entwickeln, sind solche Probleme wirklich nur Spaß und Spiel.

Jetzt denke ich auch, dass es davon abhängt, was Sie unter "Theorie" verstehen. Sprechen wir über Entwurfsmuster oder über das Lemma? Weil ein gutes solides Verständnis der Entwurfsmuster für einen guten Softwareentwickler von entscheidender Bedeutung ist. Bei der Architektur eines großen Softwaresystems ist es jedoch nicht sinnvoll, über P/NP-Probleme zu theoretisieren. In diesem Sinne glaube ich, dass es einen sehr starken Kontrast zwischen Software-Engineering und theoretischer Informatik gibt.

Oder bezieht sich die Theorie auf Algorithmen? Sie verbringen nicht viel Zeit damit, Algorithmen zu schreiben, die Sie in Ihrer Algorithmusklasse gelernt haben. Warum? Weil Sie sie normalerweise nur in bestimmten Fällen benötigen (und dann nachschlagen und recherchieren) oder eine bereits für Sie geschriebene Bibliothek verwenden. Sie müssen keinen weiteren Bayes'schen Klassifikator schreiben. Abstraktion ist ein wichtiges Prinzip in der Informatik. Ich denke, Softwareentwickler lernen in der Regel erst, wie ein Algorithmus funktioniert, wenn sie es brauchen.

Ein weiterer Grund ist, dass es derzeit mehrere beliebte "Get it done" -Softwareentwicklungsmethoden gibt, die effektiv sind. In der agilen Entwicklung erstellen Sie beispielsweise nicht vorher ein gesamtes System. Der Grund dafür ist, dass Sie wissen noch nicht genau, was Sie erstellen - Sie möchten, dass das, was Sie machen, flexibel ist und sich an neue Informationen und Anforderungen anpasst. Wenn Sie alles von Anfang an entwerfen und dann genau das erstellen, wird nicht immer die beste Software erstellt. Es ist jedoch nicht für alles die Lösung. Nehmen wir zum Beispiel an, Sie entwerfen eine verteilte-Computer-Cluster-verrückte-neue Sache. Sie können keine Serviettenskizzen machen und Ihr SCRUM starten.

TL; DR. Ich denke, das Wort "Theorie" ist nicht eindeutig. Traditionell bezieht sich die Theorie auf die theoretischen mathematischen Aspekte der Informatik. Sofern Sie nicht nach neueren Methoden des Rechnens suchen, spielt die theoretische Informatik im täglichen Leben eines Softwareentwicklers größtenteils keine Rolle. Softwareentwickler kümmern sich um Entwurfsmuster und Systemarchitektur. Spezifische Implementierungsdetails bestimmter Algorithmen sind nicht wichtig. Oft ist es bei weniger komplizierten Ideen angebracht, nicht viel zu entwerfen und einfach mit dem Codieren zu beginnen. Und ich denke, hier kommt die Idee her, dass Programmierer Theorie nicht mögen.

1
Jarsen

Die Kluft zwischen Theorie und Praxis ist derzeit zu groß. Wenn Sie Theorie machen, erhalten Sie drei Axiome und es wird anschließend gezeigt, dass ein einzeiliger Satz einen Beweis von tausend Seiten oder gar keinen Beweis hat. In der Softwareentwicklung erhalten Sie inkonsistente APIs mit Tausenden von Funktionen, die Ihnen eine Vielzahl von (schlechten) Methoden zur Implementierung einer nicht spezifizierten Funktion bieten.

Echtes Software-Engineering würde die meisten im formalen Bereich verrückt machen, und echte mathematische Software-Entwicklung würde diejenigen im Engineering-Bereich verrückt machen. Beide Bereiche erfordern Menschen mit unterschiedlichen Fähigkeiten, und ich glaube nicht, dass sich die Fähigkeiten oft überschneiden.

1
Marco Devillers

Die formale Theorie geht davon aus, dass Sie wie ein hergestelltes Produkt alles im Voraus genau planen können, dass Software auf unbestimmte Zeit in derselben Umgebung vorhanden ist und dass die Lösung eines allgemeinen abstrakten Problems immer das Ziel ist. Es wird ein 4D-Software-as-a-Product-Lebenszyklus vorausgesetzt: Entwerfen, Entwickeln, Bereitstellen, Fertigstellen. In der formalen Theorie geht es darum, das Problem des Software-Designs mithilfe von Analyse, Abstraktion, Generalisierung und Vorhersage zukünftiger Veränderungen zu lösen. Dies ist gut, wenn Sie ein genau definiertes Problem in einer einfachen Domäne haben, die leicht zu analysieren, vorhersehbar und ziemlich statisch ist.

Bei der praktischen Programmierung geht es darum, das richtige Problem (nicht das des Software-Designs) jetzt richtig zu lösen, damit Ihre Mitarbeiter ihre Arbeit besser/schneller/überhaupt erledigen können oder Einnahmen in das Unternehmen fließen können. Viel Software ist nicht wie ein Produkt, niemals "fertig", sondern eher wie ein Lebewesen, das hochspezialisiert für eine ökologische Nische beginnt und möglicherweise eine sehr variable Lebensdauer hat, während der es neue, unvorhergesehene Probleme in einem Land lösen muss Vielzahl von sich ständig ändernden Umgebungen. In der Geschäftswelt mit Politik und Rechtmäßigkeit sowie Wettbewerb und sich ständig ändernden Organisationen, Strukturen und Trends sind die Anforderungen häufig mehrdeutig, mit allen Arten von Sonderfällen verwickelt, schlecht definiert und unterliegen schnellen, unerwarteten Änderungen. Sie sind nicht analysierbar, vorhersehbar oder statisch und oft nicht logisch oder vernünftig. Die Software ist in 2 Wochen wahrscheinlich genauso irrelevant wie in 20 Jahren noch in Gebrauch. Es kommt auf die Welt, weiß nicht viel oder kann nicht viel und muss während seines gesamten Lebens gepflegt, gepflegt und geschult werden, um stark, flexibel und in der Lage zu sein, sich an seine sich ständig ändernden Umgebungen und neuen Probleme anzupassen. Wenn Sie es nach der Geburt vernachlässigen, wird es wild, wenn es lange genug überlebt, Schmerzen und Leiden verursacht und Probleme mit stumpfer Gewalt löst.

Die formale Theorie geht nicht auf die Anforderungen vieler realer Unternehmenssoftware ein. Es täuscht uns vor, dass Software entworfen und ausgeführt werden kann. Dass es sich um ein Produkt handelt, das gelegentlich repariert, poliert oder angeheftet werden kann, aber kein Lebewesen, das während seiner gesamten Lebensdauer mit ständiger Sorgfalt und Aufmerksamkeit ordnungsgemäß aufgezogen werden muss. Am Ende haben wir also wirklich hässlichen wilden Legacy-Code, aber die formale Theorie hätte wahrscheinlich nicht geholfen.

Das klingt alles ziemlich negativ, aber in Wirklichkeit liebe ich es, formale Theorie zu verwenden. Ein schönes Design zaubert immer ein Lächeln auf mein Gesicht. Das liegt jedoch hauptsächlich an meiner Hobby-Programmierung, die nicht den Wechselfällen des Geschäfts unterliegt. Bei der Arbeit beschäftige ich mich hauptsächlich mit organischem Code und hoffe nur, dass ich ihm genug Aufmerksamkeit schenken kann, damit er richtig aufwächst, mich stolz macht und nicht unausstehlich und unhöflich gegenüber anderen ist, die damit umgehen müssen.

0
Ray

Die Einsätze sind geringer, die Arbeit ist einfacher und das Management sieht den Wert eines guten Designs selten. Systeminstabilität, Wartbarkeit und Integrität sind ein "IT" -Problem - kein "Business" -Problem. Alle Führungskräfte haben eines gemeinsam. Sie konzentrieren sich entweder zu 95% auf Geld oder sie berichten an jemanden, der es ist.

Der Rest des Kampfes ist mit Ihren Programmierkollegen. Viele von ihnen können oder wollen sich nicht dazu verpflichten, über ein Problem nachzudenken, bevor die Codierung beginnt. Aus den oben genannten Gründen sind viele dieser Mitarbeiter leitende Entwickler, was es noch schwieriger macht, ein gutes Design in die Produktion zu bringen.

Ich habe beobachtet, wie Projektleiter Jahre damit verschwendeten, Ad-hoc-Funktionen und Korrekturen für Projekte hinzuzufügen, die anfangs schwierig waren, und dann jeden Versuch, Ordnung ins Chaos zu bringen, mit Sätzen wie "zu kompliziert" oder "Zeitverschwendung" niederzuschlagen. Es ist nicht angenehm zu beobachten, wie ein Großprojekt zu seinem unvermeidlichen Untergang führt, da das Management nicht zugeben wird, dass es täglich ein eigenes Gefängnis baut. Ich befürchte jedoch, dass es eine unglückliche Realität ist, die viele Entwickler gesehen und - zum Guten oder Schlechten - daraus gelernt haben.

Ich versuche ein Medium in meiner Arbeit zu finden. Ich schreibe nicht mehr Code in "verdorbene" Projekte als unbedingt notwendig, und ich nutze jede Gelegenheit, um die Funktionalität zu verschieben out von ihnen. "Zwischen Projekten" verbringe ich Zeit mit Design und Bereinigung in den Projekten, über die ich tatsächlich die Kontrolle habe.

Am Ende ist es ein großes Durcheinander von Politik und persönlicher Integrität, für das 75% der Programmierer der Welt nicht den Magen haben. Ich kann es selbst kaum ertragen.

0
Daniel

Zuallererst liebe ich diese Frage. Ich habe wie drei 1000-Wort-Antworten geschrieben und sie waren alle schrecklich falsch, als ich am Ende angelangt war.

Das Problem beim Versuch, die beiden als analog zu vergleichen, besteht meiner Meinung nach darin, dass die Programmierung ein Modellierungsprozess ist, der so abstrakt oder eng an Beton gebunden sein kann, wie Sie möchten.

Die Theorie des Bauingenieurwesens ist dagegen eng an sehr spezifische realitätsbasierte Gesetze gebunden, denen Sie entsprechen müssen. Sie können nicht nur den Kontext oder die Gesetze ändern. Das Problem selbst wurzelt in diesen Gesetzen. Bei der Programmierung ändert die Lösung jedoch manchmal tatsächlich die Art der Frage oder stellt sie einfach in einen anderen Kontext.

Ob das MVC-Muster beispielsweise perfekt passt, hat viel mit diesem Kontext zu tun. Eine Desktop-Anwendung behandelt normalerweise nur eine Sprache und eine Sprache, ohne Konfigurationsdateien.

Das Frontend einer Web-App besteht dagegen hauptsächlich aus zwei deklarativen (nicht programmierbaren) Sprachen und JavaScript. Die einzige physische Sache, die Sie nicht vollständig abstrahieren können, ist die Tatsache, dass es immer diese http-Wand gibt, um Dinge zwischen Server und Browser zu verschieben. Unabhängig davon, wie Sie es in Code vergraben, erfordert dies Zeit und asynchrones Design.

Offensichtlich können Sie ein beliebtes und angesehenes Muster wie MVC nicht verwenden, um Front-End-Probleme ausschließlich im Web zu behandeln, ohne die Art und Weise zu ändern, wie Sie es in einem Desktop-App-Kontext behandeln. In der Tat würde ich argumentieren, Sie sollten sich darüber im Klaren sein, was MVC nützlich macht, aber nicht einmal versuchen, es auf besonders genaue oder umfassende Weise zu implementieren. Das Web-App-Paradigma ist insofern einzigartig, als das gesamte Look-at-Me-Material vom Browser des Benutzers verwaltet wird und sich das gesamte daten-/modellbezogene Material normalerweise irgendwo auf dem Server befindet. Aber wo bleibt der Controller? Alles auf dem Server oder alles auf dem Frontend? Jemand muss das besitzen. Oder vielleicht passt MVC nicht zu 100% zum Szenario. Keine schlechte Passform für .NET-Backend-Inhalte. Nicht schrecklich im Kontext bestimmter UI-Widgets. Der Versuch, es aus Gründen der Konsistenz auf alles anzuwenden, könnte jedoch ein schlechter Schachzug sein, IMO.

Der Bau eines Hauses löst ein Problem. Typische Programmierprobleme beinhalten jedoch häufig das Lösen von Problemen innerhalb von Problemen, und manchmal besteht die Lösung darin, das äußere Problem neu zu definieren. Die Realität ist an dieser Idee leider nicht besonders interessiert.

0
Erik Reppen

Glenn Vanderburg bietet einen großartigen Überblick über die Unterschiede zwischen Software-Engineering und traditionelleren Engineering-Disziplinen: http://www.youtube.com/watch?v=NP9AIUT9nos

Wenn ein Bauingenieur seine Entwürfe ohne Kosten testen könnte, bevor er das letzte Ding baut, würde er die Theorie viel weniger nutzen. Wenn er innerhalb von Sekunden tausendmal kostenlos eine Brücke bauen könnte, um zu testen, wann sie brechen wird, würde er dies tun, anstatt Monate damit zu verbringen, zu berechnen, wann sie theoretisch bremsen könnte ...

In der Softwareentwicklung ist das genau das, was Sie tun. Anstatt zu berechnen, wie schnell Ihr Algorithmus theoretisch ist, können Sie ihn einfach testen und die Antwort innerhalb von Sekunden erfahren.

Tatsächlich ist die meiste Software heutzutage nicht mehr durch physische Einschränkungen wie Rechenleistung oder Speicher eingeschränkt. Die Einschränkung von Software ist die Komplexität, die in immer größeren Systemen auftritt. Es bewältigt diese Komplexität, indem es das System für den Menschen verständlich hält, was die große Herausforderung bei der heutigen Programmierung darstellt.

0
mirkok