Wenn Abstraktionen undicht werden


In der Softwarewelt verwenden wir ständig Abstraktionen, um unsere Arbeit zu erleichtern, da sie uns von anderen Domänen abstrahieren und die Komplexität, mit der wir umgehen müssen, erheblich reduzieren. Ein Beispiel für eine Abstraktion sind ORMs. Ein ORM ermöglicht es uns, die Anwendung von der verwendeten Datenbank zu abstrahieren. Anstatt Abfragen (die spezifisch für die Datenbank-Engine sind) schreiben zu müssen, um auf die Daten zuzugreifen, ermöglicht uns das ORM, die Programmiersprache, die wir zum Codieren der Anwendung verwenden, auch für den Datenzugriff zu nutzen. Jeder, der ORMs verwendet hat, weiß, dass die Abstraktion in vielen Fällen gut funktioniert und viel Wert bringt, aber wenn die Anwendung erfordert, dass wir mehrere zusammenhängende Entitäten abrufen, unter anderem, dann beginnen wir, die Grenzen zu sehen. In diesen Fällen ist es üblich, dass ORMs nicht immer die optimalen Abfragen generieren oder dass sie uns dazu zwingen, übermäßig komplexen Code zu schreiben, sodass wir manchmal am Ende Abfragen direkt in der Sprache der zugrunde liegenden Datenbank schreiben. Das bedeutet, die Abstraktion für solche Fälle beiseitezulegen.
Es ist in diesen Momenten, wenn Abstraktionen beginnen, „Wasser zu ziehen", dass ein Verständnis der abstrahierten Domänen oder Schichten notwendig wird. Entwickler werden jedoch oft zu bloßen Nutzern von Abstraktionen und versäumen es, sich für das zu interessieren, was darunterliegt. Manchmal tun wir das aus Zeitmangel, aber in vielen anderen Fällen liegt es an mangelnden Grundlagen oder fehlendem Interesse.
Heutzutage gibt es eine Vielzahl von Schulen, die Ihnen beibringen, in wenigen Monaten von Null an zu programmieren. Im Allgemeinen konzentrieren sich diese Schulen darauf, Ihnen Sprachen und Frameworks auf Benutzerebene beizubringen. Alles ist sehr praxisorientiert, und fast von Anfang an programmiert man. Aber jeder, der den Weg des Programmierenlernens gegangen ist, weiß, dass es Jahre dauert, nicht Monate. Und dass es weitaus mehr Wissen erfordert, als nur zu wissen, wie man ein Framework benutzt. Es ist nur eine Frage der Zeit, bis die Studenten dieser Schulen auf die Grenzen von Abstraktionen stoßen. In diesen Fällen haben sie zwei Möglichkeiten: zu versuchen, das Problem zu umgehen, mit einem Workaround von mehr oder weniger schwerwiegenden Auswirkungen; oder zu erkennen, dass sie tiefer in die abstrahierte Domäne eintauchen und daran arbeiten müssen. Und nur einer dieser Wege wird sie dazu bringen, echte Programmierer zu werden.
Dies ist jedoch nicht nur ein Problem, das Programmierstudenten betrifft. Alle Entwickler, die Anwendungen mit einem Mindestmaß an Komplexität programmieren, werden früher oder später auf dieses Problem stoßen. Und ich denke, Programmierer akzeptieren Abstraktionen oft als perfekt, wir „verlieben" uns in Abstraktionen. Und wir vergessen, dass sie Werkzeuge sind, um uns das Leben zu erleichtern, und wie alle Werkzeuge haben sie Grenzen.
Heute stehen wir vor dem, was wahrscheinlich eine der größten Abstraktionen der Geschichte ist, nämlich KI-Sprachmodelle, die es ermöglichen, Quellcode aus natürlicher Sprache zu generieren. Diese Abstraktion ist so mächtig, dass viele glauben, es werde nicht mehr nötig sein, programmieren zu können, um Software zu erstellen. Diejenigen von uns jedoch, die diese Technologie zur Code-Generierung eingesetzt haben, wissen, dass sie noch erhebliche Einschränkungen hat, die solide Programmierkenntnisse erfordern, um sie zu überwinden. Während die Abstraktion im Laufe der Zeit wahrscheinlich verfeinert wird, halte ich es für einen Fehler zu glauben, dass wir eine neue Generation von Entwicklern ohne Programmierkenntnisse ausbilden können, genauso wie ORMs den Bedarf an Datenbankkenntnissen nicht beseitigt haben.
Während der Wert von Abstraktionen unbestreitbar ist, da sie es uns ermöglichen, uns zu erheben und größere Ziele mit weniger Aufwand und Komplexität zu verfolgen, halte ich es für sehr wichtig, sich bewusst zu sein, dass sie nicht nur Vorteile haben, sondern auch Grenzen, die nicht übersehen werden dürfen. Aus all dem ziehe ich zwei Schlussfolgerungen: Einerseits muss die Wahl einer Abstraktion durch die Analyse sowohl ihrer Vorteile als auch ihrer Nachteile erfolgen, wobei man bereit sein muss, sie zu verwerfen, wenn diese Analyse ungünstig ausfällt, und andererseits müssen wir bedenken, dass wir, wenn wir an die Grenzen von Abstraktionen stoßen, ein gutes Wissen über die zugrunde liegende Domäne haben müssen, um eine solide Antwort geben zu können. Wenn wir oder unser Team nur Wissen auf Benutzerebene darüber haben, ist es nur eine Frage der Zeit, bis wir auf Probleme stoßen, die wir nicht zufriedenstellend lösen können.