Ich arbeite jetzt seit anderthalb Jahren als App-Entwickler (ich weiß es nicht lange) und habe gerade mein erstes großes Projekt erhalten.

Unnötig zu erwähnen, dass es nicht sehr reibungslos verlief, und ich bat einen erfahrenen Programmierer, der an dem Projekt beteiligt war, um Rat, wie ich es angehen sollte.

Er sagte, ich habe die anstehende Aufgabe drastisch überdacht, und weil ich noch nie ein Projekt dieser Größenordnung in Angriff genommen hatte, bevor ich zu viel Zeit damit verbracht hatte, über Entwurfsmuster nachzudenken. In seinen weisen Worten sagte er zu mir: "Fick die Zukunft, baue für jetzt".

Ist dies ein Trend, dem Programmierer normalerweise folgen, wenn sie ein Projekt wie dieses durchführen? Wenn Sie zum Beispiel gebeten wurden, ein Proof-of-Concept-Modell zu erstellen, ist es ein typischer Trend, ein praktikables Beispiel so schnell wie möglich zusammenzustellen?

Edit: In Anbetracht der Debatte, die dies ausgelöst hat, möchte ich erwähnen, dass diese Situation ziemlich extrem ist: Wir haben sehr enge Fristen aufgrund von Faktoren, die außerhalb unserer Kontrolle liegen (dh der Markt, den wir anstreben, wird das Interesse verlieren, wenn wir nichts tun zeigen ihnen nichts) und sein Rat erwies sich für diese spezielle Aufgabe als sehr wirksam.

Captain Offensichtlich zur Rettung!

Ich werde hier Captain Obvious sein und sagen, dass es einen Mittelweg gibt, der gefunden werden kann.

Sie möchten für die Zukunft bauen und sich nicht auf eine technologische Entscheidung oder ein schlechtes Design festlegen. Sie sollten jedoch nicht 3 Monate damit verbringen, etwas zu entwerfen, das einfach sein sollte, oder Erweiterungspunkte für eine schnelle und schmutzige App hinzufügen, die eine Lebensdauer von 2 Jahren hat und wahrscheinlich keine Folgeprojekte hat.

Es ist schwierig, den Unterschied zu finden, da Sie den Erfolg Ihres Produkts nicht immer vorhersagen können und es später erweitern müssen.

Fürs Erste bauen, wenn ...

• Das Projekt wird ausrangiert
• Das Projekt hat eine kurze Lebensdauer
• Das Projekt sollte keine Erweiterungen haben
• Das Projekt hat keinen Risikoauswirkungswert (hauptsächlich in Bezug auf das Image)

Im Allgemeinen sollten für den Moment Inhouse-Projekte oder etwas, das für einen Kunden gebaut wurde, entwickelt werden. Stellen Sie sicher, dass Sie klare Anforderungen haben, und beziehen Sie sich nach Bedarf darauf, um zu wissen, was benötigt wird und was nicht. Sie möchten nicht zu viel Zeit mit etwas verbringen, das "schön zu haben" ist. Aber codiere auch nicht wie ein Schwein.

Lassen Sie das allgemeine Problem für später, falls es jemals notwendig und die Mühe wert sein sollte:

Bauen für die Zukunft, wenn ...

• Das Projekt wird öffentlich sein
• Das Projekt ist eine Komponente, die wiederverwendet werden muss
• Das Projekt ist ein Sprungbrett für andere Projekte
• Das Projekt wird Folgeprojekte oder Service-Releases mit Verbesserungen enthalten

Wenn Sie für etwas Öffentliches bauen oder das in anderen Projekten wiederverwendet wird, ist die Wahrscheinlichkeit sehr viel höher, dass Sie von einem schlechten Design heimgesucht werden, und Sie sollten dem mehr Aufmerksamkeit schenken. Dies ist jedoch nicht immer garantiert.

Richtlinien

Ich würde sagen, halten Sie sich so gut wie möglich an die folgenden Grundsätze, und Sie sollten sich in die Lage versetzen, effiziente und anpassungsfähige Produkte zu entwerfen:

• weiß, dass YAGNI ,
• KISS ,
• Schreiben Sie es auf, wenn Sie Lust auf Juckreiz haben und sich eine Ergänzung überlegen. Schauen Sie sich Ihre Projektanforderungen noch einmal an und fragen Sie sich, ob Ergänzungen Vorrang haben oder nicht. Fragen Sie, ob sie den primären Geschäftswert steigern oder nicht.

Ich weiß, dass ich persönlich dazu neige, nachzudenken und zu überdenken. Es ist wirklich hilfreich, Ideen aufzuschreiben und sehr oft darüber nachzudenken, ob ich zusätzliche Funktionen benötige. Oft lautet die Antwort "Nein" oder "es wäre später cool". Diese letzten Ideen sind gefährlich, weil sie in meinem Hinterkopf bleiben und ich mich zwingen muss, sie nicht zu planen.

Der beste Weg, Code zu schreiben, ohne zu überarbeiten und ohne sich für später zu blockieren, besteht darin, sich auf ein gutes minimales Design zu konzentrieren. Brechen Dinge nach unten schön wie Komponenten , die Sie später erweitern können, aber ohne denken bereits darüber , wie sie können später erweitert werden. Sie können die Zukunft nicht vorhersagen.

Bauen Sie einfach einfache Dinge.

Dilemmata

Überentwicklung

Ist dies ein Trend, dem Programmierer normalerweise folgen, wenn sie ein Projekt wie dieses durchführen?

Hölle ja. Es ist ein bekanntes Dilemma und zeigt nur, dass Sie sich für das Produkt interessieren. Wenn nicht, ist das besorgniserregender. Es besteht Uneinigkeit darüber, ob weniger immer wirklich mehr und ob schlechter immer wirklich besser ist . Du bist vielleicht ein Typ vom MIT oder aus New Jersey . Hier gibt es keine einfache Antwort.

Prototyping / Quick-n-Dirty / Weniger ist mehr

Ist es ein typischer Trend, einfach so schnell wie möglich ein brauchbares Beispiel herauszubringen?

Es ist eine weit verbreitete Praxis, aber es ist nicht so, wie die überwiegende Mehrheit der Projekte angegangen wird. Trotzdem ist Prototyping meiner Meinung nach ein guter Trend, aber einer mit einem kleinen Nachteil. Es kann verlockend sein, schnelle und schmutzige Prototypen für tatsächliche Produkte zu fördern oder sie als Basis für tatsächliche Produkte unter Managementdruck oder Zeitbeschränkungen zu verwenden. Dann kann das Prototyping zurückkehren und Sie verfolgen.

Das Prototyping bietet offensichtliche Vorteile , aber auch ein großes Potenzial für Missbrauch und Missbrauch (viele davon sind genau umgekehrt zu den zuvor aufgeführten Vorteilen).

Wann sollte Prototyping eingesetzt werden?

Es gibt Hinweise zu den besten Projekttypen für die Verwendung von Prototypen :

[...] Prototyping ist am vorteilhaftesten in Systemen, die viele Interaktionen mit den Benutzern haben.

[...] Prototyping ist sehr effektiv bei der Analyse und dem Entwurf von Online-Systemen, insbesondere für die Transaktionsverarbeitung, bei der die Verwendung von Bildschirmdialogen viel deutlicher wird. Je stärker die Interaktion zwischen Computer und Benutzer ist, desto größer ist der Nutzen [...]

"Eine der produktivsten Anwendungen des Rapid Prototyping war bisher das iterative User Requirements Engineering und das Design von Mensch-Computer-Schnittstellen."

Auf der anderen Seite:

Systeme mit geringer Benutzerinteraktion, z. B. Stapelverarbeitung oder Systeme, die hauptsächlich Berechnungen ausführen, profitieren nur wenig vom Prototyping. Manchmal ist die für die Ausführung der Systemfunktionen erforderliche Codierung zu intensiv und die potenziellen Vorteile, die Prototyping bieten kann, sind zu gering.

Und wenn Sie ein grünes Monster in der Nähe haben, stellen Sie sicher, dass Sie einen Prototypen im Budget behalten ...

Wenn Sie mit dem Programmieren beginnen, ist alles ein Proof of Concept, auch wenn es nur für Sie selbst ist. Es gibt Fälle, in denen eine Idee etwas schnelles und schmutziges oder einen Prototyp erfordert, weil Zeit ein Schlüsselfaktor ist. Die große Angst unter den Entwicklern ist, dass die Stakeholder glauben, die kleine App sei für die Produktion bereit, oder Sie sollten in der Lage sein, Funktionen für immer mit der gleichen Rate hinzuzufügen. Sie arbeiten an einem großen Projekt und stellen fest, dass dies nicht der Fall ist.

Bei großen Projekten sind die Anforderungen in der Regel komplexer. Daher besteht die Versuchung, komplexe Entwürfe zu implementieren. Sie werden viel Zeit damit verbringen, zu lesen, zu recherchieren und zu versuchen, sie umzusetzen. Dies kann eine große Zeitverschwendung sein, aber es ist alles Teil des Lernens und Sammelns von Erfahrung. Zu wissen, wann ein bestimmtes Design zu verwenden ist, ist schwierig und bringt normalerweise Erfahrung mit. Ich habe "das" bei "diesem" Projekt versucht und es hat nicht funktioniert, aber jetzt sehe ich, dass es "hier" funktionieren sollte.

Man muss viel planen, aber nicht alles auf einmal. Es muss definitiv nicht alles am Anfang gemacht werden. Ich würde lieber jemanden sehen, der sein erstes großes Projekt so erstellt:

1. Entwerfe und diskutiere ein bisschen.
2. Schreiben Sie eine Menge Code, der etwas bewirkt.
3. Erkennen Sie die Probleme und stoppen Sie die Codierung.
4. Machen Sie sich ernsthaft Gedanken über das Design und machen Sie sich keine Gedanken mehr über den Verlust des Schwungs oder Ihres Code-Mojo und ignorieren Sie den Projektmanager (Sie tun ihm einen Gefallen.).
5. Holen Sie sich das Projekt unter Kontrolle. Repariere deine Unordnung. Stellen Sie sicher, dass jeder den Plan versteht. Behalten Sie das Projekt unter Kontrolle.

Manchmal stößt du auf eine dieser Funktionen, die dich wirklich beunruhigt, wie du sie in der vorhandenen Codebasis implementieren kannst. Dies ist nicht die Zeit, "es einfach zum Laufen zu bringen". Ich hatte einen Chef, der sagte: "Manchmal muss man sich statt eines Hammers einen Hocker schnappen." Er erzählte mir das, nachdem er mich an meinem Schreibtisch beim "Nachdenken" erwischt hatte. Im Gegensatz zu vielen anderen Chefs ging er nicht davon aus, dass ich verarscht war, und stellte sicher, dass ich verstand, dass er wollte, dass ich mehr davon mache. Genius.

Letztendlich ist Ihr Code das Design. Es wird von Dokumenten, Diagrammen, Besprechungen, E-Mails, Whiteboard-Diskussionen, SO-Fragen, Argumenten, Beschimpfungen, Wutanfällen und leisen Chats beim Kaffee unterstützt. Es gibt einen Punkt, an dem Sie nicht mehr entwerfen können und aufgrund der Fehler, die Sie nur beim Schreiben des Codes entdecken werden, die Gefahr besteht, dass Sie mehr Entwurfszeit verlieren. Je mehr Code Sie schreiben, desto größer ist die Wahrscheinlichkeit, dass Sie einen Konstruktionsfehler feststellen, aus dem Sie nicht herauskommen können. Es ist wieder Zeit für den Hocker.

Bauen Programmierer normalerweise etwas, das jetzt funktioniert, ohne an die Zukunft zu denken?

Ja.

Sollten sie das tun?

Nein.

Auf den ersten Blick scheint das "Nachdenken über die Zukunft" gegen etablierte Gestaltungsprinzipien wie KISS und YAGNI zu verstoßen , die besagen , dass nichts implementiert werden sollte, was derzeit nicht erforderlich ist.

Tatsächlich aber nicht. An die Zukunft denken heißt, einfache, erweiterbare und verwaltbare Software zu entwerfen. Dies ist besonders wichtig für langfristige Projekte. Mit der Zeit werden neue Funktionen erforderlich sein, und ein solides Design erleichtert das Hinzufügen neuer Teile.

Auch wenn Sie nach Abschluss eines Projekts nicht mehr daran arbeiten, sollten Sie es dennoch intelligent entwickeln. Es ist deine Arbeit, und du solltest es gut machen, zumindest um nicht zu vergessen, wie gut die Arbeit gemacht wird.

Agile Entwickler haben das Sprichwort "Sie werden es nicht brauchen (YAGNI)", das Sie ermutigt, für das zu entwerfen, was Sie jetzt brauchen, anstatt für das, was Sie in Zukunft vielleicht brauchen. Um ein Design für die Zukunft zu erweitern, wird die Umgestaltung empfohlen.

Der wichtige Aspekt dabei ist, die Anforderungen an Ihr Produkt beim Entwerfen im Kopf zu behalten und sicherzustellen, dass Sie nicht für eine Reihe von Anforderungen planen, die in Zukunft möglicherweise auftreten werden.

Für Entwickler, die zwei oder drei Iterationen vorausdenken können, ist etwas zu sagen: Sie kennen ihre Kunden oder die Domäne so gut, dass sie zukünftige Anforderungen mit einem hohen Maß an Genauigkeit vorhersehen und für sie bauen können. Wenn Sie sich jedoch nicht sicher sind, Es ist am besten, nicht zu viel Zeit mit Dingen zu verbringen, die Sie oder die Kunden nicht benötigen.

Ist dies ein Trend, dem Programmierer normalerweise folgen, wenn sie ein Projekt wie dieses durchführen?

Ich vermute, Ihr Mentor hat gemeint, dass Sie keine zusätzliche Komplexität einbauen sollten, die für die endgültige Lösung möglicherweise nicht erforderlich ist.

Es ist allzu leicht zu denken, dass eine App dies und das tun und massiv abgelenkt werden sollte.

Bei Designmustern ist zu beachten, dass sie Mittel zum Zweck sind. Wenn Sie mit der Erfahrung feststellen, dass ein bestimmtes Designmuster trotz Ihrer früheren Vermutung nicht passt, kann dies auf einen Codegeruch hinweisen.

Wenn Sie zum Beispiel gebeten wurden, ein Proof-of-Concept-Modell zu erstellen, ist es ein typischer Trend, ein praktikables Beispiel so schnell wie möglich zusammenzustellen?

Es lohnt sich, sich vor Projektbeginn einen Überblick zu verschaffen, welche Meilensteine ​​es gibt und ob sie ein bisschen von allem sehen möchten (vertikaler Schnitt) oder nur jedes Teil im Detail, während Sie es entwickeln (horizontaler Schnitt). Als Teil des anfänglichen Designs empfinde ich es als lohnenswert, die gesamte App mit einer Story zu versehen. Obwohl der Code nicht geschrieben ist, können Sie einen Hubschrauberblick über das Ganze oder einen tiefen Tauchgang in einem bestimmten Gebiet machen.

Er sagte, ich hätte die anstehende Aufgabe drastisch überdacht, und weil ich noch nie ein so großes Projekt in Angriff genommen hätte, hätte ich zu viel Zeit damit verbracht, über Designmuster nachzudenken. In seinen weisen Worten sagte er zu mir: "Fick die Zukunft, baue für jetzt".

Ich denke, das ist eine Art Cowboy-Mentalität vom anderen Entwickler. Die moderne Version eines harten Nerds, der es einfach "jetzt" macht. Es ist zu einem beliebten Thema bei Start-ups geworden und vielen Leuten von Facebook sei Dank, dass sie den Satz "Es ist besser, es zu schaffen, als es richtig zu machen" eingeführt haben.

Es ist ansprechend. Es ist ermutigend und bietet Visionen von Entwicklern, die an einer Konsole stehen und in die Hände klatschen, wenn sie ihr großes Projekt pünktlich, im Rahmen des Budgets und all dem, was sie nicht übermäßig entwickelt haben, auf die Welt bringen.

Es ist eine idealistische Fantasie und das Leben funktioniert nicht so.

Ein Dummkopf wird sich in ein Projekt stürzen und denken, er könne es einfach tun und erledigen. Der Erfolg wird dem Entwickler zugute kommen, der sich auf die unsichtbaren Herausforderungen vorbereitet und seinen Beruf wie feines Handwerk behandelt.

Jeder leitende Entwickler kann kritisieren, verurteilen und sich beschweren - und die meisten tun es auch!

Während er / sie Ihnen sagt, dass Sie das Projekt "überdenken". Ich gratuliere Ihnen, dass Sie zuerst wirklich "nachdenken". Sie haben Ihre ersten Schritte unternommen, um ein besserer Entwickler zu sein als der andere.

Ist dies ein Trend, dem Programmierer normalerweise folgen, wenn sie ein Projekt wie dieses durchführen? Wenn Sie zum Beispiel gebeten wurden, ein Proof-of-Concept-Modell zu erstellen, ist es ein typischer Trend, ein praktikables Beispiel so schnell wie möglich zusammenzustellen?

Genau das ist ein Proof of Concept. Es ist ein Versuch, etwas so schnell wie möglich zu zerstampfen, damit die Leute einen Schritt zurücktreten und es sich ansehen können. Es wird getan, um Fehler, Irrtümer und Zeit- / Geldverschwendung zu vermeiden.

Es gibt viele verschiedene Arten von Proof-of-Concepts. Sie können etwas erstellen, das nach Abschluss des Vorgangs in den Müll geworfen wird, oder Sie können etwas erstellen, das einen Ausgangspunkt für das Projekt darstellt. Das hängt alles davon ab, was Sie brauchen und wie nah das Konzept am Endprodukt ist.

Es ist auch eine Gelegenheit, Ihre Ideen zu demonstrieren. Es gab Zeiten, in denen ich einen Prototyp vorgestellt habe, der die Dinge auf ein Niveau brachte, das sie nicht erwartet hatten.

Design ist in der Regel offen, daher ist es viel zu einfach, zu viel oder zu wenig davon aufzutragen. Und Sie werden den korrekten Betrag erst erfahren, nachdem das Projekt abgeschlossen oder verworfen wurde. Oder auch nicht.

Es gibt kein allgemeines Erfolgsrezept, aber Sie können lernen, Extreme zu erkennen. Das komplette Design von allem im Voraus funktioniert kaum über das Nebensächliche hinaus. Es ist in Ordnung, Komponenten zum Verfeinern zu lassen und nur das Gefühl zu haben, dass dies möglich ist, oder es gibt eine Möglichkeit, Probleme frühzeitig zu erkennen.

Sie können nachsehen, wie inkrementelle Entwicklung funktioniert, wenn Sie nicht vertraut sind. Erfolgreiche Methoden sind in der Regel auf einer oder mehreren Ebenen iterativ, suchen strenges Feedback und wachsen auf einem bestimmten Skelett.

Es gibt einige gute Gründe, sich Ratschläge anzuhören, um die Planung zu beenden und mit dem Codieren zu beginnen.

1. Nach nur 18 Monaten als Entwickler ist es unwahrscheinlich, dass Sie die Zukunft gut genug vorhersehen können, um sie zu planen, unabhängig von Ihrem College-Abschluss. Dies ist etwas, das für kluge, aber unerfahrene Entwickler äußerst schwierig zu erfassen ist, da es nur darum geht, nicht zu wissen, was Sie nicht wissen. Alte Hasen haben möglicherweise diese Schwäche in Ihrem Sehvermögen erkannt und Sie mit Bedacht dazu ermutigt, sich darauf einzulassen und Ihr Bestes zu geben.

2. Junge Entwickler sind möglicherweise davon besessen, das Design zu perfektionieren, bevor sie mit dem Codieren beginnen. Sie decken möglicherweise die Angst vor dem Schreiben des Codes ab (Leistungsangst) oder haben möglicherweise einen Codeblock (wie einen Schreibblock). Sie schwanken im Design, weil keine Arbeitsleistung erforderlich ist. Der junge Entwickler wird wahrscheinlich verärgert auf den Vorschlag reagieren, dass er "Angst" vor irgendetwas hat. Vielleicht stellen sie am Ende des Projekts fest, dass sie es waren. Der Rat, sich keine Sorgen zu machen und die Codierung zu erhalten, ist das einzige bekannte Heilmittel für die Blockade des Codierers. Ein alter Hase kann diesen Rat mit Bedacht geben.

3. Bei strengen Zeitplänen sind Ihre Chancen, das Projekt überhaupt fertig zu stellen, begrenzt. Planen Sie zu lange, und egal wie gut der Plan ist, Sie können ihn nicht rechtzeitig ausführen und kommen nie auf den Markt. Fangen Sie von Anfang an an zu hacken, und vielleicht haben Sie Glück und haben beim ersten Mal Recht. Sie liefern das Produkt auf wundersame Weise. Oder vielleicht haben Sie nicht so viel Glück und liefern ein halbgebackenes Stück Schlacke aus, aber es kommt pünktlich auf den Markt und Sie lernen etwas. Oder vielleicht scheitern Sie. Aber "vielleicht scheitern Sie" ist immer noch besser als "nie auf den Markt gekommen", weil Sie zu lange geplant haben. Das Schlüsselverständnis ist, dass Ihre Chancen von Anfang an begrenzt sind, so dass Sie nichts durch Hacken verlieren. Ihr Manager weiß möglicherweise, dass die Erfolgsaussichten gering sind, und hat eine Junior-Ressource nur als Lernübung zugewiesen. Wir lernen besser aus dem Scheitern als aus dem Erfolg. Haben Sie vielleicht gefragt: "Wann kann ich ein ganzes Projekt haben?"

Es braucht einen ziemlich introspektiven und egofreien Entwickler, um seine eigenen Unzulänglichkeiten zu erkennen. Meditieren Sie also eine Weile, bevor Sie den Rest lesen, damit Sie sich nicht entschuldigen, Ihre eigenen Schwächen zu übersehen ...

Nicht jeder Entwickler ist besonders gut in der Analyse, Planung und anderen Aufgaben, die Nachdenken erfordern. Der Gedanke ist hart und eklig. Es erfordert eine Art geistigen Schweiß, der Sie nach einem Arbeitstag unwohl und ausgewrungen lässt. Es macht einfach nicht so viel Spaß, wie mit Ihren zwei Dosen Monster in den Flow-Zustand zu gelangen, und Ihr Rock ist laut aufgetaucht und codiert, codiert, codiert. Entwickler, die nicht gerne denken, werden sich der Vorstellung widersetzen, dass Planung eine gute Idee ist. Sie empfehlen Entwicklungsmethoden, die keine Vorausplanung erfordern. Sie mögen Unternehmen und Manager, die keinen Wert auf Planung legen. Sie ziehen Arbeitsplätze an, bei denen die Kosten für die Nichtplanung nicht zu hoch sind. Sie schätzen die nächtlichen Codierungssitzungen und die Bereitstellung dieses Hotfixes für Kunden, deren gesamtes Geschäft aufgrund eines Fehlers nicht verfügbar ist.

Bestimmte Entwickler haben sogar erkannt, dass ein einwandfreies Funktionieren der Demo bedeutet, dass das Funktionieren vollständig und unter allen Umständen aufgeschoben und möglicherweise sogar auf einen anderen Entwickler verschoben werden kann, während sie ein Lob dafür erhalten, dass sie ihre Arbeit anfänglich erledigt haben.

Es gibt Manager, die selbst keinen Trend erkennen können, bis dieser bereits auf Facebook aufbricht. Anstatt einen Job zu finden, der ein Discount-Reifengeschäft verwaltet, stellen diese Manager das Problem, dass der Code bis Freitag ausgeführt werden muss. Sie möchten nicht hören, dass Sie die API entwerfen oder testen müssen, ob Ihr Algorithmus skalierbar ist. Dies ist für sie nur Tech-Mumbo-Jumbo. Sie werden Sie zum Programmieren ermutigen, da sie beim Schreiben von Perl-Skripten nur etwas über Software verstanden haben, um Kunden bei der Übertragung ihrer Dateien zu unterstützen. (Sie hatten den Titel "Software Engineer" in ihrem ersten Verkaufsjob. Wer wusste, dass Software so langweilig und hart werden würde?)

Zeigen Sie mir Ihren Code und ich werde Ihnen sagen, wer Sie sind

Ihr Code ist Ihre Visitenkarte. Was sagen Sie den anderen Leuten über sich selbst, wenn Sie unordentlichen Code schreiben? Denken Sie nur daran. Jedes Mal, wenn wir im Büro ein wirklich schlechtes Codefragment finden, fragen wir uns, wer es geschrieben hat und wie zum Teufel er die Universität durchlaufen hat.

Sie werden zu dem, was Sie codieren

Ihr Code ist Ihr Programm fürs Leben.

Ein Programmierer, der schlechten Code schreibt, ist wie ein Balletttänzer, der im Striptease-Club tanzt

Manche Leute interessieren sich nicht dafür, im Striptease-Club zu tanzen. Aber wenn sie hochbegabte Tänzer sind, verschwenden sie ihre Fähigkeiten. Wenn Sie ein armer Tänzer sind, aber schöne Beine haben, können Sie sich für viele ausziehen.

Schließlich sollten Sie Gogols Novelle "Das Porträt" lesen und sich durch die Geschichte der Hauptfigur warnen lassen. Ihr Freund ähnelt dem Mann aus dem Porträt. Er lockt dich mit Geld, aber du wirst den hohen Preis dafür bezahlen.