Wann wird es übertrieben?


10

Zunächst einmal entschuldige ich mich, weil ich nicht weiß, wie ich einen Community-Thread erstellen soll. Also hilft mir bitte jemand.

Als Entwickler auf vielen Plattformen, Technologien und sogar auf Infrastrukturebene; Ich frage mich immer, wann ich zu viel mache?!?

Es war ein nie endender Lernprozess, seit ich angefangen habe. Eine (1) Sache, die ich gelernt habe, ist, dass Anforderungen über einen längeren Zeitraum kaum gültig sind und daher ein wenig Voraussicht einen langen Weg gehen kann.

Aber wo ist das Gleichgewicht und woher weißt du, wann du Zeit verlierst und nicht gewinnst?!


1
Sprechen wir über Dinge wie die Skalierung für eine Million Benutzer vom ersten Tag an, wenn Sie gerade keine Kunden haben? Oder eher funktionale Dinge wie die Art und Weise, wie Steuerberechnungen "konfigurierbar" durchgeführt werden, wenn es keinen Vorschlag gibt, dass sie sich jemals ändern könnten, und selbst wenn dies der Fall ist, hat niemand eine Ahnung, wie sie in dieser hypothetischen neuen Welt funktionieren könnten?
Jon Hopkins

1
Community Wiki ist ziemlich veraltet. Es hat nie wirklich wie geplant funktioniert. Mach dir keine Sorgen.
David Thornley

Wenn Sie über eine Million Benutzer sprechen, sollte Overkill nicht in Ihrem Wortschatz enthalten sein.
Theofanis Pantelides

Antworten:


12

Sie tun zu viel, wenn der durchschnittliche Entwickler nicht verstehen kann, was Sie durch Lesen Ihres Codes getan haben .

  • Führen Sie mit Ihrem Team häufige Codeüberprüfungen durch.
  • Besprechen Sie die Architekturen, Technologien oder Muster, die Sie verwenden möchten. (in täglichen Stand-up-Meetings, wenn Sie sie haben)

Ich kämpfe gegen alle CV-gesteuerten "Architekten", denen ich begegne. Ich wünschte, die Kuppel existiert! ;)

Ich glaube, die Welt verschwendet einen riesigen Haufen Geld, mit dem wir stattdessen unser (Programmierer-) Leben verbessern könnten.


5
"Ich kämpfe gegen alle CV-gesteuerten" Architekten "Ich begegne" :)
Gratzy

2
Ich stimme dem nicht unbedingt (praktisch) zu, da die Entwickler ungleich sind. In vielen Fällen überarbeite ich ähnliche Projekte, um eine gemeinsame Bibliothek zu verwenden, und sie ist nicht immer so lesbar wie zuvor.
Theofanis Pantelides

1
Ich denke, es ist ziemlich wichtig, dass jedes Teammitglied den Quellcode, an dem es arbeitet, gut genug versteht. Für den Reichtum Ihres Projekts und auch um zu vermeiden, dass der Architekt der Sklave seiner eigenen Implementierungen ist. Wenn es also zu viele Wissensunterschiede gibt, beheben Sie diese zuerst.

1
Ich mag deinen ersten Satz; Klarheit des Codes ist wichtig. Aber häufige Codeüberprüfungen? Architekturdiskussionen in täglichen Meetings ... Wirklich? Und was genau bedeutet "CV-gesteuerte Architekten"?
Robert Harvey

1
Häufige Codeüberprüfungen bedeuten, dass sie automatisch erfolgen müssen. Sie schreiben eine Funktion, eine Ihrer Kollegen überprüft sie und muss sie verstehen, um sie zu validieren. Wenn er Sie befragt, arbeiten Sie zusammen, um den Code zu verbessern. Sie erwähnen Ihre architektonischen Probleme während des Aufstehens, aber die Diskussion erfolgt danach. Lesen Sie, wer einen Architekten braucht ( martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf ). CV-gesteuert bedeutet, dass Sie eine Technologie auswählen, weil Sie sie in Ihrem Lebenslauf haben

11

Wenn die Prozesse die Ergebnisse überholen.

Zu oft haben wir gesehen, dass schlechte Dinge beginnen, wenn sich die Entwickler mehr auf den Prozess als auf die Ergebnisse konzentrieren (wie in Bezug auf Qualität, Einhaltung der Frist usw.).

Aus diesem Grund sollte niemals vergessen werden, dass der Zweck von Codeüberprüfungen, Entwurfsmustern usw. darin besteht, den Code zu verbessern, aber sie sind nicht das Ziel selbst.


4

Für mich gefällt mir der Ansatz, den Kent Beck in XP vorschlägt (nicht sicher, ob es "seine" Idee oder die einer anderen Person ist, aber dort habe ich ihn zum ersten Mal gehört):

Es ist schwer genug, die Probleme von heute zu lösen, ohne zu versuchen, die Probleme von morgen herauszufinden und sie auch zu lösen.

Entwickler können viel Zeit mit Lösungen für Anforderungen verbringen, die nicht existieren, Randfälle, die niemals auftreten werden, oder sogar mit echten Problemen, bei denen die Auswirkungen des Problems erheblich geringer sind als die Kosten für dessen Verhinderung.

Dies ist die Zeit, die in Dinge gesteckt werden könnte, die Benutzer wirklich wollen und nutzen, Dinge, die ihnen Vorteile bringen, die selbst die Unannehmlichkeiten, die in dem unwahrscheinlichen Fall entstehen, dass eines dieser Dinge tatsächlich passiert, massiv überwiegen.

Abgesehen von diesem für den Benutzer nicht optimalen Ergebnis sind die Auswirkungen von Over Engineering auf diese Weise auf den Entwickler in der Regel auf komplexen Code zurückzuführen, der schwerer zu unterstützen und schwerer zu verbessern ist.

Wenn Sie also wissen oder ziemlich sicher sein können, dass etwas eine Anforderung ist oder ein Problem verursachen wird, sprechen Sie es an, wenn nicht, dann nicht.

Möglicherweise müssen Sie zurückkommen und es überarbeiten, wenn sich herausstellt, dass eine größere Anforderung als ursprünglich implementiert vorhanden war. Im Allgemeinen ist der Gesamtaufwand für das gesamte Projekt jedoch geringer, da dies in den meisten Fällen nicht der Fall ist.


Wie wäre es, alles zu modularisieren und dann einfach die Module zu ersetzen, während Sie skalieren? oder ist das auch übertrieben?
Theofanis Pantelides

1
@ Theofanis Patelides - Gut strukturierter Code ist natürlich immer eine gute Idee, aber wie bei den meisten Dingen kann man es sicherlich zu weit bringen. Ich denke, bei vielen dieser Dinge wird es mit der Zeit instinktiv - Sie wissen, was Sie zuvor getan haben und was Zeitverschwendung war.
Jon Hopkins

1

Ihre Frage ist ziemlich offen, daher werde ich sie als "zu viel für einen Teil des Projekts tun" interpretieren:

Für mich ist es einfach, zu viel Zeit mit etwas zu verbringen, das dem Kunden nicht wirklich viel Gewinn bringt. Oft sind es die winzigen Dinge wie "Nun, es funktioniert, aber nicht ganz so, wie ich es auch will", bei denen es dem Kunden wahrscheinlich egal wäre, ob es so oder so funktioniert.

Wenn das passiert, sollte ich damit aufhören und Zeit mit Dingen verbringen, die wichtiger sind. Es ist besser, dass das Produkt als Ganzes funktioniert als nicht, aber Sie haben diese kleineren Teile, die perfekt funktionieren.

Das Schreiben von Tracer-Code (von Code Complete ) ist wahrscheinlich eine gute Idee, um dies zu vermeiden: Sie starten Ihr Projekt, indem Sie Code schreiben, der den gesamten Code verbindet - von der GUI (oder in der Nähe davon) bis zum Backend und dann zurück. Auf diese Weise haben Sie immer etwas, das funktioniert, und Sie haben keine Zeit damit verbracht, die kleinen Dinge zu perfektionieren, bis das Ganze läuft.

Trotzdem geht es um Disziplin und Priorisierung.


Ich stimme zu, aber ich habe auch viele Stunden damit verbracht, Funktionen zu nutzen und sie dann an einen nicht-technischen Endbenutzer weiterzugeben und sie wegen der kleinen Dinge abzulehnen!
Theofanis Pantelides

1

Wenn ich mit "Nein, werde ich wütend sein" antworte, habe ich das später nicht getan und es beißt mich.

IRL Ressourcen- und Zeitbeschränkungen bringen mich normalerweise dazu, bevor ich diese Frage viel stellen muss. An diesem Punkt konzentrieren Sie sich nur auf die wichtigsten / erreichbaren Teile und hoffen auf das Beste.


1
Für mich gibt es nichts irritierenderes als von Plan A
abzuweichen

1

Ein nie endender Lernprozess! ... und ich denke es bleibt so! Das Gleichgewicht ist, wenn die Dinge effizient genug sind und Sie die Zeit haben, neben der Programmierung noch etwas anderes zu tun. Ich stimme Gablin zu "eine Frage der Disziplin und Priorisierung" und Jim Hopkins, dass es nach einer Weile instinktiv wird. Ich weiß, dass die Perfektionierung der kleinen Teile uns glücklich macht, aber am Ende geht es darum, was den Endbenutzer glücklich macht. Ich würde also sagen, dass das Gleichgewicht (oder vielleicht der Kompromiss) darin besteht, den Endbenutzer / Kunden / Kunden zuerst glücklich zu machen (was Plan A sein sollte) und dann, wenn Zeit für die Perfektionierung bleibt - Ihre "Kleinteile" und / oder effizienter zu machen oder alles andere bitte. Irgendwann muss man allerdings "genug" sagen :) sonst wird es ja ein Overkill!

Das schlimmste Szenario ist natürlich, wenn der Endbenutzer / Kunde / Kunde Sie sind! :) :)

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.