Analyse häufiger Fehler von unerfahrenen Programmierern, Punkt. 1

Hallo Welt! Sobald Sie alles gelernt haben, was Sie wissen müssen, und endlich als Praktikant oder Junior-Entwickler arbeiten können, können Sie sich wahrscheinlich entspannen, oder? Nö. Für dich fängt alles gerade erst an... Du bist von viel Neuem und Unverständlichem umgeben. Wie schafft man es nicht, es gleich von Anfang an zu vermasseln? Darüber werden wir heute sprechen. In diesem Artikel möchte ich häufige Anfängerfehler analysieren und basierend auf meiner eigenen Erfahrung einige Ratschläge geben, wie man sie vermeiden kann. Fangen wir also ohne Umschweife an:

1. Angst davor, Hilfe von erfahreneren Kollegen zu suchen

Wir sind alle Menschen. Wir alle haben Angst, dumm auszusehen, insbesondere in den Augen unserer neuen, erfahreneren Kollegen. Wenn Entwickler ihren ersten Job annehmen, lassen sie sich oft von dieser Angst leiten und ziehen sich mit schwerem Gehör in sich selbst zurück und versuchen, alles selbst herauszufinden. Darüber hinaus kann jemand von erfahreneren Kollegen umgeben sein, die ihn wiederum in die erfolgversprechendste Richtung weisen können und so dazu beitragen, weitere Fehler und unnötige „Stöße auf dem Kopf“ zu vermeiden. Denken Sie also daran: Haben Sie keine Angst, Fragen zu stellen. Du bist ein Anfänger und jeder versteht das vollkommen gut. Wenn du fragst, wird dich niemand mit Stöcken schlagen. Vielleicht passiert sogar das Gegenteil: Sie freunden sich schneller mit Ihren Kollegen an und beginnen, eine aktivere Kommunikation mit ihnen zu genießen. ICH' Ich möchte noch mehr sagen: Je mehr Sie Fragen stellen und verschiedene technische Themen besprechen, desto schneller können Sie Ihre grüne Neulingshaut abstreifen und sich zu einem Experten auf Ihrem Gebiet entwickeln. Und noch ein Ratschlag. Seien Sie kein FremderStackOverflow . Ich spreche speziell davon, Fragen zu dieser Ressource zu stellen. Einerseits dauert es einige Zeit, bis Sie eine Antwort auf Ihre Frage erhalten. Andererseits lernen Sie möglicherweise schnell mehrere Lösungsansätze für Ihr Problem kennen und betrachten es aus einem etwas anderen Blickwinkel. Ich möchte auch anmerken, dass es praktische Vorteile hat, Kommentare/Antworten zu schreiben und klärende Fragen zu StackOverflow-Fragen anderer Entwickler zu schreiben: Sie haben die Möglichkeit, zu diskutieren und tiefer in die Themen einzutauchen, ganz zu schweigen von einem Karma-Schub.

2. Versuchen Sie nicht, selbst nach Informationen zu suchen

Dieser Fehler könnte als die Kehrseite des vorherigen angesehen werden.Damit meine ich, wenn Sie anfangen, Ihre Kollegen und Bekannten wegen jedes Problems oder Schluckaufs zu belästigen, auf den Sie stoßen. Fragen ist gut, aber übertreiben Sie es nicht mit Fragen. Andernfalls könnten die Leute Sie einfach als nervig empfinden. Wenn Sie über etwas verwirrt sind, sollten Sie zunächst Ihre Suchfähigkeiten in der besten Suchmaschine üben – Google. Die überwiegende Mehrheit der unverständlichen Fehler und anderen Probleme ist bereits jemand anderem begegnet. Und Sie werden überrascht sein, wenn Sie Ihre Frage googeln und sehen, wie viele Menschen mit einem ähnlichen Problem vertraut sind und bereits ausführliche Antworten erhalten haben, die Sie in Ihrer eigenen Arbeit anwenden können. Deshalb werden Sie von Ihren Kollegen oft die Antwort „Google it“ hören. Anziehen' Lassen Sie sich von dieser Antwort nicht beleidigen – Ihr Kollege ist nicht Ihr persönlicher Lehrer, der alle Feinheiten Ihres Arbeitsgebiets vermitteln muss. Die endlosen Weiten des Internets werden Ihr Mentor sein. Manchmal werden auch Programmierer als bezeichnetPersonen mit schwarzem Gürtel in der Google-Suche . Wenn wir also einen „Schluckauf“ haben, googlen wir zunächst das Problem. Wenn keine Lösung gefunden werden kann (das ist selten, aber es kommt vor), fragen wir erst dann die Kollegen. Bei Sofortfragen geht es eher darum, Ratschläge zu erhalten, welchen Ansatz Sie zur Lösung eines Problems wählen sollten, als das, was Sie tun würden, wenn Sie auf eine Geschwindigkeitsbegrenzung oder eine unverständliche Fehlermeldung stoßen. Schließlich sind sie möglicherweise in der Lage, über Ihren bevorzugten Ansatz hinauszuschauen und sofort vorherzusagen, wohin ein bestimmter Ansatz auf lange Sicht führen wird.

3. Blindes Kopieren und Einfügen

Aber das Googeln von Problemen und deren Lösungen hat seine Tücken. Zum Beispiel blindes Kopieren und Einfügen .Dies geschieht normalerweise, wenn Sie ein ähnliches Problem (aber möglicherweise nicht genau dasselbe) und eine zugehörige Lösung finden, beispielsweise auf StackOverflow. Sie greifen zu dieser Lösung, kopieren sie und fügen sie ein, ohne sich weiter mit den Details zu befassen. Und dann entdecken Sie oder Ihre Kollegen seltsame Fehler oder falsches Verhalten in Ihrem Code. Und niemand kann sofort erraten, woher sie kommen. Irgendwann wird natürlich die Stelle mit dem kopierten Code gefunden und Sie werden für Ihre Lösung auf keinen Fall gelobt. Wenn Sie daher auf StackOverflow (oder anderswo) eine fertige Lösung finden, müssen Sie zunächst gründlich verstehen, was, wie und warum. Googeln Sie vielleicht die entsprechende Funktionalität und lesen Sie die Dokumentation dazu. Und erst nachdem Sie das getan haben, sollten Sie es Ihrem Projekt hinzufügen.

4. Bei der falschen Lösung bleiben

Wenn Sie eine Lösung schreiben, werden Sie manchmal feststellen, dass diese immer komplizierter wird und schließlich in einer Sackgasse endet. Und dann versucht man, die Lösung noch aufwändiger zu gestalten, damit sie irgendwie funktioniert, anstatt nach einer anderen, passenderen Alternative zu suchen. Vielleicht haben Sie das Gefühl, dass Sie viel Zeit und Mühe investiert haben und deshalb beschlossen haben, dass Sie auf keinen Fall aufgeben und das Problem mit Ihrem bisherigen Ansatz lösen werden. Das ist nicht ganz die richtige Einstellung. Zumindest in der Programmierung. Je früher Sie einen anderen Ansatz ausprobieren, desto mehr Zeit sparen Sie am Ende. Scheuen Sie sich also nicht, zu experimentieren und andere Ansätze auszuprobieren, unabhängig davon, wie viel Zeit Sie in Ihren aktuellen Ansatz investiert haben. Darüber hinaus können Sie durch das Ausprobieren mehrerer Ansätze und das tiefere Eintauchen in das Thema

5. Angst davor, Fragen zu Ihrer aktuellen Aufgabe zu stellen

Bei der Arbeit an einem Softwareentwicklungsprojekt geht es in der Regel darum, bestimmte Aufgaben auszuführen. Zum Beispiel in Jira. Diese Aufgaben sind nicht immer klar und detailliert umrissen. Aufgabenbeschreibungen werden in der Regel von Teamleitern verfasst, die ebenfalls Normalsterbliche sind. Möglicherweise vergessen sie, etwas hinzuzufügen, oder berücksichtigen nicht, dass Sie mit dieser oder jener Funktionalität nicht vertraut sind. Oder Sie haben möglicherweise keinen Zugriff auf das Projekt (z. B. Zugriff auf die Datenbank, den Protokollserver usw.). Und jetzt haben Sie die Aufgabe erhalten, sie mehr als ein paar Stunden lang studiert, aber Sie sitzen immer noch da und starren verwirrt auf den Bildschirm. Anstatt weiterhin erfolglos zu versuchen, dies zu verstehen, sollten Sie anfangen, denjenigen, der die Aufgabe erstellt hat, um Klarstellung oder Rat zu bitten. Beispielsweise können Sie in der App, die Ihr Team zur Kommunikation nutzt (z. B. Microsoft Teams), Fragen stellen oder einen direkten Kommentar zur Aufgabe abgeben. Wenn Sie Ihre Frage einerseits in einer persönlichen Nachricht schreiben, erhalten Sie wahrscheinlich schneller eine Antwort, da die Person Ihre Frage sofort sieht. Andererseits erbringen Sie durch das Stellen einer Frage in Jira den Beweis, dass Sie etwas tun, nämlich das Problem analysieren. Es gibt eine Möglichkeit, diesen Prozess zu beschleunigen: Stellen Sie Ihre Frage in einem Kommentar in Jira und fügen Sie dann in einer DM einen Link zu Ihrem Kommentar ein und bitten Sie darum, einen Blick darauf zu werfen.

6. Unrealistisch hohe Erwartungen an die Teamleitung stellen

Auch dies ist die Kehrseite des vorherigen Punktes. Der Teamleiter ist der Leiter eines Entwicklungsteams. In der Regel verbringt Ihr Teamleiter die meiste Zeit mit verschiedenen Arten der Kommunikation. Allerdings schreibt er oder sie auch Code, um nicht alles über das Programmieren zu vergessen. Wie Sie verstehen können, ist das Leben eines Teamleiters sehr arbeitsreich. Es wird offensichtlich nicht angenehm sein, jedes Mal, wenn Sie niesen müssen, am Ärmel Ihres Teamleiters zu ziehen. Stellen Sie sich vor, dass jedes Teammitglied den Lead mit einer Reihe von Fragen bombardiert. Das könnte jeden verrückt machen, oder? Und wenn Sie viele Fragen stellen, muss Ihr Teamleiter viel Zeit damit verbringen, Ihnen zu antworten. Was kann getan werden, um die Anzahl der an den Teamleiter gerichteten Fragen zu reduzieren:

• Sehen Sie sich die Projektdokumentation genauer an, um die Anzahl blinder Flecken zu reduzieren.
• Richten Sie Ihre Fragen an Ihre anderen Teammitglieder. Sie sind mit dieser Funktionalität möglicherweise genauso vertraut wie der Lead oder möglicherweise sogar noch besser, da die Funktionalität höchstwahrscheinlich von einem von ihnen geschrieben wurde.

Alternativ können Sie sich die Anmerkungen in der IDE ansehen, um zu erfahren, wer und wann der Code in einer bestimmten Zeile zuletzt geändert wurde. So können Sie herausfinden, wer für Ihre Frage am besten geeignet ist. Wie Sie wahrscheinlich bereits wissen, müssen Sie bei Fragen an den Teamleiter, genau wie bei Fragen an Kollegen, versuchen, einen guten Mittelweg zu finden – haben Sie keine Angst, Fragen zu stellen, aber stellen Sie auch nicht zu viele von ihnen.

7. Angst vor Codeüberprüfungen

Eine CodeüberprüfungDies ist eine solche Phase, die stattfindet, bevor Sie Ihren Code an eine gemeinsame Anwendung senden (an einen gemeinsam genutzten Zweig, z. B. Master oder Dev). Diese Prüfung wird von einem Entwickler durchgeführt, der nicht an der Aufgabe beteiligt ist und mit seinem frischen Blick Fehler, Ungenauigkeiten oder Mängel in Ihrem Codestil erkennen kann, die beim ersten Schreiben Ihres Codes unbemerkt geblieben sind. Wenn es Kritik gibt, werden diese als Kommentare zu bestimmten Teilen des Codes hinterlassen. In diesem Fall muss der Entwickler, der den Code geschrieben hat, die in der Überprüfung festgestellten Fehler korrigieren (oder seine Entscheidungen mit dem Prüfer besprechen und ihn möglicherweise davon überzeugen, dass sie richtig sind). Anschließend wird der Code immer wieder zur Überprüfung eingereicht, bis der Prüfer keine Kommentare mehr hat. Der Prüfer fungiert als „Gateway“, bevor der Code festgeschrieben wird. Die Herausforderung besteht darin, dass viele unerfahrene Programmierer die Codeüberprüfung als Kritik und Verurteilung empfinden. Sie schätzen Codeüberprüfungen nicht und haben Angst davor. Das sollten sie nicht. Codeüberprüfungen sind genau das, was uns ermöglicht, unseren Code zu verbessern. Schließlich erhalten wir wichtige Informationen darüber, was wir falsch machen und worauf es sich zu achten lohnt. Sie sollten jede Codeüberprüfung als Teil der Lernkurve betrachten, die Ihnen dabei helfen kann, besser zu werden. Wenn jemand Ihren Code kommentiert, teilt er oder sie Erfahrungen und Best Practices mit Ihnen. Ich persönlich glaube nicht, dass man ein guter Programmierer werden kann, ohne Code-Reviews zu bekommen. Denn Sie wissen gar nicht, wie gut Ihr Code ist und ob ein erfahrener Außenstehender auf Fehler hinweisen würde. Ich schätze Codeüberprüfungen nicht und habe Angst davor. Das sollten sie nicht. Codeüberprüfungen sind genau das, was uns ermöglicht, unseren Code zu verbessern. Schließlich erhalten wir wichtige Informationen darüber, was wir falsch machen und worauf es sich zu achten lohnt. Sie sollten jede Codeüberprüfung als Teil der Lernkurve betrachten, die Ihnen dabei helfen kann, besser zu werden. Wenn jemand Ihren Code kommentiert, teilt er oder sie Erfahrungen und Best Practices mit Ihnen. Ich persönlich glaube nicht, dass man ein guter Programmierer werden kann, ohne Code-Reviews zu bekommen. Denn Sie wissen gar nicht, wie gut Ihr Code ist und ob ein erfahrener Außenstehender auf Fehler hinweisen würde. Ich schätze Codeüberprüfungen nicht und habe Angst davor. Das sollten sie nicht. Codeüberprüfungen sind genau das, was uns ermöglicht, unseren Code zu verbessern. Schließlich erhalten wir wichtige Informationen darüber, was wir falsch machen und worauf es sich zu achten lohnt. Sie sollten jede Codeüberprüfung als Teil der Lernkurve betrachten, die Ihnen dabei helfen kann, besser zu werden. Wenn jemand Ihren Code kommentiert, teilt er oder sie Erfahrungen und Best Practices mit Ihnen. Ich persönlich glaube nicht, dass man ein guter Programmierer werden kann, ohne Code-Reviews zu bekommen. Denn Sie wissen gar nicht, wie gut Ihr Code ist und ob ein erfahrener Außenstehender auf Fehler hinweisen würde. Was man falsch macht und worauf man achten sollte. Sie sollten jede Codeüberprüfung als Teil der Lernkurve betrachten, die Ihnen dabei helfen kann, besser zu werden. Wenn jemand Ihren Code kommentiert, teilt er oder sie Erfahrungen und Best Practices mit Ihnen. Ich persönlich glaube nicht, dass man ein guter Programmierer werden kann, ohne Code-Reviews zu bekommen. Denn Sie wissen gar nicht, wie gut Ihr Code ist und ob ein erfahrener Außenstehender auf Fehler hinweisen würde. Was man falsch macht und worauf man achten sollte. Sie sollten jede Codeüberprüfung als Teil der Lernkurve betrachten, die Ihnen dabei helfen kann, besser zu werden. Wenn jemand Ihren Code kommentiert, teilt er oder sie Erfahrungen und Best Practices mit Ihnen. Ich persönlich glaube nicht, dass man ein guter Programmierer werden kann, ohne Code-Reviews zu bekommen. Denn Sie wissen gar nicht, wie gut Ihr Code ist und ob ein erfahrener Außenstehender auf Fehler hinweisen würde.

8. Neigung zu obskuren Entscheidungen

Verschiedene Aufgaben/Probleme können oft mehrere unterschiedliche Lösungen haben. Und von allen verfügbaren Lösungen neigen Anfänger dazu, die komplexesten und geheimnisvollsten zu verwenden. Und das macht Sinn: Erst gestern haben unerfahrene Programmierer viele verschiedene Algorithmen, Muster und Datenstrukturen gelernt, sodass es ihnen kaum noch in den Fingern liegt, einige davon umzusetzen. Glauben Sie mir, ich war so, also weiß ich, wovon ich rede :) Ich hatte eine Situation, in der ich über einen längeren Zeitraum hinweg einige Funktionen implementiert habe. Es stellte sich als sehr, sehr kompliziert heraus. Dann hat der leitende Entwickler meinen Code neu geschrieben. Natürlich war ich sehr gespannt, was und wie er es verändert hat. Ich habe mir seine Umsetzung angeschaut und war erstaunt, wie viel einfacher es war. Und es gab dreimal weniger Code. Und erstaunlicherweise wurden die automatisierten Tests für diese Funktionalität weder entfernt noch geändert! Mit anderen Worten, die allgemeine Logik blieb dieselbe. Daraus bin ich zu dem Schluss gekommen, dassDie genialsten Lösungen sind immer einfach . Nach dieser Erkenntnis wurde das Codieren viel einfacher und meine Codequalität sprang auf ein deutlich höheres Niveau. Wann lohnt es sich dann, Designmuster und ausgefallene Algorithmen anzuwenden? Bei der Anwendung handelt es sich um die einfachste und kompakteste Lösung.

9. Das Rad neu erfinden

Das Rad ist eine langlebige Lösung, die vor langer Zeit erfunden wurde. Bei diesem Anti-Pattern implementiert der Entwickler seine eigene proprietäre Lösung für ein bereits gelöstes Problem. Manchmal sind diese vorhandenen Lösungen besser als das, was der Programmierer vorschlägt. Das Rad neu zu erfinden führt in der Regel zu Zeitverlust und verminderter Produktivität, da die Lösung, die Sie finden, möglicherweise bei weitem nicht die beste ist, oder, nun ja, Sie finden überhaupt keine. Allerdings können wir die Möglichkeit nicht ausschließen, eine eigene, unabhängige Lösung zu entwickeln: Wenn wir das täten, bliebe nur noch die Programmierung durch Kopieren und Einfügen. Der Programmierer sollte sich richtig an den konkret anfallenden Programmieraufgaben orientieren, um diese kompetent und zeitnah zu lösen, sei es durch die Verwendung vorgefertigter Lösungen oder durch die Erstellung individueller Lösungen. Einerseits, An Universitäten und in Online-Kursen werden wir mit Aufgaben unterschiedlichster Art bombardiert, die scheinbar darauf abzielen, uns dabei zu helfen, das Rad neu zu erfinden. Aber nur auf den ersten Blick: Der eigentliche Zweck besteht darin, algorithmisches Denken zu entwickeln und die Syntax der Sprache besser zu beherrschen. Solche Aufgaben helfen Ihnen auch, Algorithmen und Datenstrukturen besser zu verstehen, und vermitteln Ihnen die Fähigkeit, bei Bedarf komplexere Gegenstücke zu implementieren (dies ist manchmal notwendig, aber äußerst selten). Im wirklichen Leben müssen Sie in den allermeisten Fällen kein eigenes Rad erfinden, denn Räder, die Ihren Bedürfnissen entsprechen, gibt es schon lange. Möglicherweise ist es Ihnen aufgrund Ihrer Unerfahrenheit nicht möglich, über die Existenz von Implementierungen der von Ihnen benötigten Funktionalität Bescheid zu wissen. Hier müssen Sie den Rat aus dem ersten Punkt dieses Artikels beherzigen, nämlich: Bitten Sie erfahrenere Kollegen um Hilfe. Sie können Sie weiterleiten (z. B. in Ihrer Google-Suche in die richtige Richtung weisen) oder eine bestimmte Implementierung vorschlagen (z. B. eine Bibliothek).

10. Fehler beim Schreiben von Tests

Alle Neulinge mögen es nicht, Tests zu schreiben. Aber warum sollten wir hier Neulinge hervorheben? Erfahrenere Entwickler schreiben auch nicht gerne Tests, verstehen aber besser, warum Tests erforderlich sind. Wenn Sie völlig grün sind, fragen Sie sich, warum Sie sie schreiben sollten. Alles funktioniert, es können also keine Fehler passieren. Aber wie stellen Sie sicher, dass Ihre Änderungen nicht an anderer Stelle im System kaputt gehen? Ihre Kollegen werden es nicht zu schätzen wissen, wenn Sie Veränderungen vorantreiben, die mehr schaden als nützen. Hier helfen uns Tests. Je mehr der Code einer Anwendung durch Tests abgedeckt wird, desto besser (dies wird als Codeabdeckung oder Testabdeckung bezeichnet). Wenn die Anwendung über eine gute Testabdeckung verfügt, können Sie alle Tests ausführen, um Stellen zu finden, die durch Ihren Code unterbrochen werden. Und wie ich im obigen Beispiel sagte, Als der leitende Entwickler den Code umgestaltete, schlugen die Tests nicht fehl. Dies lag daran, dass sich die allgemeine Logik nicht änderte. Mithilfe von Tests zeigen wir, ob sich die Logik einer bestimmten Funktionalität geändert hat oder nicht. Auch wenn Sie nicht gerne Tests schreiben, sind sie auf jeden Fall nützlich und die dafür aufgewendete Zeit auf jeden Fall wert.

11. Übermäßige Kommentare

Viele Entwickler leiden unter Perfektionismus und Neulinge bilden da keine Ausnahme. Manchmal zeigen sie nur eine Facette dieser Neigung, wenn sie beginnen, alles und jeden zu kommentieren. Sogar unnötige Kommentare abgeben, weil der Code so offensichtlich ist:

Cat cat = new Cat(); // Cat object

Nicht alle unerfahrenen Programmierer erkennen sofort, dass das Kommentieren von Code nicht immer gut ist, da die überflüssigen Kommentare den Code unübersichtlich machen und ihn schwer lesbar machen. Und was ist, wenn sich der Code ändert, die alten Kommentare jedoch nicht aktualisiert werden? Dann werden sie uns nur irreführen und verwirren. Warum also überhaupt einen solchen Kommentar abgeben? Normalerweise muss gut geschriebener Code nicht kommentiert werden , da alles darin bereits offensichtlich und lesbar ist. Wenn Sie einen Kommentar schreiben müssen, haben Sie die Lesbarkeit des Codes bereits beeinträchtigt und versuchen, die Situation irgendwie zu beheben. Der beste Ansatz besteht darin, von Anfang an lesbaren Code zu schreiben, also Code, der keine Kommentare benötigt. Ich kann auch nicht umhin, die Notwendigkeit zu erwähnen, korrekte Namenskonventionen für Methoden, Variablen und Klassen einzuhalten. Hier ist meine Regel: Der beste Kommentar ist entweder kein Kommentar oder eine korrekte Benennung , die die Funktionalität in Ihrer Anwendung klar beschreibt.

12. Schlechte Namensgebung

Neulinge gehen schnell und locker mit der Benennung von Klassen, Variablen, Methoden usw. um, indem sie beispielsweise eine Klasse erstellen, deren Name überhaupt nicht ihren Zweck beschreibt. Oder sie deklarieren eine Variable mit einem Kurznamen, etwa x . Sie sind zwei weitere Variablen mit den Namen n und yerstellt werden, wird es sehr schwierig, sich daran zu erinnern, wofür x verantwortlich ist. Angesichts dieser Situation müssen Sie sorgfältig über den Code nachdenken, ihn unter einem Mikroskop analysieren (vielleicht mit einem Debugger) und die Funktionalität studieren, um einfach zu verstehen, was passiert. Hier helfen uns die korrekten Namenskonventionen, die ich oben erwähnt habe. Korrekte Namen verbessern die Lesbarkeit des Codes und verkürzen so die Einarbeitungszeit, da die Verwendung einer Methode wesentlich einfacher ist, wenn der Name ihre Funktionalität annähernd beschreibt. Alles im Code besteht aus Namen (Variablen, Methoden, Klassen, Objekte, Dateien usw.), daher ist dieser Punkt sehr wichtig, wenn es darum geht, korrekten, sauberen Code zu erstellen. Sie sollten bedenken, dass der Name eine Bedeutung vermitteln sollte, zum Beispiel, warum die Variable existiert, was sie tut, und wie es verwendet wird. Ich werde mehr als einmal darauf hinweisen, dass der beste Kommentar für eine Variable darin besteht, ihr einen guten Namen zu geben. Für ein tieferes Studium der Kommentare und der richtigen Benennung empfehle ich die Lektüre der zeitlosen Klassiker:„Clean Code: A Handbook of Agile Software Craftsmanship“ von Robert Martin . In diesem Sinne ist der erste Teil dieses Artikels (meine Überlegungen) zu Ende. Fortgesetzt werden...