Wie kann ich die schlechten Programmierstandards meiner erfahreneren Teamkollegen angehen? [geschlossen]

Ich bin seit ungefähr 5 Jahren Softwareentwickler für eine große Firma, seit ich auf Einstiegsniveau war. Kürzlich hatte ich die Gelegenheit, an einem hochkarätigen Projekt zu arbeiten.

Mein breiteres 27-köpfiges Team ist dreigeteilt. Die anderen Mitglieder meines Teams haben über 10 Jahre Erfahrung.

Ich habe festgestellt, dass mein Team nicht weiß, wie man professionell programmiert. Ich sehe dies, weil sie keine Form von umfangreichem Design anwenden, wie z. B. Entwurfsmuster, die Verantwortlichkeiten in separate Klassen aufteilen, um Spaghetti-Code zu vermeiden. Testen Sie Code nicht oder nicht richtig, und allgemeine Diskussionen drehen sich im Kreis, nicht in eine Richtung, die einen Mehrwert bieten würde.

Ich erwäge nicht, meine Gedanken mit dem Team zu teilen, und ich helfe immer bei der Entwicklung und betrachte sie als mein Team und schütze es in irgendeiner Weise.

Ich bin nur sehr verwirrt, wie sind sie hierher gekommen und warum werden sie nicht als Risiko angesehen? Ich bin ein sehr bescheidener Mensch, der niemanden unter den Bus werfen würde, aber dieses Umfeld war nicht zu erwarten.

Ich dachte immer, ich würde von kompetenteren Menschen umgeben sein und lernen.

Ich bin nur überrascht und wollte eure Meinung hören.

Jeder hat vor vierzig Jahren so codiert. Vor zehn Jahren haben nur faule Inkompetente so codiert.
Diese Art von offener Frage ist für diese Site nicht sehr gut geeignet (und wird wahrscheinlich geschlossen, weil sie nicht beantwortet werden kann). Ich denke, Sie hätten mehr Glück in einer allgemeinen Diskussionsgruppe wie einem der hier aufgeführten Slack-Teams Techbeacon .com/46-slack-groups-developers
@Kilisi nein, gute Entwickler gab es schon in den Neunzigern. Selbst wenn es die GoF nicht gäbe, könnten Sie sich immer noch eine Scheiße Papier / Diagrammsoftware nehmen und darüber nachdenken, wie Sie die Dinge tun werden, bevor Sie in den Code einsteigen. Was Quincy Adams sagt, könnte zusammengefasst werden als „es gibt kein/einen Mangel an Softwareentwicklung“ und Mangel an Tests. Gute Testteams gab es bereits im 20. Jahrhundert (aber ein gutes Testteam muss immer von den Entwicklern getrennt werden, Punkt).
Wenn Sie gefragt würden, könnten Sie sicher beweisen, dass Ihre Methoden produktiver sind als ihre? Ist es möglich, dass ein hochrangiges Mitglied des Teams seine Methoden den anderen aufgezwungen hat?
Hinterfragen, diskutieren und Verbesserungen vorschlagen und motivieren oder ignorieren, nicht kritisieren.
@Kilisi Denken Sie daran, dass alles, was die GoF getan hat, bestehenden Mustern Namen gegeben hat, sie haben sie nicht erfunden.

Antworten (2)

Hier gibt es keine Programmierstandards und keinen wirklichen Entwicklungsprozess/Zyklus – es scheint, als würden Ihre Teamkollegen nur Anforderungen in Code übersetzen.

Sie müssen mit Ihrem Teamleiter beginnen und fragen, ob es sich lohnt, einige Programmierstandards und Teststrategien durchzusetzen, um die Effizienz des Teams zu verbessern. Es muss am Anfang nicht viel sein.

Vielleicht möchten Sie darum bitten, ein kleines Team bei einem kleinen Projekt zu leiten und einige Prozesse einer Testphase zu unterziehen und zu sehen, wie das läuft.

Natürlich hängt dies alles von der Denkweise des Teamleiters und des Unternehmens als Ganzes ab (sie könnten mit verspäteten/unterdurchschnittlichen Projekten vollkommen zufrieden sein).

Wenn Sie nirgendwo hinkommen und immer noch frustriert über den Mangel an Struktur sind, ziehen Sie in Betracht, weiterzumachen. Lass dich von diesen anderen Typen nicht runterziehen.

Zuerst müssen Sie auflisten, was die wirklichen Mängel Ihres Teams sind, was Ihr Unternehmen Geld und Zeit gekostet und Ihnen und Ihren Kollegen Kopfschmerzen bereitet hat.

Normalerweise läuft dies zunächst auf einen Mangel an automatischen Tests im "ärgerlichsten" Teil Ihrer Anwendung hinaus, mit "ärgerlich" meine ich: (entweder oder beides)

  • Das manuelle Testen dieses bestimmten Teils Ihrer Software kann einige Zeit in Anspruch nehmen
  • Einige spezifische Teile sind instabil und viele Fehler kommen daher.
  • Ein bestimmter Teil ist kritisch und alle Fehler kosten Ihrem Unternehmen viel Geld oder Reputation.

Daher ist der Vorschlag, nicht-Regressionstests auf hohem Niveau hinzuzufügen, sehr wahrscheinlich ein guter Anfang, und die Wirkung wird sofort für alle sichtbar sein.

Für Codierungsstandards: Es kommt darauf an, ob der Code Ihrer Teamkollegen bereits lesbar ist, dann bestehen Sie nicht zu sehr darauf, wenn nicht, versuchen Sie, sie zu bitten, bei der Benennung vorsichtiger zu sein, und hinterlassen Sie einige Kommentare, wo dies erforderlich ist.

Denken Sie an die beiden folgenden Prinzipien: Halten Sie es einfach und dumm, und Sie werden es nicht brauchen.

Die Lösung, die Sie vorschlagen, muss ein bestehendes Problem lösen und einfach sein. Andernfalls fügen Sie Ihrem System nur Komplexität hinzu, ohne die aktuellen Fehler zu beheben.