Ich lese oft über die Bedeutung von Lesbarkeit und Wartbarkeit. Oder ich lese sehr starke Meinungen darüber, welche Syntaxmerkmale schlecht oder gut sind. Oder Diskussionen über die Werte bestimmter Paradigmen, wie OOP.
Abgesehen davon schwebt mir diese Frage immer wieder in den Kopf, wenn ich Debatten über SO oder Meta über subjektive Fragen lese. Oder lesen Sie Fragen zu Best Practices und finden Sie mich oder andere manchmal nicht einverstanden.
Welche Rolle spielt Subjektivität im Programmierbereich?
Manchmal denke ich, dass es eine große Rolle spielt. Softwareentwickler sind in gewisser Weise Ingenieure, aber auch Menschen. Ein großer Teil der Programmierung beschäftigt sich mit Code, der lesbar ist . Dies ist sehr verschieden von Mathematik oder Physik oder anderen Disziplinen mit sehr genauen und strukturierten Regeln. Hier sind die genaue Struktur und die Regeln weitgehend in der Luft, aus einer Laune heraus veränderbar und daher die Anzahl der vorhandenen Sprachen. Und eine Person kann eine Sprache sehr gut lesbar finden, und eine andere Person kann ihre eigene Sprache am tröstlichsten finden.
Das Gleiche gilt für Praktiken. Eine Person mag bestimmte akzeptierte Praktiken nicht. Ich selbst finde aufspalten Klassen in verschiedenen Dateien sehr unlesbar, zum Beispiel.
Aber ich kann nicht sagen, dass Regeln im Allgemeinen nicht geholfen haben. Bestimmte Praktiken haben und erleichtern das Leben. Und neue Sprachen haben zu Syntax und Struktur geführt, die das Leben erleichtern. Es gab sicherlich einen Fortschritt in Bezug auf Code, der einfacher zu lesen und zu pflegen ist, selbst bei einer sehr heterogenen Gruppe von Menschen. Vielleicht sind diese Dinge nicht so subjektiv wie ich dachte.
Es erinnert mich in gewisser Weise an das UI-Design. Sicherlich ist es subjektiv, aber dann gibt es eine ganze Disziplin in der Herstellung guter Benutzeroberfläche und es funktioniert.
Gibt es etwas Nicht-Subjektives über die Ideen hinter Wartbarkeit, Lesbarkeit und anderen Best Practices? Gibt es etwas Greifbares, wenn man eine neue Sprache entwickelt oder an neue Praktiken denkt?
Wahrscheinlich geht es bei Ihrer Frage wirklich um die Unterscheidung zwischen Programmierung , die mathematisch, algorithmisch und wissenschaftlich ist, und Softwareentwicklung , die subjektiv, variabel und auf den Menschen ausgerichtet ist.
Großartige Programmierer sind nicht unbedingt großartige Softwareentwickler und umgekehrt. Die beiden Skillsets haben zwar keine Exklusivität, überschneiden sich jedoch weniger als sie zunächst erscheinen. Ihre relative Bedeutung hängt stark vom Projekt ab: Ein brillanter Programmierer, der alleine arbeitet, kann erstaunliche Beispiele für technisches Genie liefern, und es spielt keine Rolle, dass niemand sonst es verstehen oder aufrechterhalten kann, weil er den Code ohnehin nicht teilen wird. Aber bewegen Sie sich in eine Unternehmensumgebung - wie unternehmensinterne Softwareentwicklung - und ich tausche Ihnen gerne zehn "Höhlentroll" -Genis für einen mittelmäßigen Programmierer, der die Bedeutung von Lesbarkeit und Dokumentation versteht.
Ich habe die Erfahrung gemacht, dass die Welt großartige Softwareentwickler mehr braucht als großartige Programmierer. Relativ wenige Leute heutzutage schreiben Software, die wirklich performancekritisch ist (OS-Kernel, Compiler, Grafik-Engines, eingebettete Echtzeitsysteme usw.), und das Internet ermöglicht es mittelmäßigen Programmierern, schnell algorithmische Lösungen für Probleme zu finden, die sie nicht konnten alleine lösen. Aber fast jeder, der professionellen Code schreibt, muss innerhalb eines Teams arbeiten. Und die Teamproduktivität steigt und fällt dramatisch auf die Fähigkeit ihrer Mitglieder, effektiv zu kommunizieren und die Arbeitsbelastung effizient zu verteilen, zwei Fähigkeiten, die sehr subjektiv sind und durch starre Formeln nicht bewiesen werden können.
Die meisten Software-Engineering-Prinzipien basieren auf Erfahrung und nicht auf objektiven Gesetzen. Ähnlich wie die Sozialwissenschaften studieren, lernen, adaptieren und anwenden wir - aber ohne wirkliche Garantien für das Ergebnis. Alles was wir sagen können ist, dass einige Dinge in den meisten Gruppen besser funktionieren als andere.
Ich denke, vieles hängt notwendigerweise davon ab, wie viel unser Verstand gleichzeitig verarbeiten kann. Es kommt also darauf an, wie sehr die Sprache und die Werkzeuge es einem Team oder Entwickler ermöglichen, das Problem in Stücke zu zerlegen, die für sich selbst bedeutungsvoll sind, aber nicht so groß, dass es zu schwer wird, sie zu erfassen. Das gemeinsame Thema ist die Kunst des Organisierens von Informationen (in diesem Fall der Code, die Logik, ...). Aber das ist nicht so viel anders als Mathematik oder Physik.
Genau wie die besten Autoren von vielen Stilen borgen, behalten die besten Programmierer eine riesige Auswahl an Mustern in ihrem mentalen Arsenal. Slawisch ein paar Muster zu folgen und sich an eine absolute Wahrheit zu halten, ist sowohl faul als auch gefährlich.
Sagen wir es anders, der Tag, an dem wir uns auf Roboter für die Code-Überprüfung verlassen, ist der Tag, an dem ich aufhöre.
Es hängt alles von Ihrem Standpunkt ab: -)
Aber um Ihre Fragen zu beantworten, denke ich, dass eine Möglichkeit, Subjektivität zu betrachten, darin besteht, zu erkennen, dass Softwaresprachen, Werkzeuge und Best Practices ein gemeinsames Kommunikationsmittel zwischen Individuen sind. Ja, eine Programmiersprache ist eine formale Methode, um einem Computer Anweisungen zum Verhalten zu geben, aber eine Programmiersprache kann auch als Möglichkeit angesehen werden, Spezifikationen auf einem hohen Detaillierungsgrad zu definieren und zu kommunizieren (der Code ist die ultimative Spezifikation, nicht wahr? ?).
Wenn wir uns also mit dem Grad der Subjektivität in Softwaresprachen, Werkzeugen und Best Practices befassen wollen, würde ich sagen, dass der Mangel an Subjektivität anzeigt, wie gut die Kommunikation erleichtert wird.
Ja, Individuen haben bestimmte Neigungen, die sich in ihren Gewohnheiten und Neigungen ausdrücken, aber das sollte letztlich nicht zu sehr auf der perfekten Plattform für die Entwicklung liegen.
Ich wandte mich an meine Math-PhD-Frau und fragte, ob es Subjektivität in Mathematik gäbe. Ihre Antwort ist ja, da ist es, hauptsächlich in der Art, wie wir als Menschen die Antwort erreichen.
Wenn ein mathematischer Beweis das Ergebnis ist, wie kann man zu diesem Ergebnis kommen? Wenn das Dataset groß ist, müssen Sie möglicherweise einen Computer verwenden, der Fehler verursachen kann, und daher darüber debattiert werden, ob dies der richtige Ansatz ist. Oder manchmal können Mathematiker der Theorie widersprechen - man versucht zu beweisen, dass x wahr ist, während der andere zu beweisen versucht, dass x falsch ist.
Ich denke, das Gleiche existiert in der Informatik. Eine korrekte Antwort ist ein Programm, das korrekt ausgeführt wird, aber diese Definition von "korrekt" kann für jedes Projekt unterschiedlich sein. Manchmal bedeutet richtig, keine Fehler. Manchmal bedeutet es, effizient zu laufen.
Von hier aus können Programmierer argumentieren, wie man das "richtige" Ergebnis am besten erreicht. Ein gutes Beispiel dafür ist die FizzBuzz-Anwendung. Eine einfache Antwort wäre nur eine For-Schleife, aber Enterprise FizzBuzz ist auch "korrekt", da sie die richtige Antwort liefert , wird aber allgemein als "schlechtes" Engineering ausgelacht wegen seiner Überkomplikation der Idee (es war immerhin eine Scherz App).
Wie groß ist die Rolle der Subjektivität beim Programmieren? Ich würde sagen, es ist ein sehr großer Teil von dem, was wir tun, einfach weil wir Menschen sind und weil es mehrere Möglichkeiten gibt, die "richtige" Antwort zu bekommen, so dass es Uneinigkeit darüber gibt, welcher Weg der Beste ist.
Es wurden Studien durchgeführt, die zeigen, dass bestimmte Praktiken die Fehlerrate in Software reduzieren. Zum Beispiel fand eine Studie eine starke Korrelation zwischen der zyklomatischen Komplexität und der Wahrscheinlichkeit fehleranfällig zu sein. Andere Studien zeigen die durchschnittliche Effektivität von Design- und Code-Inspektionen 55 und 60 Prozent. Es scheint also in unserem Interesse zu sein, Einfachheit zu bevorzugen, Metriken zu überprüfen und Code-Reviews durchzuführen.
Wir sprechen hier allerdings Wahrscheinlichkeiten. Wenn ich deinen Code überprüfe, kann ich nicht sicher sein, dass er 60% deiner Fehler findet. In der Softwareentwicklung gibt es auch einige absolute Dinge. Erfahrene Entwickler wissen, dass die richtige Antwort im Allgemeinen "es kommt darauf an". Allerdings gibt es eine Reihe von Praktiken mit objektiven Daten zu ihren Gunsten.
Tags und Links language-agnostic