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

Beim Vergleich von Software-Engineering und Bauingenieurwesen war ich überrascht, dass 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 ein 10-stöckiges Haus (oder, zum Beispiel so etwas wie diese ) Sie ganz ein paar Mathe tun müssen , um sicher zu sein , dass es nicht auseinander fallen.

Wenn ich dagegen mit einigen Programmierern spreche oder Blogs oder Foren lese, finde ich oft eine weit verbreitete Meinung, die sich mehr oder weniger wie folgt formulieren lässt: Theorie und formale Methoden richten sich an Mathematiker / Wissenschaftler, während beim Programmieren mehr darum geht, Dinge zu erledigen .

Was ist in der Regel hier angedeutet ist , dass die Programmierung ist etwas sehr praktisch und dass , obwohl formale Methoden, Mathematik, Algorithmik, sauber / kohärente Programmiersprachen, usw., können interessante Themen sein, sind sie oft nicht erforderlich , wenn alles , was man will , ist auf die Dinge fertig .

Nach meiner Erfahrung würde ich sagen, dass Sie, während Sie nicht viel Theorie brauchen, um ein 100-zeiliges Skript (die Hütte) zu erstellen, um eine komplexe Anwendung (das 10-stöckige Gebäude) zu entwickeln, auch einen strukturierten Entwurf benötigen -definierte Methoden, eine gute Programmiersprache, gute Lehrbücher, in denen Sie Algorithmen nachschlagen können usw.

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

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

Wird Software Engineering (Gebäudesoftware) von vielen als einfach empfunden, verglichen mit z. B. Tiefbau (Gebäudehäuser)?

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

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

1. Im Gegensatz zum Software Engineering ist im Bauingenieurwesen viel klarer, welcher theoretische Umfang (Modellierung, Design) für eine bestimmte Aufgabe benötigt wird.
2. Dies liegt zum Teil daran, dass das Bauwesen so alt ist wie die Menschheit, 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 (möglicherweise darf sie abstürzen), unterschiedlichen Marketingstrategien (gutes Design kann geopfert werden, um es schnell auf den Markt zu bringen) usw.

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

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

Ich denke, der Hauptunterschied besteht darin, dass die Physik der realen Welt beim Bauingenieurwesen als ständiger, leistungsfähiger Realitätscheck fungiert, der die Theorie vernünftig hält und auch schlechte Praktiken einschränkt, wohingegen es im Software-Engineering keine ebenso große Kraft gibt, unpraktische Konzepte für Elfenbeintürme beizubehalten als miese verarbeitung im schach.

Viele Programmierer haben schlechte Erfahrungen damit gemacht, dass die Runaway-Theorie ein aktives Hindernis für die Erledigung von Aufgaben darstellt (z. B. "ausführbare UML", überbürokratische Entwicklungsprozesse). Umgekehrt können schmutzige Hacks und Patches Sie ziemlich weit bringen, wenn auch langsam am Ende. Und wie Sie in Ihrem letzten Absatz feststellen: Fehler sind in der Regel nicht so endgültig und daher auch nicht so problematisch.

Software Engineering und Civil Engineering haben wenig gemeinsam. Tiefbauarbeiten sind durch die physikalischen Eigenschaften ihrer Werkstoffe und der Umwelt begrenzt. Bauingenieure verbringen viel Zeit mit dem Erlernen der Bodeneigenschaften und Materialeigenschaften. Die Softwareentwicklung ist physikalisch 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 größte Einschränkung bei der Softwareentwicklung ist der menschliche Intellekt. Und keine zwei Entwickler sind gleich. Ist dieser Code wartbar? Von wem? Eine dreizeilige Implementierung von Quicksort in Haskell ist für einige offensichtlich korrekt, für andere jedoch unverständlich. Ein Team von zwei Personen kann einen Antrag in einem Monat abschließen, während ein anderes Team von zehn Personen Probleme 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 ein Unikat.

Als ein mehr oder weniger ehrlicher Maschinenbauingenieur (mit einem gewissen zivilen) Programmierer, dann CS (AI) PhD, dann Lehrer, dann Programmierer (entschuldigen Sie, Software Engineer ), habe ich ein Problem dieses allgemeine Thema.

In traditioneller Technik

• Sie müssen sich mit Mathematik und Naturwissenschaften auskennen, weil alles, was Sie tun, 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 die Software - Informationstheorie gilt, aber Softwareingenieure werden kaum darauf angesprochen, und es wird mit Sicherheit nichts angewendet. Die Theorie, die sie bekommen, ist Berechenbarkeit und Big-O.

Ich bin auch immer wieder erstaunt über die Menschen , die glauben , zu wissen , Programmierung ist genug, und sie brauchen nicht auf die verstehen , Gegenstand von dem, was ihre Programme über.

Einfallsreichtum wird nicht gefördert. Es wird zugunsten von Gruppen-Denkmethoden mit dem geringsten gemeinsamen Nenner, die als "Lesbarkeit" getarnt sind, abgeraten. (Stellen Sie sich vor, Luftfahrt- oder Nuklearingenieure würden aufgefordert, nichts zu tun, was für ihre jüngeren Kollegen schwer zu verstehen sein könnte.)

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

Wenn ich bei den meisten Programmen Abstriche mache und etwas mache, das nicht das beste Design ist, aber den Job erledigt, wird niemand sterben. Es ist der gleiche Grund, warum eine Hütte im Garten nicht den gleichen Standard benötigt wie ein 10-stöckiges Gebäude. Ich kann jedoch eine sehr große App wie Facebook erstellen, und wenn es Fehler macht und Daten verliert, oder was auch immer, ist das nicht wirklich eine 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. Es kommt alles auf den Kontext und die Berechnung des Risikos an.

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

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

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

Ich habe mir einmal von einem Professor sagen lassen, dass Zaudern zu Zaudern führt, obwohl die meisten Leute nach einer Nacht voller Papierkram sagen: "Das mache ich nie wieder. Das nächste Mal fange ich früh an und früh fertig werden. " In meiner Erfahrung als vollendeter Zauderer habe ich festgestellt, dass dies zutrifft, und hier ist die Erklärung des Professors, warum: Egal wie unangenehm die Erfahrung des Zauderns ist, in den meisten Fällen haben Sie einen relativen Erfolg erzielt. Dies ist ein Verhalten mit hohem Risiko und hohem Ertrag. Nach einer Weile vergisst du all die Unannehmlichkeiten und erinnerst dich nur an die Belohnung. Umso verlockender ist die nächste Versuchung, etwas hinauszuschieben, denn Sie haben es das letzte Mal geschafft.

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 einer echten Zeitbeschränkung, geht beim Programmieren so vor, dass all Ihre Theorie, Mathematik und bewährten Praktiken aus dem Fenster geworfen werden. Und weisst du was? Sie erledigen Dinge. Es ist nicht elegant, hübsch oder wartbar, aber es erledigt die Arbeit. Vielleicht gibt ihnen ein nicht-technischer Vorgesetzter, der kein Semikolon aus einem Semaphor kennt, ein hohes Lob für "Dinge erledigen". Das nächste Mal, wenn der Programmierer versucht ist, diesen lockeren Ansatz für die Programmierung zu wählen, ist es umso einfacher, weil es letztes Mal funktioniert hat, nicht wahr? Es ist der "einfache" Ausweg, es sei denn, du bist der Arme,

Ich war diese arme, unglückliche Seele, und wahrscheinlich haben das auch viele von Ihnen. Ich flehe euch alle an. Geh nicht einfach raus! :)

Ihre Prämisse ist fehlerhaft. Der Hauptgrund, warum Bauingenieure beim Entwerfen großer Gebäude, Brücken, Tunnel usw. Ingenieure einsetzen, besteht darin, sicherzustellen, dass sie nur ein Minimum an Material (Beton, Baustahl usw.) verwenden, das 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 Kosten für Material und Arbeit kein Gegenstand sind, aber einmal gebaut, ist es normalerweise sinnlos, sie zu modifizieren sie, damit sie das Material effizienter nutzen.

Das Entwerfen großer Softwaresysteme weist eine etwas andere Dynamik auf. Wenn überhaupt, sind sie in der Regel unterkonstruiert, aber dies liegt daran, dass die Konstruktion 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 senkt die Kosten (sowohl hinsichtlich des tatsächlichen Materials als auch hinsichtlich des Haftungspotenzials), wohingegen in der Softwareentwicklung die Designkosten über den erzielten Wert hinaus ansteigen.

Ich möchte außerdem darauf hinweisen, dass die Menschheit seit den Zeiten der Ägypter das Äquivalent zum "Bauingenieurwesen" getan hat. Wir hatten also viel Zeit, um die allgemeine Theorie zu perfektionieren, wie die Dinge aussehen sollten getan werden. Wir entwickeln seit ungefähr 70 Jahren Software (je nachdem, was Sie als erste "Software" bezeichnen). Ich meine, wir hatten nicht die gleiche Zeit, um die gleiche Art von Erfahrung zu entwickeln.

Die Baupläne eines Architekten / Bauingenieurs sind so gut wie nie mit den "as built" -Plänen identisch. Etwas ändert sich IMMER. Warum? Denn es gibt und wird immer "unbekannte Unbekannte" geben. Es gibt Dinge, die Sie kennen und so planen können, Dinge, die Sie kennen, sind unbekannt und Sie können nachforschen und schätzen, und dann gibt es Dinge, die Sie nicht kennen und 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 des Baukastens (die möglicherweise auf einer Regel basiert, die vor zwei Jahren bei der Konzeption Ihres Gebäudes noch nicht bestand) und alles -Umfassender Masterplan muss sich ändern, manchmal ganz drastisch.

Software ist sehr ähnlich; Es gibt immer ein unbekanntes Unbekanntes. Im Gegensatz zum Hoch- und Tiefbau ist die Softwareentwicklung inhärent viel toleranter gegenüber Änderungen, die auf den Problemen beruhen, die durch unbekannte Unbekannte verursacht werden. Wenn Sie ein 10-stöckiges Gebäude errichten und die Tragfähigkeit des Fundaments, das Sie in Ihrem Entwurf verwendet haben, überschätzt haben, können Sie das Gebäude entweder nicht auf 10 Stockwerke aufbauen, oder Sie müssen einen erheblichen Arbeitsaufwand aufbringen Gehe zurück zum Fundament und verstärke es oder baue es wieder auf. Wenn Sie in der Software die Anforderungen an eine bestimmte Ebene der Gesamtlösungsstruktur unterschätzt haben, gibt es viele Optionen zum Beheben dieser Ebene, bei denen nicht alle anderen Arbeiten ungültig werden. Sie können einen einzelnen DB-Server durch einen leistungsfähigeren oder einen Replikations- / Failover-Cluster ersetzen. oder ein Load-Balancing / Distributed Cluster. Gleiches gilt für den Webserver. Wenn Sie einen Algorithmus codiert haben, der ineffizient, aber einfach ist und auf fehlerhaften Annahmen der Eingabegröße basiert, können Sie die Implementierung fast immer einfach entfernen und relativ chirurgisch neu schreiben, ohne anderen Code zu beeinflussen, der den Algorithmus kennt (ruft auf und leitet Eingaben an) es, oder erwartet eine Ausgabe davon).

Diese relativ einfache Änderung ermöglicht es einem Softwareentwickler, basierend auf dem, was er weiß, zu programmieren, ohne sich übermäßig Gedanken über das zu machen, was er nicht weiß. Dies ermöglicht eine lockerere Anwendung von Theorie und Konzeption im Vorfeld. du tauchst ein und erledigst es, und auf dem Weg findest du die Dinge, die du codiert hast und die geändert werden müssen, und änderst 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. Aber Sie dürfen eine schnelle Entscheidung treffen, ohne der "Analyse-Lähmung" zu erliegen, denn wenn sich herausstellt, dass Sie die falsche Entscheidung getroffen haben, basierend auf etwas, das Sie nicht wussten oder nicht in Ihre "Berechnungen" einbezogen haben fehler ist leichter zu korrigieren.

Der Unterschied beruht hauptsächlich auf den bekannten Anforderungen:

• Theoretisch alles 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 etwas in der Mitte der Implementierung, 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 von "Theorie" die Rede ist, bedeutet dies in der Regel eher die theoretische Seite der Informatik als das Software-Engineering. In diesem Teil der Informatik geht es hauptsächlich darum, bessere und effizientere Algorithmen zu finden, um zu beweisen, ob etwas möglich ist oder nicht (z. B. P und NP) und so weiter. Während es gut ist, diese im Hinterkopf zu haben, kommen sie in der Softwareentwicklung nicht sehr oft vor.

Wir benutzen Bibliotheken für solche Dinge so oft wie möglich.

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, daher ist der Entwicklungsprozess naturgemäß viel strenger als der einer Website, auf der Bilder von Raketen gezeigt werden.

Einer meiner Mitarbeiter, der für die NASA gearbeitet hat, beschrieb seinen Softwareentwicklungsprozess zuvor als das Schreiben von Hunderten von Seiten Rechtfertigung und Hunderten von Stunden Versammlungen, um das Schreiben einer einzigen Codezeile zu rechtfertigen!

Verstehen Sie mich nicht falsch, denn ich versuche nicht, 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, irgendwann etwas kaputt geht, sodass sie auch Notfallpläne entwickeln müssen.

Beim Erstellen von Software verursachen die Kosten eines Absturzes selten einen Verlust an Leben, sodass es viel einfacher ist, schnell etwas nach draußen zu werfen und es zu testen. Lassen Sie uns zustimmen, dass eine schnelle Ausführung zu einem schwachen Code führt. Auch wenn dies immer der Fall ist, ist es für einen Entwickler am besten, Software in Aktion zu sehen, wo sie schwach ist und stärker werden muss als dort, wo sie schwach und immer noch um ein Vielfaches stärker ist, als es sein muss, um mitzuhalten die Ladung.

Zusammenfassend, Premature optimization is the root of all evil oder wie mein Chef immer sagen würdeShipping is a feature!

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. Ebenso ist Civil Engieering eine Sammlung von Vereinfachungen und Annäherungen der Physik für das praktische Bauen von Sachen.

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

Der große Unterschied besteht darin, dass Brücken, Wolkenkratzer und andere Produkte des Bauingenieurwesens einigermaßen gut verstanden werden. Softwareentwickler bauen häufig neuartige Konstrukte oder verwenden neuartige Methoden, um gut verstandene Dinge zu erstellen. Software Engineering ist weitaus weniger ausgereift als das Bauingenieurwesen, und dies wird wahrscheinlich auch in absehbarer Zukunft so bleiben.

TL; DR : Theorie und Praxis unterscheiden sich im Software Engineering wie überall. Die richtige Analogie ist Software Engineering: Civil Engineering :: Computer Science: Physics. Aber in der Praxis ist es etwas komplexer :)

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 ist anders als das 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, die die Wartung und die Zusammenarbeit mit Entwicklern vereinfachen und sich nicht an willkürliche mathematische Formeln oder andere solche Ideale halten. Wenn Sie beispielsweise das Verhalten anhand 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 anderes Beispiel kann mit Datenmanipulation gemacht werden. Es ist oft sinnvoll, Delegaten im Kontext von .NET zu verwenden. In Java ist das 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 der Situation Y auszuführen. Dies ist auf die Tatsache zurückzuführen, dass X und Y von der Anzahl N variabler Faktoren abhängen.

Wird Software Engineering (Gebäudesoftware) von vielen als einfach empfunden, verglichen mit z. B. Tiefbau (Gebäudehäuser)?

Ich bin mir nicht sicher, ob "einfach" der richtige Begriff ist. Das Fehlen konkreter Beweise kann zu der Annahme führen, dass keine Arbeit geleistet wird. Oder, ähnlich, die vorhandene Arbeit wird leicht geändert.

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

Traditionelles Engineering und Software Engineering sind aus den bereits genannten Gründen sehr unterschiedlich.

Möglicherweise ist Ihre Wahrnehmung hier falsch, oder es sind viele Ressourcen von Personen enthalten, die keine ausreichend komplexe Software geschrieben haben.

Ihre Erfahrung entspricht der Meinung der meisten mir bekannten Personen (die ausreichend komplexe Software entworfen und geschrieben haben).

Das heißt, wenn es für die meisten Programmierer darum geht, etwas zu schreiben, hat der Architekt / lead / etc das Design ("die Mathematik", wie Sie es ausdrücken) bereits übernommen. vor der Aufgabe des Schreibens kommt es zu ihnen. So könnte es von der Frontlinie aus aussehen.

Ich denke, der Grund für diesen Gegensatz ist, dass der Lebenszyklus eines Softwareprojekts und eines Hardware- oder Architekturprojekts unterschiedlich ist. Die meiste Software entwickelt sich schrittweise weiter, es 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, machen Sie einen Schritt zurück und überdenken Sie Ihre Strategie. Das ist der Grund, warum Softwareentwickler Dinge wie agile Entwicklung, minimal lebensfähige Produkte und so weiter haben.

Bauingenieure haben keinen solchen Luxus. Wenn einmal etwas geplant ist, können Sie es nicht so einfach ändern wie mit Software, da die Kosten für solche Änderungen sehr hoch sein können. Für die Software-Entwicklung ist das nicht so teuer, und das kann zu ihrem Vorteil genutzt werden.

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

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

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

Ich war Maschinenbauingenieur und Fertigungsingenieur, bevor ich vor 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 die Dinge erledigen. Wir haben jetzt ungefähr zehn Jahre agiler Entwicklung hinter uns, und die Botschaft ist klar. Gehen Sie nicht schichtweise vorwärts. Fortschritt durch Funktionen. Sicher - es wird Projekte geben, bei denen Sie schrittweise Fortschritte erzielen müssen (z. B. Ihren Netzwerkstapel vor Ihrem Webserver erstellen), aber für die überwiegende Mehrheit der Projekte in der Praxis haben wir die Lektion gelernt, dass die Bereitstellung von Funktionsmerkmalen eine oder mehrere ist In einer Zeit ist es viel effektiver, riesige ungetestete Theorien aufzubauen und dann zu versuchen, sie umzusetzen.

Nehmen wir also Ihr Hüttenbeispiel (ich spreche normalerweise davon, eine Brücke zu bauen, indem ich einen Baumstamm über einen Bach oder eine kilometerlange Hängebrücke wirf ... was auch immer!) Und bringen es in die Welt der Softwareentwicklung. Der Hauptunterschied, den ich sehe, besteht darin, dass in der Software der größte Teil der Arbeit von einer Größe ist, die keine große Vorab-Modellierung erfordert, um erfolgreich zu sein. Der Fehler des Anfängers ist oft anzunehmen, dass die Dinge mehr davon brauchen als sie tatsächlich tun, und für die meisten von uns, die diesen Fehler ein paarmal gemacht haben, ist es unheimlich, dass wir ihn zu oft wiederholen.

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

Ich denke, die Analogie ist fehlerhaft. Das Bauingenieurwesen hat meines Wissens 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 nicht viel über Bauingenieurwesen, aber ich glaube nicht, dass es Bauingenieur-Äquivalente von P gegen NP, dem reisenden Verkäufer und anderen lustigen Dingen gibt, gegen die man seinen Verstand schlagen kann. Und es gibt definitiv einen Platz für unsere Informatiktheorie - wenn jemand den reisenden Verkäufer oder das Problem des Anhaltens löst, stehen uns viele großartige neue Fortschritte bevor. Für einen Softwareentwickler, der Software entwickeln möchte, sind solche Probleme jedoch nur Spaß und Spiel.

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

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

Ein weiterer Grund ist, dass es derzeit mehrere populäre Methoden zur "Erledigung" von Softwareentwicklungen gibt, die effektiv sind. Bei der agilen Entwicklung wird beispielsweise nicht vorher ein gesamtes System entworfen. Der Grund dafür ist, dass Sie noch nicht genau wissen, was Sie erstellen - Sie möchten, dass das, was Sie erstellen, flexibel ist und sich an neue Informationen und Anforderungen anpasst. Das alles von Anfang an zu entwerfen und dann zu bauen, bringt nicht immer die beste Software hervor. Es ist jedoch nicht die Lösung für alles. Angenommen, Sie entwerfen eine neue Sache, die für Distributed-Computing-Cluster verrückt ist. Sie können keine Serviettenskizzen anfertigen und Ihren SCRUM starten.

TL; DR. Ich denke, das Wort "Theorie" ist etwas zweideutig. Traditionell bezieht sich die Theorie auf die theoretischen mathematischen Aspekte der Informatik. Sofern Sie nicht nach neueren Methoden suchen, spielt die theoretische Informatik im alltäglichen Leben eines Software-Ingenieurs zum größten Teil keine Rolle. Softwareentwickler kümmern sich um Entwurfsmuster und die Systemarchitektur. Spezifische Implementierungsdetails bestimmter Algorithmen sind nicht wichtig. Oft ist es mit 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.

Die Kluft zwischen Theorie und Praxis ist momentan zu groß. In der Theorie werden Ihnen drei Axiome gegeben, und anschließend wird gezeigt, dass ein einzeiliger Satz einen tausendseitigen oder gar keinen Beweis enthält. In der Softwareentwicklung erhalten Sie inkonsistente APIs mit Tausenden von Funktionen, mit denen Sie unzählige (schlechte) Möglichkeiten zum Implementieren einer unterbestimmten Funktion erhalten.

Echte Softwareentwicklung würde die meisten im formalen Bereich in den Wahnsinn treiben, und echte mathematische Softwareentwicklung treibt die Ingenieure in den Wahnsinn. Beide Bereiche erfordern Menschen mit unterschiedlichen Fähigkeiten, und ich glaube nicht, dass sich die Fähigkeiten oft überschneiden.

Die formale Theorie geht davon aus, dass Sie alles im Voraus genau planen können, wie ein hergestelltes Produkt, dass Software auf unbestimmte Zeit in derselben Umgebung existiert 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 durch Analyse, Abstraktion, Generalisierung und Vorhersage zukünftiger Veränderungen zu lösen. Dies ist gut, wenn Sie ein genau definiertes Problem in einer unkomplizierten Domäne haben, das leicht zu analysieren, vorhersehbar und ziemlich statisch ist.

Bei der praktischen Programmierung geht es darum, das richtige Problem (nicht das des Softwaredesigns) jetzt auf die richtige Weise 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, das niemals "fertig" ist, sondern eher wie ein lebendiges Ding, das hochspezialisiert für eine ökologische Nische beginnt und möglicherweise eine sehr variable Lebensdauer hat, in der es neue, unvorhergesehene Probleme in einer Nische lösen muss Vielzahl von sich ständig ändernden Umgebungen. In der Geschäftswelt sind die Anforderungen angesichts von Politik und Recht sowie Wettbewerb und sich ständig ändernden Organisationen, Strukturen und Trends häufig nicht eindeutig, mit allen Arten von Sonderfällen behaftet, schlecht definiert und unterliegen raschen unerwarteten Veränderungen. Sie sind nicht analysierbar, vorhersehbar oder statisch, und oft nicht logisch oder vernünftig. Es ist wahrscheinlich, dass die Software in 2 Wochen irrelevant ist und in 20 Jahren noch verwendet wird. Es kommt auf die Welt, ohne viel zu wissen oder zu können, und muss während seines gesamten Lebens gepflegt, gepflegt und trainiert werden, um stark, flexibel und in der Lage zu sein, sich an die sich ständig ändernden Umgebungen und neuen Probleme anzupassen. Wenn Sie es nach der Geburt vernachlässigen, wird es verwildern, wenn es lange genug überlebt, Schmerzen und Leiden verursacht und Probleme mit stumpfer Gewalt löst.

Die formale Theorie geht nicht auf die Bedürfnisse vieler realer Unternehmenssoftware ein. Dies lässt uns glauben, dass Software entworfen und durchgeführt werden kann. Dass es sich um ein Produkt handelt, das gelegentlich repariert, poliert oder angeheftet werden kann, aber nicht um ein Lebewesen, das während seines gesamten Lebens mit ständiger Sorgfalt und Aufmerksamkeit richtig aufgezogen werden muss. Am Ende haben wir also wirklich hässlichen, verwilderten Code, aber die formale Theorie hätte wahrscheinlich nicht dazu beigetragen.

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

Die Einsätze sind geringer, die Arbeit ist einfacher und das Management sieht selten den Wert eines guten Designs. 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 berichten an jemanden, der es ist.

Der Rest der Schlacht ist mit Ihren Programmiererkollegen. Viele von ihnen können oder wollen sich nicht dazu verpflichten, über ein Problem nachzudenken, bevor die Codierung beginnt. Aufgrund des oben Gesagten sind viele dieser Leute leitende Entwickler, was es noch schwieriger macht, ein gutes Design in die Produktion zu bringen.

Ich habe beobachtet, wie Projektleiter jahrelang Ad-hoc-Funktionen und Korrekturen zu Projekten hinzugefügt haben, die anfangs steinig waren, und dann jeden Versuch, Ordnung in das Chaos zu bringen, mit Begriffen wie "zu kompliziert" oder "Zeitverschwendung" niedergeschlagen. Es ist nicht angenehm, eine große Projektspirale in ihrem unvermeidlichen Untergang zu beobachten, da das Management nicht zugeben wird, dass sie täglich ihr eigenes Gefängnis bauen. Ich fürchte jedoch, es ist eine unglückliche Realität, die viele Entwickler gesehen und - zum Guten oder Schlechten - daraus gelernt haben.

Ich versuche in meiner Arbeit ein Medium zu finden. Ich schreibe in "verdorbenen" Projekten nicht mehr Code, als unbedingt erforderlich ist, und nutze jede Gelegenheit, um Funktionen aus ihnen herauszuholen . "Zwischen Projekten" Ich verbringe Zeit mit dem Entwerfen und Aufräumen der Projekte, über die ich tatsächlich die Kontrolle habe.

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

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

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

Die Konstruktionstheorie ist dagegen eng an ganz bestimmte, auf der Realität basierende Gesetze gebunden, an die Sie sich halten müssen. Sie können nicht nur den Kontext oder die Gesetze ändern. Das Problem selbst ist in diesen Gesetzen verwurzelt. Beim Programmieren ändert die Lösung jedoch manchmal 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 wird normalerweise in einer Sprache und nur in einer Sprache ausgeführt, wobei Konfigurationsdateien nicht berücksichtigt werden.

Das Front-End einer Web-App besteht dagegen hauptsächlich aus zwei deklarativen (nicht programmierbaren) Sprachen und JavaScript. Die einzige physikalische 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 kein beliebtes und bekanntes Muster wie MVC verwenden, um Front-End-Probleme ausschließlich im Web zu behandeln, ohne die Art und Weise zu ändern, wie Sie sie in einem Desktop-App-Kontext behandeln. In der Tat würde ich argumentieren, Sie sollten wissen, was MVC nützlich macht, aber nicht einmal versuchen, es auf eine besonders anspruchsvolle oder umfassende Art und Weise zu implementieren. Das Web-App-Paradigma ist insofern einzigartig, als alle Look-at-Me-Inhalte vom Browser des Benutzers verarbeitet werden und sich alle daten- / modellbezogenen Inhalte normalerweise auf dem Server befinden. Aber wo bleibt der Controller? Alles auf dem Server oder alles auf dem Frontend? Jemand muss das besitzen. Oder MVC ist nicht zu 100% für das Szenario geeignet. Keine schlechte Passform für .NET-Backend-Produkte. Nicht schrecklich im Zusammenhang mit bestimmten Widgets der Benutzeroberfläche.

Der Bau eines Hauses löst ein Problem. Typische Programmierprobleme beinhalten jedoch oft 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 leider nicht besonders an dieser Idee interessiert.

Glenn Vanderburg gibt einen guten Überblick über die Unterschiede zwischen Software-Engineering und traditionelleren Ingenieurdisziplinen: http://www.youtube.com/watch?v=NP9AIUT9nos

Wenn ein Bauingenieur seine Entwürfe ohne Kosten testen könnte, bevor er das Endergebnis erstellt, 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 bricht, würde er dies tun, anstatt monatelang 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 kennen.

Tatsächlich sind die meisten Softwareprodukte heutzutage nicht mehr durch physische Einschränkungen wie Rechenleistung oder Arbeitsspeicher eingeschränkt. Die Einschränkung von Software ist die Komplexität, die in immer größeren Systemen auftritt. Es geht darum, diese Komplexität zu bewältigen, indem das System für den Menschen nachvollziehbar bleibt, was die große Herausforderung bei der heutigen Programmierung darstellt.