{"id":4512,"date":"2024-04-15T16:02:03","date_gmt":"2024-04-15T16:02:03","guid":{"rendered":"https:\/\/msgprogramator.sk\/?p=4512"},"modified":"2025-07-07T11:36:23","modified_gmt":"2025-07-07T11:36:23","slug":"code-reviews","status":"publish","type":"post","link":"https:\/\/msgprogramator.sk\/de\/code-reviews\/","title":{"rendered":"Code Reviews: Sind sie n\u00fctzlich oder Zeitverschwendung?"},"content":{"rendered":"

Eine der wichtigsten F\u00e4higkeiten eines Programmierers ist die F\u00e4higkeit, sauberen Code<\/a> zu schreiben, der wartbar und fehlerfrei ist. Ganz gleich, wie geschickt Sie sind, es ist immer m\u00f6glich, dass Sie bestimmte Fehler oder potenzielle Probleme in Ihrem Code \u00fcbersehen. An dieser Stelle kommt der Code-Review-Prozess ins Spiel. Code-Reviews sind in vielen Entwicklungsunternehmen zu einem Teil des Softwareentwicklungsprozesses geworden. Ihr Ziel ist es, den Code von Teamkollegen \u00fcberpr\u00fcfen zu lassen, bevor er in ein Quellcode-Repository \u00fcbertragen wird, um potenzielle Fehler zu finden, sicherzustellen, dass die Codierungsstandards eingehalten werden, und nicht zuletzt, um Wissen unter den Teammitgliedern zu teilen. Manche Menschen lieben sie, andere hassen sie. W\u00e4hrend die einen argumentieren, dass Code-Reviews ein notwendiger Bestandteil des Entwicklungsprozesses sind, stellen andere ihre Effektivit\u00e4t in Frage und bezeichnen sie als zeitaufw\u00e4ndig und potenziell \u00fcberfl\u00fcssig. Der wahre Nutzen von Code-Reviews ist sehr umstritten. Sind Code-Reviews also wirklich n\u00fctzlich oder sind sie nur Zeitverschwendung? In unserem Artikel befassen wir uns mit den Argumenten aus beiden Lagern. Lesen Sie auch den Artikel Wie man Code-Reviews effektiv durchf\u00fchrt: Tipps und Tricks<\/a>. <\/p>\n

\"Code<\/p>\n

Was ist eine Code\u00fcberpr\u00fcfung?<\/h2>\n

Bei der Code\u00fcberpr\u00fcfung wird der von einem oder mehreren Entwicklern geschriebene Code \u00fcberpr\u00fcft, bevor er in ein gemeinsames Quellcode-Repository eingef\u00fcgt wird. Dabei handelt es sich um eine systematische zeilenweise \u00dcberpr\u00fcfung des Quellcodes durch eine oder mehrere Personen, um Fehler zu finden und zu beheben, die Qualit\u00e4t zu verbessern und die Einhaltung von Codierungsstandards sicherzustellen. In der Regel \u00fcberpr\u00fcfen die Entwickler die von ihren Kollegen vorgenommenen Code\u00e4nderungen, geben Feedback, schlagen Verbesserungen vor und identifizieren m\u00f6gliche Probleme. Code-Reviews k\u00f6nnen mit einer Vielzahl von Methoden durchgef\u00fchrt werden, z. B. mit Pair Programming, E-Mail, pers\u00f6nlichen oder Online-Meetings oder mit speziellen Tools, die asynchrone Reviews erm\u00f6glichen. <\/p>\n

Prozess der Code\u00fcberpr\u00fcfung<\/h2>\n

Bei einer Code\u00fcberpr\u00fcfung werden normalerweise verschiedene Aspekte des Codes untersucht, um seine Qualit\u00e4t und Korrektheit sicherzustellen. Wir stellen Ihnen eine Liste mit einigen der wichtigsten Metriken zur Verf\u00fcgung, die w\u00e4hrend des Code-Review-Prozesses \u00fcberpr\u00fcft werden k\u00f6nnen: Funktionalit\u00e4t:<\/u><\/strong> \u00dcberpr\u00fcft, ob der Code die erforderlichen Funktionen und Operationen korrekt ausf\u00fchrt. Es wird gepr\u00fcft, ob der Code die Anforderungen erf\u00fcllt und ob Daten und Eingaben korrekt verarbeitet werden. Effizienz und Optimierung:<\/u><\/strong> Die Effizienz des Codes wird \u00fcberpr\u00fcft und es wird nach M\u00f6glichkeiten zur Optimierung gesucht. Dies kann die \u00c4nderung von Algorithmen, die Eliminierung unn\u00f6tiger Wiederholungen oder die Verbesserung der Leistung kritischer Teile des Codes umfassen. Sicherheit:<\/u><\/strong> Der Code wird auf die Einhaltung von Sicherheitsstandards und -richtlinien gepr\u00fcft. Dazu geh\u00f6rt die Vermeidung potenzieller Sicherheitsl\u00fccken wie SQL-Injection<\/em>, Cross-Site-Scripting (XSS)<\/em> oder unbefugter Zugriff. Architektur und Entwurfsmuster:<\/u><\/strong> Analysiert, ob der Code die im Projekt verwendeten Entwurfsmuster und Architekturprinzipien einh\u00e4lt. Dieser Aspekt umfasst die \u00dcberpr\u00fcfung, ob der Code den Standard-Designregeln f\u00fcr Klassen, Module und Schichten folgt.<\/p>\n

\"Bei<\/p>\n

Lesbarkeit:<\/u><\/strong> Misst, wie leicht der Code f\u00fcr andere Entwickler zu lesen und zu verstehen ist. Dieser Aspekt umfasst wichtige Faktoren wie die Verwendung verst\u00e4ndlicher Variablen, korrekte und beschreibende Funktionsnamen und das Auskommentieren der weniger verst\u00e4ndlichen Teile des Codes. Codierungsstil und Konventionen:<\/u><\/strong> \u00dcberpr\u00fcft, ob der Code den etablierten Kodierungskonventionen und -stilen entspricht, die f\u00fcr das Projekt oder die Programmiersprache definiert sind. Dieser Aspekt umfasst die Formatierung des Codes, die Verwendung von Leerzeichen, Einr\u00fcckungen und \u00c4hnliches. Testen:<\/u><\/strong> Untersucht, ob der Code ordnungsgem\u00e4\u00df getestet wurde und ob Tests geschrieben wurden, die alle kritischen Aspekte seiner Funktionalit\u00e4t abdecken. Zu diesem Punkt geh\u00f6rt auch die \u00dcberpr\u00fcfung, ob der neue Code bestehende Tests nicht zerst\u00f6rt und ob er neue Testf\u00e4lle hinzuf\u00fcgt. Dokumentation:<\/u><\/strong> Bewertet, ob der Code angemessen dokumentiert ist, so dass er f\u00fcr andere Entwickler leicht zu verstehen und zu verwenden ist. Dazu geh\u00f6ren Codekommentare, die Dokumentation der neuen API und Benutzerhandb\u00fccher. <\/p>\n

Arten der Code\u00fcberpr\u00fcfung<\/h2>\n

Sehen wir uns nun an, welche verschiedenen Arten von Codepr\u00fcfungen in Unternehmen verwendet werden.<\/p>\n

Pers\u00f6nlich (oder durch das Teilen des Bildschirms \u00fcber MS Teams)<\/h3>\n

Diese Methode ist f\u00fcr die meisten Entwickler recht einfach und bequem, und der Entwickler erh\u00e4lt recht schnell Feedback. Wenn Ihr Code fertig ist, suchen Sie sich einen erfahrenen Teamkollegen, vereinbaren einen Termin und gehen den Code, den Sie geschrieben haben und den Sie in das Repository einbringen m\u00f6chten, gemeinsam durch – entweder pers\u00f6nlich oder online. Diese Art der Code\u00fcberpr\u00fcfung eignet sich f\u00fcr kleinere \u00c4nderungen, da der Pr\u00fcfer weniger Zeit hat, sich den Code in Ruhe anzusehen. <\/p>\n

E-Mail-Thread<\/h3>\n

Es l\u00f6st das Problem, einen Termin f\u00fcr die \u00dcberpr\u00fcfung des Codes zu finden. Sobald ein bestimmtes St\u00fcck Code zur \u00dcberpr\u00fcfung bereit ist, wird die Datei (oder ein Hyperlink dazu) per E-Mail an den\/die entsprechenden Kollegen geschickt, so dass jeder sie \u00fcberpr\u00fcfen kann, sobald es sein Arbeitsplan erlaubt. Dieser Ansatz ist sicherlich flexibler und anpassungsf\u00e4higer als traditionellere Techniken, wie z.B. ein Treffen von Personen, die sich auf die Code\u00fcberpr\u00fcfung konzentrieren. Allerdings kann ein E-Mail-Thread mit Vorschl\u00e4gen und unterschiedlichen Meinungen zu Codekorrekturen schnell aufgebl\u00e4ht werden, und es ist m\u00f6glicherweise nicht offensichtlich, was bereits korrigiert wurde und was nicht. <\/p>\n

Paarprogrammierung<\/h3>\n

Die Paarprogrammierung ist ein Ansatz zum Schreiben von Software, bei dem sich zwei Entwickler (meistens) einer einzigen Aufgabe widmen, gemeinsam an demselben Code arbeiten und so die Arbeit des anderen \u00fcberpr\u00fcfen. Es ist eine gute M\u00f6glichkeit f\u00fcr \u00e4ltere Entwickler, j\u00fcngere Kollegen zu betreuen und die Code\u00fcberpr\u00fcfung direkt in den Programmierprozess einzubinden. Allerdings geht bei diesem Code-Review-Ansatz die Objektivit\u00e4t und Unvoreingenommenheit verloren, die Sie beim Betrachten und \u00dcberpr\u00fcfen Ihres eigenen Codes haben. Der gr\u00f6\u00dfte Nachteil ist jedoch der h\u00f6here Ressourcenverbrauch (insbesondere Personal und Zeit) im Vergleich zu anderen Methoden. <\/p>\n

\"Paarprogrammierung<\/p>\n

Software-Tools<\/h3>\n

Sie vereinen die Vorteile der bisherigen Ans\u00e4tze und beheben viele der oben erw\u00e4hnten Einschr\u00e4nkungen der bisherigen Ans\u00e4tze, indem sie eine einfachere und effizientere Methode zur \u00dcberpr\u00fcfung von Code bieten. Die Codepr\u00fcfung kann direkt im Browser erfolgen oder diese Tools lassen sich \u00fcber Plugins nahtlos in verschiedene Entwicklungsumgebungen oder Codeverwaltungs-Tools integrieren. Sie erm\u00f6glichen es Ihnen, Kommentare von Kollegen und L\u00f6sungsvorschl\u00e4ge f\u00fcr Fehler in einer klaren und koh\u00e4renten Reihenfolge zu verfolgen (\u00e4hnlich wie bei der \u00c4nderungsverfolgung in MS Word), die \u00dcberpr\u00fcfungen sind asynchron (d.h. sie richten sich danach, wer wann verf\u00fcgbar ist), der Autor des \u00fcberpr\u00fcften Codes erh\u00e4lt Benachrichtigungen f\u00fcr neue \u00dcberpr\u00fcfungen. Es ist nicht n\u00f6tig, einen erfahrenen Kollegen zu finden und einen Termin f\u00fcr die \u00dcberpr\u00fcfung des Codes zu vereinbaren. Die Mitarbeiter arbeiten an ihren Rechnern und haben so viel Zeit, wie sie f\u00fcr die \u00dcberpr\u00fcfung des Codes auf Korrektheit ben\u00f6tigen. Au\u00dferdem haben Software-Tools verschiedene Metriken f\u00fcr die statische Code-Analyse eingebaut, die den Pr\u00fcfer auf bestimmte Teile des Codes aufmerksam machen k\u00f6nnen, auf die er sich bei seiner Pr\u00fcfung konzentrieren sollte. <\/p>\n

Vorteile von Codepr\u00fcfungen<\/h2>\n

Lassen Sie uns nun die Argumente sowohl der Bef\u00fcrworter als auch der Gegner von Code-Inspektionen betrachten. Beginnen wir mit den Argumenten, denen wir wahrscheinlich alle zustimmen werden. <\/p>\n

Zwei Augenpaare sehen mehr als eines.<\/h3>\n

Wir Entwickler \u00fcbersch\u00e4tzen manchmal, wie gut unser Code ist. Eine zweite, unabh\u00e4ngige Sichtweise kann uns eine andere Perspektive auf unseren Code geben und uns erlauben, den Code objektiver zu betrachten. Ein Pr\u00fcfer kann uns wertvolles Feedback dazu geben, wie lesbar und verst\u00e4ndlich unser Code ist. Wir versuchen in der Regel, unseren Code so zu schreiben, dass wir, wenn wir nach einiger Zeit darauf zur\u00fcckkommen, kein Problem haben, relativ schnell zu verstehen, wie der Code funktioniert und was er l\u00f6st.<\/p>\n

Wissensaustausch.<\/h3>\n

Code-Reviews bieten eine hervorragende Gelegenheit, Wissen unter den Teammitgliedern auszutauschen und etwas Neues zu lernen. Ganz gleich, ob es sich um unterschiedliche Codierungsstile, Techniken und bew\u00e4hrte Verfahren oder um die Verwendung neuer Frameworks und Bibliotheken handelt, ich pers\u00f6nlich sehe diese gegenseitige Befruchtung als den gr\u00f6\u00dften Vorteil des Code-Review-Prozesses. <\/p>\n

Fehlererkennung<\/h3>\n

Als Vorteil der Code\u00fcberpr\u00fcfung wird oft angef\u00fchrt, dass es sich um eine Form der Fehlererkennung handelt und dass das Aufsp\u00fcren von Fehlern, bevor der Code in einer Produktionsumgebung verwendet wird, langfristig Zeit und Ressourcen spart. Als Gegenargument wird jedoch angef\u00fchrt, dass der Code vor der Code\u00fcberpr\u00fcfung funktionsf\u00e4hig und getestet sein sollte. <\/p>\n

Verbesserte Codequalit\u00e4t<\/h3>\n

Ein weiterer h\u00e4ufig genannter Vorteil ist die verbesserte Codequalit\u00e4t. Durch konstruktives Feedback und Verbesserungsvorschl\u00e4ge tragen Code-Reviews dazu bei, die Gesamtqualit\u00e4t des Quellcodes zu verbessern. Die Pr\u00fcfer k\u00f6nnen aber auch Bereiche f\u00fcr die Optimierung, das Refactoring des Codes<\/a> oder die Verbesserung der Dokumentation identifizieren. Diese Vorteile schwinden jedoch allm\u00e4hlich mit der Erfahrung des Programmierers. Ein Entwickler mit langj\u00e4hriger Erfahrung ist in der Lage, diese Bereiche selbst zu erkennen und bei der Konzeption und Implementierung einer L\u00f6sung zu ber\u00fccksichtigen. <\/p>\n

Konsistenz der Standards und Verfahren<\/h3>\n

Code-Reviews gew\u00e4hrleisten die Konsistenz von Standards und vereinbarten Codierungspraktiken im gesamten Team. Dies ist zwar richtig, aber es gibt verschiedene Anwendungen wie Sonar<\/a>, mit denen dies automatisch \u00fcberpr\u00fcft werden kann, so dass eine \u00dcberpr\u00fcfung w\u00e4hrend der Code\u00fcberpr\u00fcfung nicht mehr erforderlich ist. <\/p>\n

Nachteile von Code-\u00dcberpr\u00fcfungen.<\/h2>\n

Kommen wir zu den Argumenten der Gegner der Durchf\u00fchrung von Code-Reviews.
\nLangwierig, zeitaufwendig und daher teuer. Au\u00dferdem machen Code-Reviews selten Spa\u00df. Deshalb werden sie, vor allem unter Zeitdruck (unter dem wir alle von Zeit zu Zeit stehen) oder einer schnell n\u00e4her r\u00fcckenden Frist, entweder gar nicht durchgef\u00fchrt oder zumindest gelegentlich \u00fcbersprungen. Dies gilt insbesondere f\u00fcr Code, der bereits einmal eingecheckt wurde und bei jeder \u00c4nderung wiederholt eingecheckt werden sollte. Au\u00dferdem kann die \u00dcberpr\u00fcfung von Code zeitaufw\u00e4ndig sein, insbesondere in gro\u00dfen Entwicklungsteams oder Projekten mit einer gro\u00dfen Codebasis. Die gr\u00fcndliche \u00dcberpr\u00fcfung jeder einzelnen Codezeile erfordert viel Zeit und M\u00fche, was den Entwicklungsprozess verlangsamen kann.<\/p>\n

Fehleranf\u00e4llig<\/h3>\n

Sie sind anf\u00e4llig f\u00fcr Fehler, da auch der Pr\u00fcfer nur ein Mensch mit mehr oder weniger Erfahrung und in den meisten F\u00e4llen kein Sicherheitsexperte ist. Trotz aller Bem\u00fchungen der Pr\u00fcfer k\u00f6nnen bei der Code\u00fcberpr\u00fcfung immer noch einige Probleme auftreten. Menschliches Versagen, Erm\u00fcdung oder mangelndes Fachwissen in bestimmten Bereichen k\u00f6nnen dazu f\u00fchren, dass kritische Punkte \u00fcbersehen werden, was die Effektivit\u00e4t des Code-Review-Prozesses verringert. <\/p>\n

Sie erfordern mindestens zwei Programmierer.<\/h3>\n

Sie ben\u00f6tigen mindestens zwei Programmierer im Team, die mit der Technologie vertraut sind. Der Pr\u00fcfer, der den Code pr\u00fcft, sollte \u00fcber die gleiche oder eine h\u00f6here Erfahrung verf\u00fcgen, denn wenn ein weniger erfahrener Programmierer einen Code-Review f\u00fcr einen erfahreneren Kollegen durchf\u00fchrt, wird der gesamte Code-Review in der Regel bedeutungslos. <\/p>\n

Subjektiv und demotivierend<\/h3>\n

Code-Reviews k\u00f6nnen manchmal subjektiv sein, da verschiedene Reviewer unterschiedliche Meinungen \u00fcber die Qualit\u00e4t und den Stil des Codes haben. Diese Subjektivit\u00e4t f\u00fchrt dann oft zu Konflikten oder langwierigen Diskussionen innerhalb des Teams, was den Abschluss der \u00dcberpr\u00fcfung verz\u00f6gern und die Produktivit\u00e4t beeintr\u00e4chtigen kann. Wenn das Feedback zu kritisch oder falsch ausf\u00e4llt, kann sich der Autor des zu pr\u00fcfenden Codes demotiviert f\u00fchlen. \u00c4hnlich verh\u00e4lt es sich, wenn sein Code nach wiederholter Pr\u00fcfung und Einarbeitung des Feedbacks nicht in das Repository aufgenommen wird. Softwareentwickler neigen dazu, ihren eigenen Code \u00fcber alles zu lieben und den Code anderer Entwickler zu hassen, wenn er auf eine Weise geschrieben ist, die ihnen nicht gef\u00e4llt. Sie sind sehr empfindlich, wenn es um ihren Code geht, und wenn jemand sie darauf hinweist, dass ihr Code schlecht ist, assoziieren sie das damit, dass sie schlechte Programmierer sind. <\/p>\n

Endlose Debatten<\/h3>\n

Im Gro\u00dfen und Ganzen sorgen Code-Reviews f\u00fcr endlose Debatten unter Entwicklern. Ein Entwickler kann dem Drang nicht widerstehen, einem anderen Entwickler zu beweisen, dass die Art und Weise, wie er den Code schreibt, falsch ist. Entwickler f\u00fchren Code-Reviews in der Regel aus ihrer eigenen Perspektive durch und betrachten andere Ans\u00e4tze nicht gerne als richtig. Wir ziehen es vor zu glauben, dass unsere Ans\u00e4tze genau die richtigen sind. Das liegt daran, dass wir Menschen zu faul sind und dass es f\u00fcr uns zu schmerzhaft ist, Zeit und Energie in die L\u00f6sung eines Problems zu investieren, das bereits gel\u00f6st wurde. Jeder Entwickler m\u00f6chte anerkannt werden, also pr\u00e4sentieren sie ihre Argumente und Anwendungsf\u00e4lle, um den Pr\u00fcfer davon zu \u00fcberzeugen, dass ihr Ansatz zur L\u00f6sung des Problems besser und optimaler ist. Das f\u00fchrt bei den Entwicklern zu endlosen Debatten, die letztlich dem Unternehmen und dem Gesch\u00e4ft schaden. <\/p>\n

\u00dcberm\u00e4\u00dfiges Nachdenken<\/h3>\n

Ein weiteres Problem, das bei der Code\u00fcberpr\u00fcfung auftritt, ist \u00fcberm\u00e4\u00dfiges Nachdenken. Selbst wenn der Code auf den ersten Blick gut aussieht, wollen wir unbewusst einen Fehler darin finden. Wir f\u00fchlen uns nat\u00fcrlich gut, wenn wir bei etwas n\u00fctzlich sind, und wenn wir einen Fehler im Code finden, f\u00fchlen wir uns n\u00fctzlich. Paradoxerweise wird derselbe Pr\u00fcfer, wenn wir ihm den verbesserten (korrigierten) Code zur erneuten Pr\u00fcfung vorlegen, noch mehr Dinge finden, die er verbessern kann. Und wenn wir denselben Code einem anderen Entwickler zur \u00dcberpr\u00fcfung geben, wird dieser noch mehr Fehler finden. <\/p>\n

Fazit<\/h2>\n

Wir haben Ihnen verschiedene Perspektiven auf Code-Reviews vorgestellt, und es ist klar, dass sie viele Vor- und Nachteile haben. Welche davon \u00fcberwiegen, \u00fcberlassen wir dem Urteil des Lesers. Wenn jedoch der Code-Review-Prozess nicht richtig eingerichtet ist, nicht gen\u00fcgend Zeit zur Verf\u00fcgung steht oder die Reviews unter Zeitdruck durchgef\u00fchrt werden und obendrein kein konstruktives Feedback vom Reviewer an den Code-Autor gegeben wird, k\u00f6nnen Code-Reviews das Arbeitsklima im Team erheblich st\u00f6ren und zu unkonstruktiven Auseinandersetzungen dar\u00fcber f\u00fchren, wessen L\u00f6sung f\u00fcr das Problem besser ist. Deshalb ist es wichtig, dass wir anfangen, einander mehr zu vertrauen und anderen die Entscheidungsfreiheit zu lassen. Wir bei msg life Slovakia<\/a> verwenden auch Code-Reviews, allerdings nur f\u00fcr Programmieranf\u00e4nger. Auf diese Weise k\u00f6nnen sie durch erfahrenere Kollegen eine Menge lernen und schneller in einen produktiven Arbeitsprozess einsteigen. <\/p>\n

Wenn du ein Java Programmierer<\/a> bist und nach Arbeit suchst, schau dir unsere Mitareiterbenefits <\/a> an und reagiere auf die neuesten Stellenangebote<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

Im Artikel erf\u00e4hrst du, was Code Reviews (\u00dcberpr\u00fcfung oder Revision von Code) sind, welche Vorteile und Nachteile sie haben und ob es sich lohnt, sie durchzuf\u00fchren.<\/p>\n","protected":false},"author":14,"featured_media":3084,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[64],"tags":[],"class_list":["post-4512","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programmierung"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/posts\/4512","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/users\/14"}],"replies":[{"embeddable":true,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/comments?post=4512"}],"version-history":[{"count":3,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/posts\/4512\/revisions"}],"predecessor-version":[{"id":8010,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/posts\/4512\/revisions\/8010"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/media\/3084"}],"wp:attachment":[{"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/media?parent=4512"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/categories?post=4512"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/tags?post=4512"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}