it-swarm.com.de

Überdenken der Entwicklung

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

Unnötig zu erwähnen, dass es nicht sehr reibungslos verlief. Deshalb habe ich mich von einem leitenden Programmierer, der an dem Projekt beteiligt war, beraten lassen, wie ich es angehen soll.

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

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

Bearbeiten: Angesichts 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 nicht zeigen ihnen nichts) und sein Rat erwies sich für diese spezielle Aufgabe als sehr effektiv.

89
sf13579

Kapitän Offensichtlich zur Rettung!

Ich werde hier Captain Obvious sein und sagen, dass es einen Mittelweg gibt.

Sie möchten für die Zukunft bauen und vermeiden, sich auf eine technologische Entscheidung oder ein schlechtes Design festzulegen. Sie möchten jedoch nicht drei 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 zwei Jahren hat und wahrscheinlich keine Folgeprojekte hat.

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

Bauen Sie jetzt, 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 vorerst interne Projekte oder für einen Kunden erstellte Projekte entwickelt werden. Stellen Sie sicher, dass Sie klare Anforderungen haben, und beziehen Sie sich bei Bedarf auf diese, um zu wissen, was benötigt wird und was nicht. Ich möchte 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:

(XKCD: The General Problem

Bauen für die Zukunft, wenn ...

  • das Projekt wird öffentlich sein
  • das Projekt ist eine Komponente, die wiederverwendet werden soll
  • das Projekt ist ein Sprungbrett für andere Projekte
  • das Projekt verfügt über Folgeprojekte oder Service Releases mit Verbesserungen

Wenn Sie für etwas Öffentliches bauen oder das in anderen Projekten wiederverwendet wird, haben Sie eine viel höhere Wahrscheinlichkeit, dass ein schlechtes Design Sie verfolgt, also sollten Sie dem mehr Aufmerksamkeit schenken. Aber es ist 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, anpassungsfähige Produkte zu entwickeln:

  • weiß, dass YAGNI ,
  • KUSS ,
  • wenn Sie Lust haben, sich an einem Juckreiz zu kratzen und an einen Zusatz zu denken, schreiben Sie ihn auf. Schauen Sie zurück auf Ihre Projektanforderungen und fragen Sie sich, ob Ergänzungen Priorität haben oder nicht. Fragen Sie, ob sie primären Geschäftswert hinzufügen oder nicht.

Ich weiß, dass ich persönlich dazu neige, zu überdenken und zu überarbeiten. Es ist wirklich hilfreich, Ideen aufzuschreiben und sehr oft zu überdenken, wenn 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, nicht für sie zu planen.

Der beste Weg, um zu programmieren, ohne zu überarbeiten und ohne sich für später zu blockieren, besteht darin, sich auf ein gutes Minimal-Design zu konzentrieren. Teilen Sie die Dinge gut als Komponenten auf, die Sie später erweitern können, ohne jedoch bereits darüber nachzudenken, wie sie später erweitert werden können. 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 solches Projekt durchführen?

Hölle ja. Es ist ein bekanntes Dilemma und es zeigt nur, dass Sie sich für das Produkt interessieren. Wenn Sie dies nicht tun, ist das besorgniserregender. Es gibt Meinungsverschiedenheiten darüber, ob weniger immer wirklich mehr ist und wenn schlechter immer wirklich besser ist . Sie sind möglicherweise ein MIT oder New Jersey-Typ . Hier gibt es keine einfache Antwort.

Prototyping/Quick-n-Dirty/Weniger ist mehr

Ist es ein typischer Trend, ein praktikables Beispiel so schnell wie möglich zu erstellen?

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

(Dilbert on shipping prototypes directly to production

Es gibt offensichtliche Vorteile des Prototyping , aber auch viel Potenzial für Missbrauch und Missbrauch (viele der genauen Umkehrung der zuvor aufgeführten Vorteile als Ergebnis).

Wann sollte Prototyping verwendet werden?

Es gibt Hinweise zum beste Arten von Projekten für die Verwendung von Prototyping :

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

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

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

Auf der anderen Seite:

Systeme mit geringer Benutzerinteraktion, wie z. B. Stapelverarbeitung oder Systeme, die hauptsächlich Berechnungen durchführen, profitieren wenig vom Prototyping. Manchmal ist die zur Ausführung der Systemfunktionen erforderliche Codierung zu intensiv und die potenziellen Vorteile, die das Prototyping bieten könnte, sind zu gering.

Und wenn Sie ein grünes Monster in der Nähe haben, stellen Sie sicher, dass ein Prototyp innerhalb des Budgets bleibt ...

(Dilbert on extending prototyping periods

113
haylem

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 massive Angst unter den Entwicklern besteht darin, dass die Stakeholder glauben, die kleine App sei produktionsbereit, oder Sie sollten in der Lage sein, Funktionen für immer mit der gleichen Geschwindigkeit hinzuzufügen. Sie arbeiten an einem großen Projekt und stellen fest, dass dies nicht der Fall ist.

Große Projekte haben normalerweise komplexere Anforderungen, daher besteht die Versuchung, komplexe Entwürfe zu implementieren. Sie werden viel Zeit damit verbringen, sie zu lesen, zu recherchieren und zu implementieren. Dies kann zu einer großen Zeitverschwendung werden, aber es ist alles Teil des Lernens und des Sammelns von Erfahrung. Zu wissen, wann ein bestimmtes Design verwendet werden muss, ist schwierig und mit Erfahrung verbunden. Ich habe "das" bei "diesem" Projekt versucht und es hat nicht funktioniert, aber jetzt sehe ich, dass es "hier" funktionieren sollte.

Sie müssen viel planen und planen, aber tun Sie 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 wie folgt erstellt:

  1. Entwerfen und diskutieren Sie ein wenig.
  2. Schreiben Sie eine Menge Code, der etwas bewirkt.
  3. Erkennen Sie die Probleme und STOPPEN Sie die Codierung.
  4. Nehmen Sie das Design ernst und machen Sie sich keine Sorgen mehr, dass Sie an Dynamik oder Ihrem Code-Mojo verlieren, und ignorieren Sie den Projektmanager (Sie tun ihm/ihr einen Gefallen.).
  5. Holen Sie sich das Projekt unter Kontrolle. Repariere deine Probleme. Stellen Sie sicher, dass jeder den Plan versteht. Behalten Sie das Projekt unter Kontrolle.

Manchmal stoßen Sie auf eine dieser Funktionen, die Sie wirklich beunruhigen, wie Sie sie in die vorhandene Codebasis implementieren können. 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 nahm er nicht an, dass ich vermasselt war, und stellte sicher, dass ich verstand, dass ich mehr davon machen sollte. Genius.

Letztendlich ist Ihr Code das Design. Es wird von Dokumenten, Diagrammen, Besprechungen, E-Mails, Whiteboard-Diskussionen, SO Fragen, Argumenten, Fluchen, Wutanfällen und leisen Chats beim Kaffee unterstützt. Es gibt einen Punkt, an dem Sie nicht entwerfen können mehr und riskieren, mehr Designzeit wegzuwerfen, weil Sie nur beim Versuch, den Code zu schreiben, Fehler entdecken. Je mehr Code Sie schreiben, desto größer ist die Chance, dass Sie einen Designfehler einführen, den Sie nicht codieren können wieder Zeit für den Stuhl.

54
JeffO

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

Ja.

Sollten sie das tun?

Nein.

Auf den ersten Blick scheint es, dass "über die Zukunft nachdenken" gegen etablierte Designprinzipien wie KISS und [~ # ~] yagni [~] verstößt # ~] , die behaupten, dass nichts implementiert werden sollte, was momentan nicht erforderlich ist.

Aber eigentlich nicht. Über die Zukunft nachzudenken bedeutet, 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 nicht an einem Projekt arbeiten, sollten Sie es dennoch intelligent entwickeln. Es ist deine Arbeit, und du solltest es gut machen, zumindest um nicht zu vergessen, wie gute Arbeit geleistet wird.

24
superM

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

Der wichtige Aspekt dabei ist, die Anforderungen an Ihr Produkt beim Entwerfen im Auge zu behalten und sicherzustellen, dass Sie nicht für eine Reihe von Anforderungen entwerfen, die in Zukunft auftreten könnten.

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

13
user93143

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

Ich vermute, Ihr Mentor meinte damit, 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 ein Mittel zum Zweck sind. Wenn Sie mit Erfahrung feststellen, dass ein bestimmtes Entwurfsmuster trotz Ihrer früheren Vermutung nicht passt, kann dies auf einen Codegeruch hinweisen.

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

Es lohnt sich, vor Projektbeginn zu steuern, welche Meilensteine ​​es gibt und ob sie bei der Entwicklung ein bisschen von allem (vertikaler Schnitt) oder nur jedes Teil im Detail sehen möchten (horizontaler Schnitt). Als Teil des anfänglichen Designs finde ich es lohnenswert, die gesamte App mit einer Story zu versehen. Obwohl der Code nicht geschrieben ist, können Sie eine Hubschrauberansicht des Ganzen oder einen tiefen Tauchgang in einem bestimmten Gebiet durchführen.

7
Robbie Dee

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

Ich denke, das ist eine Art Cowboy-Mentalität des anderen Entwicklers. Die moderne Version eines harten Nerds, der es einfach "jetzt macht". Es ist ein beliebtes Thema bei Startups geworden und nein, danke an die Facebook-Leute, die den Satz "Es ist besser, es richtig zu machen, als es richtig zu machen" gestartet haben.

Es ist ansprechend. Es ist ermutigend und bietet Visionen von Entwicklern, die an einer Konsole stehen und in die Hände klatschen, während sie ihr großes Projekt pünktlich, im Rahmen des Budgets und alles in die Welt bringen, weil sie nichts überarbeitet haben.

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

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

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

Während er/sie Ihnen sagt, dass Sie das Projekt "überdenken". Ich gratuliere Ihnen, dass Sie zuerst "nachgedacht" haben. 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 solches Projekt durchführen? Wenn Sie beispielsweise gebeten wurden, ein Proof-of-Concept-Modell zu erstellen, ist es ein typischer Trend, ein praktikables Beispiel so schnell wie möglich zu erstellen?

Genau das ist ein Proof of Concept. Es ist ein Versuch, etwas so schnell wie möglich zu zerdrücken, damit die Leute einen Schritt zurücktreten und es sich ansehen können. Es wird getan, um Fehler, Fehlleitung 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 gebracht hat, das sie nicht erwartet hatten.

6
Reactgular

Design ist normalerweise offen, so dass es viel zu einfach ist, zu viel oder zu wenig davon aufzutragen. Und Sie werden den richtigen Betrag erst kennen, nachdem das Projekt abgeschlossen oder verworfen wurde. Oder auch nicht dann.

Es gibt kein allgemeines Erfolgsrezept, aber Sie können lernen, Extreme zu erkennen. Das vollständige Design von allem im Voraus funktioniert kaum über triviale Dinge hinaus. Es ist in Ordnung, Komponenten zum Verfeinern zu belassen 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 nachschlagen, wie inkrementelle Entwicklung funktioniert, wenn Sie nicht vertraut sind. Erfolgreiche Methoden sind normalerweise auf einer oder mehreren Ebenen iterativ, suchen nach engem Feedback und wachsen auf einem bestimmten Skelett.

5
Balog Pal

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-GPA. Dies ist etwas, das für kluge, aber unerfahrene Entwickler äußerst schwer zu verstehen ist, da es darum geht, nicht zu wissen, was Sie nicht wissen. Alte Hasen haben diese Schwäche in Ihrer Vision möglicherweise erkannt und Sie mit Bedacht ermutigt, sich einfach 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 Codiererblock (wie den Schreibblock). Sie stimmen mit dem Design überein, da keine Arbeitsleistung erforderlich ist. Der junge Entwickler wird wahrscheinlich verärgert auf den Vorschlag reagieren, dass er vor irgendetwas "Angst" hat. Vielleicht werden sie am Ende des Projekts feststellen, dass sie es waren. Der Rat, sich keine Sorgen zu machen und Codierung zu erhalten, ist das einzige bekannte Heilmittel für den Codiererblock. Ein alter Hase kann diesen Rat mit Bedacht anbieten.

  3. Bei strengen Zeitplanbeschränkungen sind Ihre Chancen, das Projekt überhaupt durchzuführen, 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 eine bessere Chance 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, sodass Sie durch Hacken nichts verlieren. Ihr Manager weiß möglicherweise, dass es nur geringe Erfolgschancen gibt, und hat eine Junior-Ressource nur als Lernübung zugewiesen. Wir lernen besser aus Misserfolg als aus Erfolg. Haben Sie vielleicht gefragt: "Wann kann ich ein ganzes Projekt haben?"

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

Nicht jeder Entwickler ist besonders gut in Analyse, Planung und anderen Aufgaben, die Nachdenken erfordern. Das Denken ist hart und eklig. Es erfordert eine Art mentalen Schweiß, der Sie nach einem Arbeitstag unbehaglich und ausgewrungen macht. Es macht einfach nicht so viel Spaß, wie mit deinen beiden Dosen Monster in den Flow-Zustand zu kommen, und dein Stein 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 Schwerpunkt auf Planung legen. Sie ziehen Jobs an, bei denen die Kosten für die Nichtplanung nicht zu hoch sind. Sie legen Wert darauf, die ganze Nacht über Codierungssitzungen abzuhalten und diesen Hotfix an Kunden weiterzugeben, deren gesamtes Geschäft aufgrund eines Fehlers ausgefallen ist. (Und egal, dass die Lieferung von defektem Code an einen Kunden ein Kapitalverbrechen sein sollte).

Einige Entwickler haben sogar erkannt, dass eine vollständige Funktionsweise für die Demo bedeutet, dass die vollständige Ausführung unter allen Umständen verschoben und möglicherweise sogar auf einen anderen Entwickler übertragen werden kann, während sie zunächst ein Lob für die "Erledigung der Aufgabe" erhalten.

Es gibt Manager, die einen Trend erst erkennen können, wenn er bereits auf Facebook bricht. Anstatt einen Job als Manager eines Discount-Reifengeschäfts zu finden, machen diese Manager es zu Ihrem 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-Hokuspokus. Sie werden Sie zum Codieren ermutigen, da dies alles ist, was sie über Software verstanden haben, als sie Perl-Skripte geschrieben haben, um Kunden beim Übertragen ihrer Dateien zu helfen. (Sie hatten den Titel "Software Engineer" in ihrem ersten Verkaufsjob. Wer wusste, dass Software so langweilig und hart werden würde?)

3