Hallo! Ich heiße Nikolai Izhikov. In diesem Beitrag möchte ich über ein wichtiges Element der Interaktion sprechen, auf das wir bei der Softwareentwicklung stoßen, insbesondere bei Open Source. Dies ist eine exemplarische Vorgehensweise und eine Codeüberprüfung.
Ich werde
schädliche Ratschläge geben, wie ich mein Feature erstellen und im OpenSource-Projektassistenten im Kontext kultureller, zeitlicher, konzeptioneller und anderer Unterschiede zwischen Community-Mitgliedern zusammenführen kann. Dies ist normalerweise eine schwierige Frage, insbesondere für diejenigen, die gerade erst mit Open Source anfangen.
Beginnen wir mit einer kleinen Einführung. Denken Sie bei der Kommunikation mit Personen, insbesondere im Chat oder per E-Mail, insbesondere auf Englisch, immer daran, dass Ihre Nachricht völlig anders wahrgenommen werden kann als erwartet. Wer den Brief lesen wird, ist unbekannt. Er kann ein Hindu, ein Engländer oder nur eine schläfrige Person sein. Es wird immer Unterschiede beim Verständnis bestimmter Wörter geben. Ohne auf technische Details einzugehen, erkläre ich Ihnen, wie Sie diese minimieren können.
Achtung: Die Geschichte enthält Sarkasmus.
Schlechte Tipps für einen Mitwirkenden
Besprechen Sie keine neue Funktion mit jemandem
Wenn Sie eine neue Funktion implementieren möchten, besprechen Sie Ihre Überarbeitung in keinem Fall mit jemandem. Jemand kann es belauschen und vor Ihnen tun! Oder nachdem sie die Details gehört haben, können sie Ihnen sagen, dass Sie etwas nicht verstanden haben - um Ihre Idee zu kritisieren. Kritik tut sehr weh. Vielleicht wurde bereits eine Funktion wie Ihre besprochen, und Sie benötigen eine andere ... Sagen Sie im Allgemeinen niemandem, was Sie tun möchten. Niemals.
Machen Sie niemals technische Dokumentation
Committer und erfahrene Leute aus der Community verstehen den Code des empfangenen Patches sehr gern. Führen Sie daher in keinem Fall eine technische Dokumentation durch. Wiki, Jira, Mail-List-Diskussion - das alles ist völliger Unsinn. Und der Bullshit ist nichts für dich!
Wenn Sie einen Patch an [+5000, -3500] mit einer Beschreibung der Verbesserungen in Form von „Verbesserungen der Factory-Methoden und einiger anderer Verbesserungen“ senden, wird dies jeder selbst herausfinden und gleichzeitig verstehen, wie gut Sie sind.
Führen Sie niemals Tests durch
Alle Tests sind gefährlich, weil sie etwas beschädigen können. Wenn Sie die Tests trotzdem ausgeführt haben, zeigen Sie ihre Ergebnisse nicht an. Fehler in den Ergebnissen können zur Ablehnung des Patches führen! Und auf keinen Fall neue Tests schreiben. Run All wird länger, der CPU-Verbrauch steigt. Wie auch immer, gute Entwickler schreiben Code ohne Fehler - jeder erfahrene Kollege wird sich Ihre Patches ansehen und verstehen, dass dort keine Fehler vorliegen.
Lesen Sie niemals die Anleitungen
Wenn Sie in ein OpenSource-Projekt eintreten, lesen Sie niemals eine Anleitung. Sie sind für Narren geschrieben, oder?
Gestalten Sie Ihren Code auf Ihre eigene Weise. Wie wird sonst jeder verstehen, dass Sie ein guter Entwickler und eine vielseitige kreative Person mit einem entwickelten Sinn für Schönheit sind?
Senden Sie Patches nach Ihren Wünschen. Zum Beispiel ist das Projekt an die GitHub-Infrastruktur gebunden - senden Sie es so, wie es direkt im Brief an den Linux-Kernel gesendet wird. Sie können sogar nicht im Anhang, sondern direkt im Text. Immerhin wird Linus Torvalds nicht schlecht raten! Und wenn das Projekt anders angenommen wird, dann sind dies Probleme des Projekts.
Fühlen Sie sich frei, die öffentliche API zu komplizieren
Versuchen Sie bei der Entwicklung der neuen öffentlichen API, sie so abstrakt und komplex wie möglich zu gestalten. Benutzerfragen zum nicht offensichtlichen Verhalten der API können immer beantwortet werden: „Haben Sie das Handbuch nicht gelesen? Seite 42, alles ist klar geschrieben! Lies es noch einmal! “ Bei ernsthaften Projekten sollte alles kompliziert sein. Wir haben ein ernstes Projekt?
Beraten oder sprechen Sie nicht über Probleme
Konsultieren Sie niemanden und erzählen Sie niemandem von den Problemen, die bei der Entwicklung aufgetreten sind. Es macht viel mehr Spaß, eine Sache zu verstehen. Wie auch immer, gute Entwickler haben immer beim ersten Mal Erfolg, sie haben keine Probleme. Wenn andere von Ihren Problemen erfahren, werden sie intelligenter und schreiben Code schneller als Sie. Dies sollte nicht erlaubt sein. Und in der Tat ist es nicht üblich, über die eigenen Probleme zu sprechen.
Die Einschränkungen der endgültigen Entscheidung sind ebenfalls nicht erwähnenswert. Schließlich kann die Lösung aufgefordert werden, abzuschließen. Wer kümmert sich um Einschränkungen? Wenn ein Benutzer Ihr Produkt in das Produkt einführt und auf Einschränkungen stößt, ist er interessierter und macht mehr Spaß. Er wird zu dir kommen und dich bitten, es zu beenden. Und bis zu diesem Punkt sollten Sie ihm auf keinen Fall etwas über die Einschränkungen erzählen - was ist, wenn er beschließt, nichts umzusetzen?
Ein wirklich guter Rezensent wird alles finden und Sie nach Details fragen. Erzählen Sie ihm auf keinen Fall etwas.
Wenn Sie Fragen haben, schreiben Sie an die Entwicklerliste
Dieser Tipp ergänzt den vorherigen. Es ist am besten, nicht nur niemandem etwas zu erzählen, sondern auch Fragen zu stellen, die hauptsächlich auf der Entwicklerliste stehen.
Hier sind Beispiele für Fragen, die jeder gerne beantwortet. Wenn Sie eine Art Test schreiben, fragen Sie unbedingt: "Müssen Sie diese Sammlung auf Null prüfen?". Sie müssen es nicht selbst herausfinden, Sie können immer auf dem Entwicklungsblatt nachfragen. Schließlich gibt es viele Menschen, die nur darauf warten, eine solche Frage zu stellen. Sie werden versuchen, schneller darauf zu reagieren.
"Wie mache ich die Aufgabe?" - Eine weitere gute Frage. Geben Sie in keinem Fall Details an: Die Aufgaben-ID reicht aus. Alle, die es brauchen, werden es selbst sehen.
"Welches Framework soll verwendet werden?" - auch eine sehr gute Frage. Es ist immer interessant, darauf zu antworten, und Sie können darüber diskutieren.
Beheben Sie alle Projektprobleme in einer Pull-Anfrage
Das ist mein Lieblingstipp. Beheben Sie alle Probleme des Projekts in einer Pull-Anforderung, insbesondere wenn Sie in einem Unternehmen arbeiten. Es gab nur Dummköpfe im Projekt vor Ihnen, sie haben den Code schlecht geschrieben. Und du schreibst gut. Dementsprechend müssen Sie einfach:
- Überarbeiten Sie den gesamten vorhandenen Code, den Sie nicht verstehen.
- Benennen Sie Ihrer Meinung nach alle falsch benannten Variablen um.
- Korrigieren Sie alle vorhandenen Javadoc-Kommentare.
Im Allgemeinen können Sie einige Klassen, Fabriken usw. herausnehmen und herausnehmen, andere Transformationen vornehmen, damit der Code besser ist. Dies wird besonders in Bereichen beeindruckend sein, die für Ihre Aufgabe nicht relevant sind. So können Sie Ihr Potenzial besser entfalten. Zum Ruhm der OOP! Amen!
Fordern Sie im Voraus eine Codeüberprüfung an
Wenn Sie eine Aufgabe ausführen und dann eine Anforderung zur Codeüberprüfung senden, kann der Vorgang eine Weile dauern. Alle Experten sind normalerweise beschäftigt. Nutzen Sie den Trick: Wenn Ihre Aufgabe, wie es Ihnen scheint, bald endet, fordern Sie im Voraus eine Überprüfung an. Schließlich sehen sie nicht sofort aus - bis Ihre Hände Sie erreichen, können Sie einfach alles beenden.
Nun, wenn der Rezensent plötzlich Zeit hat, während die Aufgabe noch nicht erledigt ist, dann hatte er Pech. Erklären Sie die Situation, sagen Sie, dass morgen alles fertig sein wird. Auf diese Weise beschleunigen Sie den Prozess (zumindest durch Überprüfung) und werden schneller zusammengeführt.
Müde von der Aufgabe - lassen Sie es fallen
Jeder, der in Open Source arbeitet, hat viel Zeit. Keine Notwendigkeit, etwas zu beenden. Codeüberprüfung bestanden, Kommentare erhalten. Und warum etwas bearbeiten und zusammenführen? Nimm das folgende Puzzle und mach es. Dies ist der Weg zum Erfolg! Der Rezensent hat viel Zeit und der nächste Patch wird ohne Ergebnis aussehen!
Rezensent ist dein Feind
Und wie soll man die Person nennen, die zwischen Ihnen und dem Commit in Master steht? Kritik am Code ist eine Kritik an Ihnen persönlich! Für wen hält er sich? In der persönlichen Kommunikation "bombardieren" Sie so viel wie möglich! Woher weiß der Rezensent sonst, dass Sie sich interessieren? Dies ist die Grundregel der Entwicklung!
Ich empfehle diesen Rat in der täglichen Entwicklung. Dies hilft, das Ergebnis zu erzielen und es richtig zu machen.
Schlechter Rat für den Rezensenten
Automatisieren Sie keine Routineprüfungen
Wenn Sie das Niveau im Projekt erreicht haben, an dem bereits Patches zur Überprüfung an Sie gesendet werden, automatisieren Sie auf keinen Fall Routineprüfungen! Es macht viel mehr Spaß, ein paar Überprüfungszyklen für die Fehlerbehebung und Diskussion aufzuwenden:
- Code-Formatierung;
- Variablennamen;
- prüft, ob diese Variablen als endgültig markiert sind, was von ihnen markiert werden kann;
- ... und alles andere.
In keinem Fall sollten Routineprüfungen automatisiert werden. Ja, und Tests, um zu nichts zu fahren.
Enthülle niemals alle Spielregeln bis zum Ende.
Um vorne zu sein, müssen Sie immer ein Paar Asse im Ärmel haben. Erzählen Sie niemandem von der Notwendigkeit der Abwärtskompatibilität. Es ist besser, kurz vor dem Commit zu sagen: „Hier muss nach unseren Regeln die Abwärtskompatibilität gewährleistet sein. Bitte korrigieren. " Dies ist besonders effektiv, wenn Sie bereits fünf Mal überprüft haben. Am sechsten kann man noch sagen: "Ich bin kein Experte, also müssen Sie auf die Überprüfung von Herrn X warten, der noch einmal nachsehen wird."
Solche Kommentare, insbesondere in der letzten Phase der Überprüfung, motivieren die Mitwirkenden immer.
Emotionen, Autoritäten und nein danke
Dieser Tipp überschneidet sich mit dem neuesten Beitragstipp. Schreiben Sie Kommentare zu Pull-Anfragen so emotional wie möglich. Wenn irgendwo nicht auf null geprüft wird oder die Variable nicht so benannt ist, fügen Sie Ihren Kommentaren Leidenschaft hinzu. Lassen Sie sie sehen, dass Sie sich interessieren.
Im Streitfall keine technischen Argumente vorbringen. Bei technischen Argumenten kann sich herausstellen, dass Sie falsch liegen. Wenden Sie sich an die Behörden - dies ist das beste Argument im Streit, Sie werden immer gewinnen.
Wenn jemand Ihre Bewertung durchgesehen hat, sollten Sie sich niemals bedanken. Trotzdem wollen sie sich zu Open Source verpflichten! Auf keinen Fall müssen Sie sich bedanken, und so werden sie wiederkommen!
Nun im Ernst: Woran sollten Sie bei der Vorbereitung und Durchführung einer Codeüberprüfung denken?
Ich hoffe, jeder hat verstanden, wie man die Überprüfung durchführt und besteht. In jedem dieser Tipps gibt es zusätzlich zum Sarkasmus Schmerzen, die in der Praxis häufig auftreten.
Ich werde der Kapitän von Evidence sein und Ihnen sagen, woran Sie bei der Vorbereitung und Durchführung einer Codeüberprüfung wirklich denken müssen. Überlegungen gelten ferner sowohl für denjenigen, der die Funktion entwickelt, als auch für denjenigen, der sie überprüft. Dies sind jedoch zwei Seiten derselben Medaille.
Ein Konsens in der Kommunikation ist zum einen erreichbar, und zum anderen muss das Projekt voranschreiten. Derzeit können nur wenige Produkte alleine entwickelt werden. Normalerweise ist das Teamwork.
Verwenden Sie gesunden Menschenverstand
Dies ist der wichtigste Rat. Verwenden Sie gesunden Menschenverstand, es lenkt. Es scheint mir, dass dieser Rat für alle Lebenssituationen gilt. Wenn Sie etwas tun, überlegen Sie, ob dies der einfachen Regel des gesunden Menschenverstandes entspricht.
Angenommen, ...
Hier geht es um Kultur. Ich war in mehreren großen Open Source-Communities. Ich weiß nicht, ob dies Teil der russischen Mentalität ist, aber oft wird eine Person, die als Chef wahrgenommen werden kann, gleichzeitig als eine Person wahrgenommen, die zufällig an seinen Platz gefallen ist. Es wird angenommen, dass er dich schlecht will, standardmäßig gibt es Zweifel an seiner Professionalität. Daher ist es bei jeder Arbeit sehr wichtig, mindestens für eine Sekunde davon auszugehen, dass:
- Der Rezensent (Mitwirkender, Ihr Chef oder Kollege) ist nicht Ihr Feind . Er will nicht, dass du schlecht bist. Dies ist eine einfache Annahme, aber oft genug wird sie nicht gemacht. Ich rate ihm, es trotzdem zu tun.
- Die Person, die Ihnen Kommentare schreibt, ist auch ein guter Ingenieur. Sie sind natürlich gut, haben eine solche Funktion gemacht. Aber es gibt viele andere gute Ingenieure auf der Welt. Und derjenige, der Ihnen Kommentare geschickt hat, gilt auch für sie.
- Diese Person möchte auch, dass Ihre Aufgabe erfüllt wird.
Wenn er nach etwas fragt, hat er eine Art Motivation. Er tut es aus einem Grund. Besonders wenn diese Person nicht der erste Tag im Projekt ist. Sicher gibt es einen Grund. Sie können nach diesem Grund fragen: Warum müssen Sie genau das tun? Warum ist hier Abwärtskompatibilität erforderlich? Wenn Sie ruhig und vernünftig einfache Fragen stellen und auf die Antworten hören, können Sie mehr erreichen.
Welchen Wert wird das Produkt bringen?
Die Überprüfung umfasst nicht nur vorgefertigte Patches, sondern auch Projektverbesserungen und Korrekturen. Tatsächlich beginnt die Codeüberprüfung in dem Moment, in dem Sie gerade Ihre Überarbeitung besprechen. Fragen Sie sich an dieser Stelle: Welchen Wert bringt das Produkt für das Produkt?
- Wird es eine neue Funktion sein?
- Ist das eine bestehende Verbesserung?
- Erweiterung einer bestehenden Funktion?
- Wird es Code Refactoring sein? Daran ist nichts auszusetzen. Einige stehen dem Refactoring kritisch gegenüber, aber es ist notwendig. Und Sie müssen sich bewusst sein, dass Sie es tun, und nicht eine neue Funktion oder etwas anderes.
- Beschleunigt es einen Prozess und verbessert es die Leistung?
- Ist das eine Fehlerbehebung?
Es gibt andere Möglichkeiten. Wenn Sie anfangen, etwas zu entwickeln, um ein Problem zu lösen, sollten Sie auf jeden Fall verstehen, welchen Wert Sie dem Projekt hinzufügen werden.
Warum ist die Revision (Funktion) einfach so?
Es gibt eine Reihe nützlicher Fragen.
Warum ein Feature machen? Warum wird diese Funktion benötigt? Die Antwort auf diese Frage ist wichtig.
Wo beginnt die Arbeit? In meiner Praxis wurde ich gebeten, eine bestimmte Anwendung zu wiederholen. Es gibt eine Anwendung A, Sie müssen eine Anwendung B erstellen, die mit geringfügigen Änderungen fast dasselbe tut. Ich beginne mit der Arbeit und es stellt sich heraus, dass A im Grunde nicht funktioniert. Tatsächlich wird es irgendwo in der Produktion über die Mensch-Maschine-Schnittstelle verwendet - das heißt, jemand sitzt und startet das Programm ständig neu, wodurch die Nullzeiger-Ausnahme buchstäblich in der Luft behoben wird. Wo beginnt die Arbeit? In diesem Fall wird das Programm A so repariert, dass es stabil funktioniert, und dann das Programm B geschrieben.
Wo ist der vollständige Abschluss der Arbeiten? Wie soll die geleistete Arbeit ideal aussehen? Es ist wichtig, von Anfang an zu formulieren, wohin Sie gehen.
Wo ist das Ende der aktuellen Phase? Es ist klar, dass Sie einen Elefanten nicht sofort essen können und es ist besser, die Arbeit in Stufen aufzuteilen. Es ist wichtig zu verstehen, wo das Ende der aktuellen Phase liegt. Oft sind Projekte aufgeblasen und enden nicht nur, weil der Umfang des Projekts unendlich groß wird.
Warum ist das Merkmal in solchen Phasen genau defekt? Hier geht es um MVP und all das. Bitte denken Sie auch darüber nach.
Nun zur öffentlichen API
Es gibt viele Artikel über die Eigenschaften der öffentlichen API. Lesen Sie es, bevor Sie es implementieren. Als gutes Beispiel kann ich das JQuery Spring-Framework in Java anführen. Es gibt auch negative Beispiele. Wer seit Jahren in Java programmiert, erinnert sich wahrscheinlich daran, was in Bezug auf die öffentliche API EJB 2.1 schrecklich ist. Die Funktionalität dort mag gut sein, aber wenn die öffentliche API schlecht ist, kann niemand Benutzer davon überzeugen, das Produkt zu verwenden.
Die öffentliche API ist nicht nur ein Tool für Benutzer von Drittanbietern. Dies und die API interner Komponenten, die Sie selbst untereinander wiederverwenden. Wichtige Eigenschaften der öffentlichen API:
- Einfachheit.
- Die Beweise.
- Die richtigen Standardeinstellungen. Es lohnt sich, darüber nachzudenken, wenn Sie beispielsweise in einer Testumgebung wie in der Produktion 500 Threads erstellen. Oder umgekehrt, in der Produktion gibt es standardmäßig 3 Threads, wie in einer Testumgebung.
- Fehlermeldungen löschen. Dies ist die Geißel so vieler Produkte. Wenn etwas in das System fällt, ist nicht klar, was falsch gemacht wird. Gestern hat funktioniert, heute eine Nullzeiger-Ausnahme. Was genau Sie falsch gemacht haben und wie Sie es beheben können, geht aus der Fehlermeldung nicht hervor.
- Es ist schwer, einen Fehler zu machen. Zu diesem Punkt gibt es viele Empfehlungen. Kompilierungszeitprüfungen sind immer besser als Laufzeitprüfungen usw.
- Klare und ausreichende Protokolle. Dies ist besonders wichtig, wenn Sie Code schreiben, der wiederverwendet und irgendwo auf dem Server bereitgestellt wird.
- Die Fähigkeit zu überwachen. Sie müssen verstehen, dass Protokolle und Überwachung auch Teil Ihrer öffentlichen API sind. Beim Parsen von Fehlern sehen Benutzer, wie sich die Metriken verhalten, die Sie bei der Überwachung ausgespuckt haben.
Änderungen am Subsystem
Wenn Sie zur Codeüberprüfung kommen, ist es wichtig, eine vollständige Liste der Systeme und Subsysteme eines großen Produkts im Kopf zu haben, in dem Sie Änderungen vornehmen. In Unternehmensprojekten ist möglicherweise nicht klar: ob es sich um ein Datenbankschema oder einen Controller oder eine Präsentation, eine Art Berichtssystem, Uploads, Downloads usw. handelt.
Wenn Sie mit einem verpackten Produkt arbeiten, ist es wichtig, sich die Frage zu stellen: Wie wirken sich Änderungen auf vorhandene Prozesse im System aus? Gibt es eine Abwärtskompatibilität? Beeinträchtigt es die Leistung? Wenn es beeinflusst, dann die Leistung von was? Wie wirkt sich dies auf die Benutzererfahrung aus?
Standardsystemprozesse
Jedes Geschäftssystem verfügt über Standardprozesse: Start, Installation, eine Liste von Vorgängen. Wie werden sie jetzt fließen? Vor der Codeüberprüfung ist es wichtig, dies zu verstehen. Sie müssen den Code durchgehen, der diese Prozesse implementiert. Im Fall von Ignite ist dies:
- Knotenstart / -stopp (Server / Client, Koordinator / regulär) - Starten, Stoppen eines Knotens, Starten eines Server- oder Clientknotens, Starten eines Koordinators oder eines normalen Knotens
- Node Join - in Bezug auf einen neuen Knoten / Koordinator / Server / Client
- Clusteraktivierung (& Deaktivierung)
- Koordinatorwechsel
- Cache erstellen / löschen
- Persistenz / BLT / MVCC
Es ist klar, dass die Menge dieser Prozesse ziemlich groß ist. Es ist wichtig zu verstehen, dass solche Prozesse existieren und wie sie sich ändern.
Eckkoffer
In Ihrer Geschäftsanwendung können Disaster Recovery, anfängliche Systeminitialisierung, Herunterfahren des Knotens, Neustart, Aktualisieren Ihrer Anwendung und dergleichen auftreten. Im Fall von Ignite haben wir die folgenden Eckfälle:
- Koordinatorwechsel;
- Knotenabfall;
- Netzwerkprobleme - wenn Netzwerknachrichten nicht erreicht werden;
- kaputte Dateien.
Wir müssen diese Dinge überprüfen und verifizieren, dass alles in Ordnung ist.
Gute Codefunktionen
Also kamen wir zum Code. Ich rate Ihnen, nicht faul zu sein und darin zu suchen:
- Einfachheit
- Erweiterbarkeit
- Testbarkeit
- Zuverlässigkeit
- hohe Arbeitsgeschwindigkeit.
Parallelität
Java hat seine eigenen Besonderheiten beim Schreiben von Parallelitätscode. Wenn Sie über ein Geschäftssystem verfügen und dort nur wenig Parallelität besteht, müssen Sie diese Funktionen nicht berücksichtigen. In der Regel wird jedoch eine gewisse Synchronisierung über die Datenbank durchgeführt. In Dingen wie Ignite ist dies etwas komplizierter. Dabei ist nicht nur die Funktionalität des Codes wichtig, sondern auch seine Eigenschaften:
- Wie schwer ist es, Ihr Parallelitätsmodell zu verstehen?
- Gemeinsame Datenstruktur - wie wird ihre Integrität garantiert?
- Schlösser - was und warum?
- Threads - welche Pools werden verwendet? Warum?
- Garantien der Sichtbarkeit von Änderungen - wofür sind sie vorgesehen?
Diese Fragen müssen gestellt werden, bevor der Parallelitätscode überarbeitet wird. Es ist klar, dass diese Liste sehr lange fortgesetzt werden kann.
Leistungstests. Benchmarks
Wenn Sie eine Art System entwickeln, das Clients und Installationen hat, funktioniert es offensichtlich mit einer gewissen Leistung. In der heutigen Welt ist es unmöglich, die Hardwareleistung auf unbestimmte Zeit zu erhöhen. Wir brauchen Tests und Leistungsüberwachung. Bei der Durchführung einer Codeüberprüfung ist es wichtig zu verstehen:
- Sind Leistungstests überhaupt notwendig? Vielleicht ist dies eine Art Verfeinerung, für die keine Leistungstests erforderlich sind?
- Wenn nötig, welches? Es gibt viele Messtechniken und -methoden usw.
- Wo-wie-was muss gemessen werden?
- Welche Benchmarks sind indikativ? Die Anzahl der Knoten? Eisen? Konfiguration entzünden? Die Art der Ladung?
Insgesamt
Insgesamt ist die Codeüberprüfung eine sehr lohnende Praxis. Ich hoffe, dass alle Entwickler (einschließlich Unternehmensprodukte) es bereits zu Hause implementiert haben. Wenn nicht, implementieren Sie dies bitte so schnell wie möglich. Gerne bespreche ich in den Kommentaren die Praktiken zur Codeüberprüfung mit Ihnen.
Video der Vorlesung:Die Präsentation finden Sie hier .