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

63

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.

Giorgio
quelle
9
nein, 90% der programmierer sind;)
jk.
24
Nun, in der Software könnten Sie mit dem Bau des Daches beginnen und sich dann bis zum Fundament arbeiten, während die fertigen Teile in der Luft schweben. Wenn etwas nicht passt, können Sie Klebeband verwenden, um es passend zu machen. Versuchen Sie dies, wenn Sie einen Wolkenkratzer bauen. ;)
Sichern Sie sich den
65
In der Theorie gibt es keinen Unterschied zwischen Theorie und Praxis, aber in der Praxis gibt es einen.
Joris Timmermans
6
Ein gutes Buch zum Nachschlagen von Algorithmen? Die meiste Software ist einfach nur CRUD, ohne dass etwas in der Nähe ist, was in einem Algorithmuskurs oder -buch enthalten ist.
Gilles
44
In der Theorie geht es um moderne Sprachen und Algorithmen. Das Training beginnt an Ihrem ersten Tag mit der Arbeit und wird beauftragt, der Point-of-Sale-Software, die auf einer Registrierkasse ausgeführt wird, eine Nebenfunktion hinzuzufügen, die Software verwendet, die von Personen, die C nicht kannten, von Hand von BASIC auf K & R C konvertiert wurde Verwenden eines fehlerhaften Compilers eines Anbieters, der bankrott gegangen ist und von dem erwartet wird, dass er die Funktion spätestens am Freitag ausführt.
Gort the Robot

Antworten:

61

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.

Michael Borgwardt
quelle
1
Ich stimme Ihnen zu, dass es beim Software-Engineering wichtig ist, über das richtige Maß an Formalismus zu verfügen. Zu viel bedeutet, dass Sie nie loslegen können und es vielleicht zu spät ist, wenn Sie herausfinden, dass Sie einen Fehler gemacht haben. Zu wenig bedeutet, dass Sie ein Durcheinander machen können. Ich denke, Sie haben eine starke Überzeugung, dass Produktivität und Qualität im Software-Engineering viel schwieriger zu messen sind als im Bauwesen.
Giorgio,
2
"... während es in der Softwareentwicklung keine ebenso starke Kraft gibt, um unpraktisch zu bleiben ..." Ich denke, Sie meinen, es gibt keine solche Kraft mehr. Damals wirkten sich die Einschränkungen durch schwächere Prozessoren, weniger Arbeitsspeicher und wenig / keinen Speicher als solche aus.
Fleisch
1
@blesh: Das glaube ich nicht. Enge Hardware-Grenzen schränken gute und schlechte Technik gleichermaßen ein.
Michael Borgwardt
Ihre Beispiele sind nicht die Theorie der Programmierung. Die Einschränkungen der Software hängen mit den verwendeten Technologien und der mathematischen Kapazität der Autoren zusammen.
Paul Nathan
5
UML hat definitiv etwas "Theoretisches" ... ... seinen Nutzen!
ObscureRobot
29

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.

Kevin Cline
quelle
1
Ich stimme Ihren Beobachtungen zu, dass der Faktor Mensch in Software viel stärker ist, aber ich denke dennoch, dass der Versuch, ein Problem zu analysieren oder Ihre Lösung zu strukturieren, eine allgemeine Haltung / ein allgemeines Werkzeug ist. Meine Frage ist, warum einige Programmierer meinen, dies sei kein nützlicher Ansatz (oder gar Zeitverschwendung). Sie haben Haskell erwähnt: Ich habe mir die Mühe gemacht, etwas über Haskell zu lernen, obwohl ich es in keinem Projekt verwendet habe, weil ich dachte, es würde mir helfen, besseren Code zu schreiben (sogar in C ++ oder Java). Auch wenn ich das nicht messen kann, ist mein Gefühl, dass ich produktiver geworden bin: Ich lasse mehr Dinge erledigen.
Giorgio,
2
Eine dreizeilige Haskell-Quicksortierung? Hmm ... ist es überhaupt möglich , Quicksort in einer Sprache zu implementieren, in der alles vom Design her unveränderlich ist?
Mason Wheeler
3
@MasonWheeler Erstes Ergebnis von Google: Quicksort in Haskell .
Chrisaycock
3
@Mason: die Laufzeit ist noch O (n log n). Es benötigt auch O (n log n) Speicher, im Gegensatz zu einer In-Place-Schnellübersicht, die nur O (log n) zusätzlichen Speicher für die Rekursion benötigt.
Kevin Cline
2
@kevincline In dem Maße, in dem ein typisches Softwareprojekt einzigartig ist, habe ich bei der Umgestaltung meines Badezimmers ein einzigartiges Projekt in Angriff genommen. Der Unterschied ist, dass wenn ich meinen Code vermassle, meine Tests rot werden und wenn ich meine Verkabelung vermassle, mein Haus niederbrennt. Natürlich war dieses Projekt auch Überstunden und über das Budget hinaus, da ich keine Erfahrung darin habe, Umbauprobleme zu lösen. Das Hauptproblem, das ich bei Softwareprojekten gesehen habe, ist ähnlich ... es ist nicht so, dass die richtigen Leute diese Probleme nicht schneller lösen könnten, es ist so, dass die richtigen Leute nicht verfügbar sind und wir die richtigen Leute im Internet werden müssen fliegen.
Philosodad
17

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.

Mike Dunlavey
quelle
5
Die Physik kann Ihnen sagen, ob eine Struktur unter ihrer eigenen Last zusammenbricht oder nicht. CS sagt Ihnen, dass Sie nicht sagen können, ob ein bestimmtes Programm bei einer bestimmten Eingabe anhält. IMO formale Methoden skalieren viel besser im Bauwesen oder Maschinenbau als in Software, vor allem weil die Systeme weniger komplex und weniger dynamisch sind ...
Guy Sirton
6
@GuySirton "CS sagt Ihnen, dass Sie nicht sagen können, ob ein bestimmtes Programm bei einer bestimmten Eingabe anhält." Wenn das alles ist, von dem Sie glauben, dass CS es tut, dann wissen Sie vielleicht nicht so viel über CS wie Sie ...
gregghz
2
Guy, es ist unglaublich unwahrscheinlich, dass Sie jemals Software-Materialien verwendet haben, die noch niemand zuvor verwendet hat. McCarthy und Turing haben es getan, aber in Wirklichkeit ist Software-Engineering nicht so verdammt erstaunlich. Wenn es in Ordnung wäre, wenn das Gebäude auf den Grund des Ozeans sinken würde, weil Sie es einfach neu starten könnten , wäre das wie Software-Engineering.
Philosodad
3
Ich würde dir eine +1 geben, außer dem Riss über die Lesbarkeit. Die Wartbarkeit macht 80% der Softwarekosten aus, sodass die Lesbarkeit keine Kleinigkeit ist. Darüber hinaus ist es wichtig, wenn dieser Luftfahrt- oder Nuklearingenieur etwas herstellt, das von anderen verstanden wird. Das Militär, die Regierung oder sogar große Institutionen sind mit einer magischen Erfindung nicht zufrieden, die von niemand anderem als dem Erfinder nachgebildet oder verstanden werden kann.
Thomas
2
@Thomas - Die Behauptung, dass praktikable Lösungen häufig bei der Änderung der "Lesbarkeit" durch untergeordnete Köpfe verworfen werden, bedeutet nicht unbedingt, dass die Lösungen nicht so lesbar sind, wie sie sein sollten. Ich habe es gesehen. Verdammt, ich habe mich dabei ertappt.
Erik Reppen
13

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.

CaffGeek
quelle
Nun, Sie hoffen, dass sie nicht sterben ... hängt von Ihrer Software ab;)
Rig
3
@Rig, deshalb habe ich 'am meisten' und 'normalerweise' gesagt. Manche Software ist viel kritischer.
CaffGeek
Ich denke, dies wird zunehmend zu einer sehr schlechten Sichtweise. Sicher, dass die meisten Software-Programme keine Auswirkungen auf die Sicherheit haben, aber es sind Geld und Datenschutz mit vielen Software-Programmen verbunden. Falsche
Angaben können
11

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! :)

FischkorbGordo
quelle
3
Wenn Sie es einmal erledigen und vergessen müssen, ist es in Ordnung. Aber wenn Sie es später erweitern und warten müssen, suchen Sie nach Schwierigkeiten. Sie müssen ein Gefühl dafür haben, wie viel Theorie es bedeutet: Zu viel bedeutet, dass Sie es nie schaffen, zu wenig bedeutet, dass Sie es zehnmal schaffen, bevor es wirklich getan wird. Meine 2 Cent.
Giorgio,
6
Aber manchmal müssen Sie Ihre Software JETZT herausbringen . Sie müssen einen Konkurrenten schlagen, um zu vermarkten. Oder Sie sind gesetzlich verpflichtet, einige Informationen bereitzustellen. Oder Sie müssen nur einen Cashflow erzielen, damit Sie auch dann noch existieren, wenn das Durcheinander, das Sie bei Ihrem Ansatz "erledigen" angerichtet haben, ein Problem ist ... was manchmal ein gutes Problem ist. Denn wenn Sie es nicht hatten, haben Sie es nicht rechtzeitig veröffentlicht und Ihr Unternehmen ist tot, bevor es beginnt.
CaffGeek
1
@Chad - ich stimme dir zu. Es ist ein Gleichgewicht. All die Dinge, die Sie erwähnen, würden als Gründe für eine erfolgreiche Programmierung unter "eine echte Zeitbeschränkung" fallen, und kurzfristig ist es in Ordnung und sogar vorteilhaft, wenn Sie darauf hinweisen.
FishBasketGordo
@FBG: Genial gesagt.
Kuba Ober
@Chad, guter Punkt. Martin Fowler macht einen ähnlichen Punkt bei martinfowler.com/bliki/TechnicalDebt.html . Manchmal ist es ein lohnender Kompromiss.
John M Gant
9

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.

James McLeod
quelle
"An einem Punkt in der Softwareentwicklung steigen die Kosten für das Design über den erzielten Wert hinaus.": Ich habe ausdrücklich "die richtige Menge an Theorie" geschrieben. Ich weiß, dass Over Engineering die Produktivität nicht steigert.
Giorgio
Es gibt IMO-Projekte, bei denen es fast keine Projekte gibt, die von vornherein so konzipiert sind, dass sie tatsächlich ihrem Entwurf folgen. Bauingenieurwesen baut (im Allgemeinen?) Immer wieder dasselbe (eine Straße, ein Damm, ein Tunnel, ein Gebäude, eine Brücke). Die Techniken sind bekannt. Dies gilt nicht für Software. Weil es leicht geändert werden kann und weil die Leute nicht wissen, was sie wollen oder was funktioniert, bis sie es ernsthaft im Voraus ausprobieren. Design ist Zeitverschwendung. Wir bauen, testen und iterieren. Etwas, das mit dem Bauingenieurwesen nicht möglich ist, wie oben ausgeführt. Die beiden Disziplinen sind nicht vergleichbar.
gman
5
Entschuldigung, ich muss auf den Tippfehler hinweisen: Ich glaube nicht, dass Bauingenieure einen Mist bauen. ;-)
Giorgio
2
Ich stelle mir vor, dass in der Zukunft, wenn wir Softwareingenieure coole Software für die Simulation von Bauingenieuren entwickeln, die Bauingenieure all diese mathematischen Dinge abschaffen können. Bauen Sie einfach einen 10 km hohen virtuellen Wolkenkratzer. Wenn es in den ersten 100 virtuellen Jahren nicht unter seinem eigenen Gewicht zusammenbricht und einem virtuellen Hurrikan der Kat. 5 standhält, können Sie es mit dem speziellen 3D-Wolkenkratzerdrucker bauen.
Emory
1
@ RexKerr: Sie hackten die Hälfte seiner Aussage: "... die die erforderlichen Sicherheitsstandards erfüllt"
Lie Ryan
7

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.

Onorio Catenacci
quelle
6

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.

KeithS
quelle
3
Es gibt auch viel mehr unbekannte Unbekannte in der Softwareentwicklung - Sie beginnen vielleicht damit, einen Wolkenkratzer zu bauen, aber wenn der Kunde es sich ansieht, sagt er Ihnen, "eigentlich wollte ich einen zehnstöckigen Rubix-Würfel".
Tacroy
@Tacroy: Interessanterweise würde ein Bauingenieur dies wahrscheinlich für einen schlechten Kunden halten, der Ihre Zeit und Ressourcen verschwendet. Ein Software-Ingenieur wird versuchen, eine neue Methodik zu entwickeln, um ihn zufrieden zu stellen. :-)
Giorgio
1
@ Giorgio oder Rechnung entsprechend ...
CaffGeek
5

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.

Izkata
quelle
1
+1 für "Wenn von Theorie die Rede ist, bedeutet dies normalerweise die theoretische Seite der Informatik."
Joshua Drake
5

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!

Albert Lang
quelle
3
+1 für "Versand ist ein Feature"! Einmal hörte ich einen ähnlichen Satz: "Perfektion existiert nicht. Diese Software hat den Vorteil, dass sie existiert." Natürlich ist es ein Witz. In Bezug auf unternehmenskritische Software: Eine nicht abgefangene Ausnahme kann zum Absturz einer Rakete führen.
Giorgio
this software has the advantage that it exists... ich hatte das noch nicht gehört, aber es wird in meine Liste großartiger Software-Zitate aufgenommen. Ich mag es
Albert Lang
@ Giorgio: JSF und MISRA C sind so geschrieben, dass es keine Ausnahmen gibt. Ausnahmen und Raketen passen nicht zusammen.
Coder
5

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 :)

ObscureRobot
quelle
"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." und solche Sachen). Dies ist keine Quantenmechanik, aber IMO ist es definitiv nicht trivial.
Giorgio,
2
Sicher, aber Sie müssen nicht für jede Komponente Ihrer Brücke eine Wellengleichung ableiten und dann erklären, wie sie sich gegenseitig beeinflussen.
ObscureRobot
Du hast recht. Mein Punkt ist jedoch nicht, wie viel Theorie im Bauingenieurwesen für das Software-Engineering verwendet wird. Bauingenieure wissen vielmehr, dass sie ihre Formeln verwenden und Berechnungen zum Bau eines Gebäudes anstellen müssen. In der Softwareentwicklung habe ich den Eindruck, dass es mehr Improvisation gibt und manchmal, wenn Sie sich zurücklehnen und ein Problem analysieren möchten (nur um es richtig zu machen, keine Doktorarbeit darüber zu schreiben), können Sie verpönt sein: Wir wollen es bekommen fertig, um es nicht perfekt zu machen. Aber IMO einige Theorie (nicht zu viel) ist genau das, was dazu beitragen kann, es schneller fertig zu machen!
Giorgio
Sie müssen einen für Ihr Projekt geeigneten Ausgleichspunkt finden. Nachwuchsentwickler sind in der Regel mehr daran interessiert, Mist zusammenzuschmeißen, um zu sehen, was haften bleibt. Wenn sie einen sehr theoretischen Hintergrund haben, haben sie möglicherweise sogar verrückte und übermäßig komplexe Ideen. Um Nachwuchsentwickler effektiv zu managen, müssen sie häufig einen Schritt zurücktreten und ihre Arbeit analysieren. Auf der anderen Seite können sich ältere Entwickler zu sehr auf langfristige Entwurfsprobleme konzentrieren, bis sie Probleme haben, sich auf unmittelbare Bedürfnisse zu konzentrieren.
ObscureRobot
Wow, tut mir leid, dass dies kein Thema ist, aber ohne Ihre Antwort zu lesen, habe ich es genauso beendet - mit einem TL; DR und dann buchstäblich genau der gleichen Analogie. SAT-Format. Ich habe es aus meiner Antwort heraus bearbeitet, damit es nicht so aussieht, als würde ich dich kopieren, aber es macht mich immer noch verrückt. Vielleicht denken die Programmierer zu ähnlich.
Jarsen
3

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.

P. Brian Mackey
quelle
1

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.

Steven Evers
quelle
3
"Die Mathematik ... ist bereits erledigt": Berücksichtigen Sie nicht nur alle Bibliotheksfunktionen, Frameworks, DBMSs, Protokolle und jede Menge anderer schwerer Dinge, die wir einfach in unserem Code verwenden können, indem Sie eine Funktion mit einigen Parametern aufrufen. Als Programmierer fühle ich mich manchmal eher wie ein Arbeiter auf dem Gerüst als wie ein Ingenieur, der das Gebäude entworfen hat.
Giorgio
1

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.

V-Stern
quelle
1

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

Martin Beckett
quelle
Was ist das Softwareäquivalent einer Finite-Elemente-Analyse des 100-stöckigen Gebäudes? Wie viele hohe Gebäude haben Wanzen in therm / crash? :-)
Guy Sirton
@GuySirton - Sie können ein großes Gebäude nur auf einer sehr groben Ebene analysieren, die weniger detailliert ist als ein Unit-Test einer typischen App. Viele große Gebäude haben Fehler, Fenster fallen heraus, Gehwege stürzen ein, sie erzeugen Windkanaleffekte. Oder bei einem geschwungenen, stark reflektierenden Hotel in Vegas erzeugen Sie einen Todesstrahl im Pool!
Martin Beckett
Sie können in der FEA ziemlich feinkörnig vorgehen und das Verhalten mit einem sehr hohen Maß an Genauigkeit vorhersagen. Die Leute machen immer noch Fehler. IMO ist es einfach unmöglich, ähnliche Vorhersagen für eine komplexe Software zu treffen. Die von Ihnen genannten Fehler machen einen winzigen Bruchteil der Gesamtzahl der Gebäude aus. Die Fehlerraten in der Software müssen zwei Größenordnungen höher sein. Das heißt, es ist offensichtlich ein Kontinuum zwischen dem, wo formale Methoden nützlich sind und wo sie unbrauchbar sind.
Guy Sirton
@GuySirton - Ich denke, die Schwierigkeit besteht darin, dass Sie sich auf andere Dinge verlassen. Die Nasa kann Flug-Avionik bis ins kleinste Detail testen (obwohl dies immer noch nicht der Fall ist), da sie auch das Betriebssystem und die Hardware erstellt. Das Schreiben auf einem allgemeinen Betriebssystem mit Toolkits und Bibliotheken ist wie das Bauen einer Brücke, bei der Sie die Details des Stahls oder Betons nicht kennen dürfen.
Martin Beckett
1
@MartinBeckett, und der Schwerkraftkoeffizient ändert sich zufällig von Stunde zu Stunde ... wie wenn Ihr Systemadministrator zufällig entscheidet, einen Server zu aktualisieren, ohne jemandem mitzuteilen, weil "er transparent sein wird".
CaffGeek
1

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.

Dominic Cronin
quelle
1

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.

Jarsen
quelle
1
Ich sehe einige Ähnlichkeiten zwischen unseren Antworten, aber Ihre Ideen sind offensichtlich originell und es gibt einige Unterschiede. Ich stimme nicht zu, dass es nicht nützlich ist, P / NP zu verstehen. Sie müssen sich nicht eingehend mit der Komplexitätstheorie befassen, aber ein funktionierender Softwareentwickler sollte in der Lage sein, das O (n) eines bestimmten Codes abzuschätzen und intelligente Aussagen über die Kosten alternativer Lösungen zu treffen. Ein Punkt, den Sie beinahe gemacht hätten, aber nicht getan haben, ist, dass die Theorie oft in Bibliotheken eingekapselt ist. Das ist gut zu überlegen.
ObscureRobot
"Wenn jemand ... das Problem des Stillstands löst, stehen uns viele großartige neue Fortschritte bevor.": Nun, leider hat die Theorie bewiesen, dass dies unlösbar ist (es gibt kein Programm, das darüber entscheiden kann), daher glaube ich, dass es keines gibt Der Versuch, das Halteproblem zu lösen, wird intensiv erforscht.
Giorgio
Turing-Maschinen können nicht "Allerdings sind nicht alle für die menschliche Vorstellungskraft denkbaren Maschinen Gegenstand der Church-Turing-These ... Es ist eine offene Frage, ob es tatsächlich deterministische physikalische Prozesse geben kann, die sich langfristig der Simulation durch a entziehen Turing-Maschine, und insbesondere, ob ein solcher hypothetischer Prozess sinnvoll in Form einer Rechenmaschine (eines Hypercomputers) genutzt werden könnte, die das Problem des Anhaltens lösen könnte ... Es ist auch eine offene Frage, ob solche unbekannten physikalischen Prozesse beteiligt sind die Arbeit des menschlichen Gehirns ... "-Halting Problem, Wikipedia
Jarsen
Soweit ich weiß, und korrigieren Sie mich, wenn ich mich irre. Ich denke, wir haben noch viel zu tun, was die Berechnung angeht. Wie in diesem Thread mehrfach erwähnt, ist die Informatik noch sehr jung; es könnte viel mehr als nur Drehmaschinen und die Von Neumann-Architektur geben.
Jarsen
@Jarsen: Es ist wahr, dass die Informatik sehr jung ist, aber jeder Computer, der bis jetzt gebaut wurde, kann nur Turing-berechenbare Sachen machen. Soweit ich weiß (sehr wenig in der Tat), können selbst Quantencomputer nicht mehr (sie könnten bestimmte Probleme schneller lösen, aber sie wären nicht in der Lage, mehr Probleme zu lösen). Also ja, wer weiß, was erfunden werden kann, aber jeder Computer-Formalismus, der in den letzten 70 Jahren vorgestellt wurde, kann nicht mehr als eine Turing-Maschine.
Giorgio
1

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.

Marco Devillers
quelle
0

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.

Strahl
quelle
0

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.

Daniel
quelle
0

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.

Erik Reppen
quelle
0

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.

Mirkok
quelle