it-swarm.com.de

Wo soll mein Team anfangen, "modern" zu werden?

Ich bin ein relativ neuer Entwickler, frisch vom College. Während des Studiums und bei der anschließenden Arbeitssuche stellte ich fest, dass es viele "moderne" Softwareentwicklungsmethoden gab, die meiner Ausbildung fehlten: Unit-Tests, Protokollierung, Datenbanknormalisierung, agile Entwicklung (im Vergleich zu generischen agilen Konzepten), Codierungsstil Anleitungen, Refactoring, Codeüberprüfungen, keine standardisierten Dokumentationsmethoden (oder sogar Anforderungen) usw.

Insgesamt habe ich nicht gesehen, dass dies ein Problem ist. Ich hatte erwartet, dass mein erster Job all diese Ideen aufgreift und sie mir im Job beibringt. Dann bekam ich meinen ersten Job (Full-Stack-Webentwicklung) bei einem großen Unternehmen und mir wurde klar, dass wir keines dieser Dinge tun . Tatsächlich bin ich, der am wenigsten erfahrene im Team, derjenige, der versucht, mein Team mit "modernen" Programmiertechniken auf den neuesten Stand zu bringen - da ich mir Sorgen mache, dass dies kein professioneller Selbstmord ist.

Zuerst begann ich mit der Protokollierungssoftware (log4J), dann schrieb ich schnell meinen eigenen Styleguide und gab ihn dann für den Google Styleguide auf - und dann stellte ich fest, dass unsere Java Webentwicklung) Hand verwendete -geschriebene Front-Controller, also habe ich auf die Einführung von Spring gedrängt - aber dann wurde mir klar, dass wir auch keine Unit-Tests hatten, aber ich habe bereits Spring gelernt ... und wie Sie sehen, wird es allzu schnell überwältigend, besonders wenn gepaart mit normaler Entwicklungsarbeit. Außerdem ist es für mich schwierig, in diesen Methoden "Experte" genug zu werden, um andere darin zu unterrichten, ohne zu viel Zeit für einen einzelnen von ihnen aufzuwenden, geschweige denn für alle.

Wie kann ich von all diesen Techniken, die ich in der heutigen Welt der Softwareentwicklung als "erwartet" betrachte, sie als neuen Spieler in ein Team integrieren, ohne mich selbst und das Team zu überwältigen?

Wie kann ich mein Team beeinflussen, um agiler zu werden? ist verwandt, aber ich bin kein agiler Entwickler wie der Fragesteller Hier sehe ich eine viel breitere Palette von Methoden als Agile.

107
WannabeCoder

Es hört sich für mich so an, als würden Sie den Karren vor das Pferd stellen.

Was ist das Hauptproblem Ihres Teams und welche Technologien würden helfen, es zu beheben?

Wenn beispielsweise viele Fehler vorliegen, insbesondere Fehler vom Regressionstyp, kann das Testen von Einheiten ein Ausgangspunkt sein. Wenn Ihrem Team Zeit fehlt, kann möglicherweise ein Rahmen helfen (mittel- bis langfristig). Wenn Menschen Schwierigkeiten haben, den Code der anderen zu lesen, kann das Styling hilfreich sein.

Denken Sie daran, dass der Zweck des Unternehmens, für das Sie arbeiten, darin besteht, Geld zu verdienen und keinen Code zu erstellen.

165
Jaydee

Java? Modern?! Sie haben bei der ersten Hürde versagt. Wenn Sie wirklich modern sein und "professionellen Selbstmord" vermeiden möchten, müssen Sie Rust Code) schreiben. Natürlich wird sich nächste Woche alles ändern und Sie müssen sogar etwas lernen neuer, um mitzuhalten!

Oder Sie könnten akzeptieren, dass keine Menge von Schlagworttechnologien oder -methoden oder -frameworks oder anderen du jour die Tatsache ändert, dass Sie Qualitätsprodukte erstellen möchten, die funktionieren. Es spielt keine Rolle, ob Sie Agile nicht verwenden, wenn Sie erfolgreich die richtige Ausgabe produzieren. Wenn Sie dies nicht tun, möchten Sie möglicherweise Änderungen vornehmen, aber es besteht die Möglichkeit, dass keine bestimmte Übung die Probleme behebt. Sie bleiben menschliche Probleme, die auf verschiedene Arten behoben werden können.

Wenn Sie wissen, was Sie tun und flexibel sind, brauchen Sie für den professionellen Selbstmord nichts, was Sie erwähnt haben. Die Leute werden weiterhin neue Wege finden, um die alte Arbeit zu erledigen, und Sie werden immer aufholen. Oder Sie können einfach die Techniken verwenden, die Ihr aktuelles Unternehmen verwendet. Wenn Sie Ihr Unternehmen ändern, lernen Sie einfach die Techniken, die sie verwenden.

Zu viele Kinder hängen an all den neuen Werkzeugen, die sie verwenden könnten, und vergessen, dass diese Werkzeuge in den Händen eines Anfängers wertlos sind. Lernen Sie zuerst die Praxis, sobald Sie ein erfahrener Entwickler sind, können Sie beginnen, die Entwicklungspraktiken mit "coolen neuen Dingen" zu "reparieren", aber bis dahin werden Sie hoffentlich erkannt haben, dass sie bei weitem nicht so wichtig sind, wie Sie derzeit denken, und Nur zu verwenden, wenn sie wirklich benötigt werden.

77
gbjbaanb

Viele Unternehmen stecken so fest; Es könnte Sie sogar überraschen, dass einige Ihrer Entwicklerkollegen Autodidakten sind und Entwickler ohne jeglichen formalen Hintergrund geworden sind. Diese Entwickler sind oft besser in ihrer Arbeit, da sie diejenigen sind, die neue Fähigkeiten erlernen und erfolgreich sein wollen, anstatt nur die Arbeit zu erledigen. Leider kann dies auch bedeuten, dass sie zwar hervorragend programmieren können, sich jedoch der Vorteile dieser Praktiken möglicherweise nicht bewusst sind. Tatsache ist, dass dies am besten Praktiken sind, nicht üblich Praktiken. Die am besten verwenden sie, aber sie sind überhaupt keine Voraussetzungen, um erfolgreich zu sein. Sie sind lediglich Werkzeuge, um den Erfolg zu erleichtern.

Sie haben absolut Recht, es wird überwältigend sein, alles auf einmal zu implementieren. Sie werden sich (und möglicherweise Ihr Team) wahrscheinlich verbrennen, wenn Sie versuchen, dies zu tun, was zukünftige Bemühungen zur Einführung neuer Methoden/Technologien demotivieren wird. Das Beste, was Sie in einer solchen Situation tun können, ist pick one thing (die Protokollierung ist wahrscheinlich ein guter Anfang, da Sie wahrscheinlich einen schwierigen Weg vor sich haben, um Fehler ohne Protokollierung zu finden, und es gibt sicher solche Bugs) und sprechen Sie mit dem Team darüber. Sie müssen dies nicht im Alleingang implementieren. Sie können die Vor- und Nachteile viel besser mit dem Team (und Ihrem Chef, der unbedingt mit so etwas an Bord sein muss) besprechen und einen Plan für die Umsetzung ausarbeiten. Es muss so schmerzlos wie möglich sein (denken Sie daran, Sie sagen den Leuten, dass sie jetzt zusätzlich zu dem, was sie bereits tun, extra Code schreiben müssen).

Und lassen Sie mich noch einmal sagen: stellen Sie sicher, dass Ihr Chef einkauft. Das ist entscheidend; Sie werden wahrscheinlich feststellen, dass sich die Geschwindigkeit von Fixes/Releases verlangsamt, wenn Sie neue Dinge implementieren. Der Punkt ist, dass Sie im Voraus bezahlen, um auf der ganzen Linie zu sparen; Sie müssen das verstehen und auf Ihrer Seite sein. Wenn Sie sie nicht an Bord bekommen, führen Sie bestenfalls einen verlorenen Kampf, und im schlimmsten Fall betrachten sie Sie möglicherweise als aktiv sabotierend für das Team (fragen Sie mich, woher ich das weiß).

Sobald Sie diese Elemente auf den Tisch gebracht haben, besprechen Sie sie mit dem Team, planen Sie, wie sie implementiert werden sollen, und folgen Sie ihnen. Der zweite, dritte, achte usw. wird einfacher. Darüber hinaus besteht für das Team und Ihren Chef das Potenzial, Respekt für Sie zu gewinnen, wenn Ihre Vorschläge umgesetzt und als Mehrwert anerkannt werden. Großartig! Stellen Sie einfach sicher, dass Sie flexibel bleiben: Sie drücken hier gegen die Trägheit, und Änderungen sind nicht einfach. Seien Sie bereit, langsam klein Änderungen vorzunehmen, und stellen Sie sicher, dass Sie den Fortschritt und den erzielten Wert verfolgen können. Wenn Sie die Anmeldung in einem neuen Prozess implementieren und so in drei Wochen Stunden beim Auffinden eines Fehlers sparen, machen Sie eine große Sache daraus! Stellen Sie sicher, dass jeder weiß, dass das Unternehmen gerade XXX US-Dollar gespart hat, indem es im Voraus das Richtige getan hat. Wenn Sie jedoch einen Pushback erhalten oder eine enge Frist haben, versuchen Sie nicht, das Problem zu erzwingen. Lassen Sie die neue Änderung für den Moment gleiten und kreisen Sie zurück. Sie werden niemals gewinnen, wenn Sie versuchen, das Team zu etwas zu zwingen, das sie nicht tun möchten, und Sie können sicher sein, dass das erste, was sie vorschlagen werden, die neue „zusätzliche“ Arbeit ist (wie das Schreiben von Protokollen oder das Folgen) ein Styleguide anstatt nur 'es zum Laufen zu bringen').

40
DrewJordan

Ich hoffe, Sie haben die Themen Ihren Mitarbeitern nicht so vorgestellt, wie Sie es uns in Ihrem Beitrag getan haben. Das wäre professioneller Selbstmord.

Das erste Problem ist, dass Sie versuchen, einer Gruppe von Programmierern Technologien und Methoden beizubringen, mit denen Sie selbst keine Erfahrung haben, die vielleicht etwas veraltet sind, aber die Arbeit "erledigen". Die Möglichkeiten dieser Fehlzündung sind endlos und werden Ihren Mitarbeitern wahrscheinlich viel Freude bereiten. Es ist interessant und bewundernswert, dass Sie sich und Ihre Abteilung verbessern möchten, aber Begriffe wie "Speerspitze" vermeiden möchten. Mit freundlichen Grüßen, benutze dieses Wort nicht.

Als Nebenproblem zu den oben genannten, überprüfen Sie, ob Sie etwas arbeiten. Ich habe viel Zeit als einsamer, selbstlernender Programmierer gearbeitet und weiß, wie einfach es ist, die eigentliche Arbeit beiseite zu legen, um vielversprechende Rahmenbedingungen, Technologien und dergleichen zu erkunden. Stellen Sie sicher, dass Ihre Leistung innerhalb der erwarteten Parameter liegt (nein, es interessiert niemanden, dass Sie 20 Stunden lang nach Spring suchen, wenn der von Ihnen angeforderte Bericht nicht fertig ist).

Vermeiden Sie aus all diesen Gründen , der Lehrer zu sein (es sei denn, es bezieht sich auf ein Gebiet/eine Technologie, in dem Sie tatsächlich genug Erfahrung haben). Eine neutralere Präsentation würde auf die Vorteile beispielsweise automatisierter Tests hinweisen und das Management entscheiden lassen, wer die Vor- und Nachteile dieser Praktiken untersuchen möchte.

Um diese "Best Practices" vorzustellen, gibt es zwei Möglichkeiten, sie Ihrem Team zu erklären:

  • Weil ich sage, dass dies die besten Praktiken sind, und das ist genug.
  • Weil sie nützlich sind und helfen, Probleme zu lösen.

Mit dem ersten Argument ist es unwahrscheinlich, dass sie Ihnen Aufmerksamkeit schenken, es sei denn, Sie sind der Chef oder ein sehr hochrangiges Mitglied des Teams. Und "Ich habe ein Buch von Knuth gelesen, das das sagt" oder "Die Leute von der SE sagen das" werden auch keinen Eindruck hinterlassen ("Diese Leute arbeiten hier nicht, also wissen sie nicht wirklich, was für diesen IT-Shop gut ist "). Ihre Methoden, Routinen, Verfahren und Dinge funktionieren "mehr oder weniger". Warum sollten Sie sich also die Mühe und das Risiko machen, Änderungen vorzunehmen?

Für den zweiten Arbeitsansatz muss erkannt werden, dass ein Problem vorliegt . Damit:

  • drücken Sie nicht Tag und Nacht auf automatische Tests. Warten Sie, bis ein Update einige Funktionen beeinträchtigt und das Team Überstunden leisten muss, um das Problem zu beheben, und schlagen Sie dann vor, ein automatisiertes Testsystem zu erstellen.
  • fragen Sie nicht nach Code-Bewertungen. Warten Sie, bis sich Joe in einem längeren Urlaub befindet und das Modul geändert werden muss, von dem nur Joe weiß, und zeigen Sie Ihrem Chef, wie viel Zeit verloren gegangen ist, wenn Sie nur versuchen, Joes Code zu verstehen.

Natürlich wird der Wandel langsam und progressiv sein (mehr noch in einem großen Unternehmen). Wenn Sie in fünf Jahren die Codeüberprüfung und das automatisierte Testen einführen möchten, sollten Sie sich zu einer gut gemachten Arbeit beglückwünschen. Aber wenn es nicht aufgrund externer Ursachen zu einem vollständigen Umschreiben kommt, vergessen Sie jede Fantasie, dass sie den Kern wechseln werden IS zu beispielsweise Spring ( Joel erklärte dies auf diese Weise) besser als ich es jemals könnte, noch bevor du geboren wurdest1 ); In dieser Zeit konnte Spring höchstens in die Liste der unterstützten Plattformen aufgenommen werden, um unkritische Systeme zu schreiben.

Willkommen in der Welt der Unternehmens-IT, Junge! :-p

1: Ok, vielleicht übertreibe ich ein wenig, aber nicht zu viel.

18
SJuan76

Sie sollten mit dem Buch Effektiv mit Legacy-Code arbeiten von Michael Feathers beginnen. Aus der Einleitung des Buches: "Es geht darum, ein verworrenes, undurchsichtiges, verschlungenes System langsam und schrittweise Stück für Stück Schritt für Schritt in ein einfaches, gut strukturiertes und gut gestaltetes System umzuwandeln." Er beginnt meistens mit automatisierten Tests, damit Sie sicher umgestalten können (Sie werden wissen, ob Sie etwas kaputt machen), und er enthält viele Strategien, um schwierigen Code unter automatisierte Tests zu bringen. Dies ist nützlich für jedes Projekt, das sich noch in der Entwicklung befindet. Sobald Sie eine grundlegende Reihenfolge festgelegt haben, können Sie sehen, von welchen anderen modernen Technologien Ihr Projekt wirklich profitieren könnte - aber gehen Sie nicht davon aus, dass Sie alle benötigen.

Wenn Sie ein neues Framework (oder etwas anderes) aus beruflichen Gründen lernen möchten, anstatt weil Ihr aktuelles Projekt es tatsächlich benötigt, sollten Sie es in einem persönlichen Projekt (in Ihrer Freizeit) verwenden.

12
user3067860

Quellcodeverwaltung.

Sie haben es nicht erwähnt, hoffentlich, weil es bereits vorhanden ist, aber falls nicht, beginnen Sie dort.

Die Quellcodeverwaltung hat den größten Vorteil, außer in seltenen Fällen, in denen pathologisch etwas anderes benötigt wird.

Und Sie können alleine anfangen, wenn sich zunächst niemand einkauft.

10

Finde einen Fehler. Beheben Sie einen Fehler. Zeigen Sie das Update.

Nehmen wir zuerst die Normalisierung *. Und in der Tat würde ich vorschlagen, dass Sie es zuerst nehmen, da mangelnde Normalisierung wahrscheinlich zu tatsächlichen Buggy-Daten führt, die sonst nicht existieren könnten, während der Rest Fälle sind, in denen Best-Practice wahrscheinlich helfen könnte, aber es schwieriger ist, "Bug" zu sagen A wurde dadurch verursacht, dass Richtlinie X nicht befolgt wurde ". Wenn Sie eine Datenbank haben, die nicht normalisiert ist, haben Sie einen Ort, an dem Daten inkonsistent sein können.

Es ist eine gute Wette, dass Sie einen tatsächlichen Fall inkonsistenter Daten finden können. Sie haben jetzt zwei Dinge gefunden:

  1. Ein Fehler in Ihren Daten.

  2. Ein Fehler in Ihren Datenbankschemata.

Sie wussten tatsächlich zuerst über den zweiten Fehler Bescheid, aber der erste ist leichter nachweisbar und auch etwas, das ein echtes Problem verursacht, nicht etwas, das theoretisch möglich wäre.

Leider ist einer der wirklichen Gründe, sich der Normalisierung der denormalisierten Datenbank zu widersetzen, dass die Frage, was mit solchen fehlerhaften Daten zu tun ist, nicht immer einfach ist, aber Sie haben einen tatsächlichen Fehler gefunden.

(Beachten Sie jedoch, dass es Gründe gibt, warum manchmal einige Daten absichtlich denormalisiert werden. Verwechseln Sie sachkundiges Brechen der Regel nicht mit Unkenntnis der Regel. Wenn Sie eine Tabelle normalisieren, die absichtlich für die Geschwindigkeit der Suche denormalisiert wird, haben Sie gewonnen Ich gewinne kein Lob. Auch hier sollte die Denormalisierung, die mit Belastungen behaftet ist, prozedural erfolgen. Wenn die denormalisierte Tabelle also nicht automatisch auf der Grundlage des Inhalts normalisierter Tabellen erstellt wird, sind noch Fortschritte zu erzielen.

Stellen Sie sie im Übrigen vor, wenn sie kurzfristig helfen, um später langfristig darauf aufzubauen. Z.B. Wenn Sie einen kleinen Code zum Erstellen erhalten, schreiben Sie einen Komponententest dafür. Besser noch, wenn Sie einen Fehler zur Behebung erhalten, schreiben Sie einen Komponententest, der aufgrund des Fehlers fehlschlägt, und erwähnen Sie dann, wenn Sie den Fehler behoben haben, die Tatsache, dass er vorübergeht, wenn Sie die Fehler schließen (oder senden Sie eine E-Mail, die besagt, dass er behoben ist , oder Wasauchimmer).

* Übrigens nicht sehr modern. Der Grund, warum es Normalisierung und nicht Normalisierung oder etwas anderes heißt, ist, dass es zu der Zeit ein aktueller Witz war, - ization auf dem zu bleiben Ende der Dinge, um sich über den Namen von Richard Nixons Vietnamization Politik lustig zu machen.

5
Jon Hanna

Schauen Sie sich in dem Team um, zu dem Sie gehören. Können Sie Beweise dafür sehen, dass testgetriebene Entwicklung oder Datenbanknormalisierung die Qualität der von Ihnen geschriebenen Software verbessern oder die Produktivität der Mitarbeiter steigern?

Haben Sie versucht, mit einem der Entwicklungsleiter oder dem Entwicklungsleiter darüber zu sprechen? Ein wirklich informeller Chat wäre ein guter Anfang. Was lässt Sie denken, dass die Leute über Ihnen nicht die gleichen Ideen hatten, diese aber nicht umsetzen können/wollen, weil das Unternehmen dies nicht zulässt?

Ich finde, dass es ein guter Weg ist, mit gutem Beispiel voranzugehen. Menschen sind viel weniger widerstandsfähig, wenn jemand anderes die Arbeit bereits erledigt hat und ihnen zeigen kann, wie man sie repliziert. Führen Sie TDD in ein Projekt ein, an dem Sie arbeiten. Bitten Sie darum, dem Rest des Teams oder sogar einigen anderen eine Präsentation zu geben und ihnen zu zeigen, was Sie getan haben. Was @DrewJordan über das Buy-In vom Chef gesagt hat, ist wichtiger, als Sie wahrscheinlich denken.

5
markp3rry

Ich werde gegen den Strich gehen und sagen: Finde einen neuen Job, nachdem ich einige Zeit in diesem verbracht habe, um deinen Lebenslauf ein wenig aufzubauen. Streben Sie ein Jahr oder so an. Obwohl viele Dinge "Schlagworte" sind, sind Probleme wie das völlige Fehlen von Unit-Tests für einen einzelnen Entwickler unlösbar, und wenn die dort arbeitenden Programmierer keine Lust zum Testen haben, werden Sie wahrscheinlich nie einen Kauf erhalten und sogar Ihre Position gefährden in der Firma, indem man die Leute dazu bringt, dich als blasenhart zu betrachten. Sie müssen an einem Ort sein, an dem Sie Mentoring erhalten können, nicht versuchen, die Kultur in Richtung Grundkompetenz voranzutreiben.

4
asthasr

Es gab viele Vorschläge zur Verbesserung des Programmierparadigmas . Die heißesten Schlagworte scheinen nun agile Programmierung und objektorientiert zu sein. Oder sind Sie? Beide sind im Vergleich zu vor fünf Jahren erheblich verblasst.

Sie können ziemlich sicher sein, dass mit jeder eingeführten Methodik das gleiche Endergebnis erzielt werden soll: Helfen Sie den Ingenieuren, ein Endprodukt wirtschaftlich herzustellen, das gut genug ist.

Es gibt ein Paradigma, das in den 1960er Jahren kontrovers eingeführt wurde: strukturierte Programmierung : Verwenden Sie nur Konstrukte auf "hoher Ebene" wie while, for, repeat , if/then/else, switch/case Anweisungen anstelle der häufig verwendeten goto Anweisung, die hatte wurde standardmäßig akzeptiert. Es gibt noch Debatten darüber, ob goto überhaupt eine legitime Verwendung hat.

Ich akzeptiere, dass die Minimierung der Verwendung von goto eine gute Sache ist, aber wie bei allen guten Dingen ist es möglich, zu weit zu gehen.

Sie erwähnen agile Methoden als etwas Positives. Ich war ungefähr sechs Monate in einem Entwicklungsteam, das absichtlich einem vorgeschriebenen agilen Regime folgte. Ich fand es genauso wie aufgeklärte Projektmanagementmethoden von vor Jahrzehnten, nur dass alles umbenannt wurde. Vielleicht können Unternehmen durch das Umbündeln und Weiterverkaufen von Ideen für die Kommunikation ihren Lebensunterhalt verdienen und Unternehmen können sich gut fühlen, wenn sie das die neuen Kleider des Kaisers sehen.

Die wertvollste Lektion von Agile, die vor langer Zeit bekannt war, ist, dass Flexibilität, um einen besseren Weg zum fertigen Produkt zu finden, eine gute Sache ist und die Fähigkeit, diesen Weg zu finden, von jedem kommen kann - nicht nur vom oberen Management.


Aus einem Schreiben des Anti-Goto-Rädelsführers Edsger Dijkstra:

Die Kunst des Programmierens ist die Kunst, Komplexität zu organisieren, die Menge zu meistern und das Chaos der Bastarde so effektiv wie möglich zu vermeiden.

- Dijkstra, in: Dahl, Dijkstra & Hoare 1972, pg. 6. (siehe Seite 6 hier .)

1
wallyk