Wo soll mein Team anfangen, „modern“ zu werden? [geschlossen]

106

Ich bin ein relativ neuer Entwickler, frisch vom College. Während des Studiums und der anschließenden Arbeitssuche stellte ich fest, dass es viele "moderne" Softwareentwicklungsmethoden gab, denen meine Ausbildung fehlte: Komponententests, Protokollierung, Datenbanknormalisierung, agile Entwicklung (im Vergleich zu generischen agilen Konzepten), Codierungsstil Anleitungen, Refactoring, Code-Reviews, 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 mir diese bei der Arbeit beibringt. Dann bekam ich meinen ersten Job (Full Stack Web Development) 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 die ersten Versuche unternimmt, mein Team mit "modernen" Programmiertechniken auf den neuesten Stand zu bringen.

Zuerst habe ich mit der Protokollierungssoftware (log4J) begonnen, aber dann habe ich schnell meinen eigenen Styleguide geschrieben und ihn dann für den Google Styleguide aufgegeben - und dann festgestellt, dass unsere Java-Webentwicklung handgeschriebene Front-Controller verwendet Unsere Einführung von Spring - aber dann wurde mir klar, dass wir auch keine Komponententests hatten, aber ich lernte bereits Spring ... und wie Sie sehen, wird es allzu schnell überwältigend, besonders wenn es mit normaler Entwicklungsarbeit gepaart wird. Darüber hinaus fällt es mir schwer, in diesen Methoden "Experte" zu werden, um andere darin zu unterrichten, ohne zu viel Zeit einem einzelnen von ihnen zu widmen, geschweige denn allen.

Wie kann ich von all diesen Techniken, die ich in der heutigen Welt der Softwareentwicklung als "erwartet" erachte, sie als neuer Spieler in ein Team integrieren, ohne mich und das Team zu überfordern?

Wie kann ich mein Team dazu bringen, agiler zu werden? ist verwandt, aber ich bin kein Agile-Entwickler wie der Fragesteller hier, und ich betrachte einen viel breiteren Satz von Methoden als Agile.

WannabeCoder
quelle
92
"modern"? Entfernen Sie dieses "agile" Schlagwort aus Ihrer Liste, und ich kann nur Dinge mit einem Alter von> 20 Jahren sehen.
Doc Brown
10
Vielleicht "modern" in dem Sinne, dass eine breite Akzeptanz von ihnen modern ist und nicht die Gene der Ideen? Ich bin auch kein Experte auf diesem Gebiet, das ist nur mein Eindruck.
WannabeCoder
41
Ich versichere Ihnen, dass Unit-Tests, Protokollierung, Datenbanknormalisierung, Coding-Style-Guides und Code-Inspektionen (= Überprüfungen) älter als 30 Jahre sind. Der Begriff "Refactoring" ist mindestens 15 Jahre alt (Fowler schrieb sein Buch im Jahr 2000). Und keine formalen Unterlagen oder schriftlichen Anforderungen zu haben, ist keine "moderne Technik", es ist IMHO nicht einmal eine "Technik".
Doc Brown
69
@DocBrown, gib es zu, du hast Marty gerade rechtzeitig zurückgeschickt, um all diese Dinge zu erstellen, bevor du deinen Kommentar abgibst.
null
17
Ich mache mir mehr Sorgen, dass sein College diese Dinge nicht von vornherein lehrt - ich bin seit über 15 Jahren nicht mehr in der Schule und die meisten dieser Dinge wurden ziemlich früh behandelt. (Abzüglich der Schlagworte natürlich).
Allen Gould

Antworten:

165

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

Was ist das Hauptproblem, mit dem Ihr Team konfrontiert ist, und welche Technologien könnten Abhilfe schaffen?

Wenn zum Beispiel viele Fehler vorliegen, insbesondere Fehler vom Regressionstyp, kann Unit-Testing ein Ausgangspunkt sein. Wenn Ihrem Team die Zeit fehlt, hilft möglicherweise ein Rahmen (mittel- bis langfristig). Wenn die Leute Schwierigkeiten haben, den Code des jeweils anderen zu lesen, kann das Stylen nützlich sein.

Denken Sie daran, dass der Zweck des Geschäfts, für das Sie arbeiten, darin besteht, Geld zu verdienen, nicht Code zu machen.

Jaydee
quelle
35
Ja schon. Teilweise aus der pragmatischen Perspektive, irgendwo anfangen zu müssen, und teils aus der Sicht der Reputation, dass sie möglicherweise eher bereit sind, auf andere Vorschläge zu hören, wenn Sie ein Problem für das Team beheben können. Denken Sie auch daran, dass dieses Unternehmen Geld verdient hat, bevor Sie mit den vorhandenen Methoden ankamen. Was Sie also eingeführt haben, muss die Fähigkeit des Unternehmens, Geld zu verdienen, erhöhen.
Jaydee
6
Akzeptiere dies, aber ich würde mich über ein Follow-up
freuen
4
@WannabeCoder - Sie müssen mit der Verwendung beginnen, bevor Sie über ausreichende Kenntnisse verfügen. Sie können weiterhin Code in die Produktion einbinden. Manchmal ist das Kodieren wie ein Arzt. Wir üben alle noch.
JeffO
5
Gute Antwort. Sie sollten diese Dinge nur implementieren, um Probleme zu lösen, nicht um Probleme herzustellen.
Kik
5
@WannabeCoder Es ist wichtig zu wissen, dass keine dieser Methoden im luftleeren Raum erstellt wurde. Sie breiten sich aus, weil sie helfen, Probleme zu lösen . Wenn Sie versuchen, sie umzusetzen, und sie helfen nicht, Probleme zu lösen, mit denen Ihr Team konfrontiert ist, haben Sie nichts erreicht und möglicherweise die Praktiken völlig missverstanden und missbraucht. Als Entwickler sollten Sie sich darauf konzentrieren , Probleme bei jeder Ihrer Aktionen zu lösen . Suchen Sie nach kleinen Gewinnen, bei denen sich die Situation verbessern lässt, wenn Sie diese Praktiken nur ein wenig weiter anwenden. Auf diese Weise können Sie ein Argument für deren Erweiterung erstellen.
jpmc26
77

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 noch etwas Neues lernen, um Schritt zu halten!

Oder Sie könnten akzeptieren, dass keine Menge von Modeworttechnologien, -methoden oder -frameworks oder anderen Du Jours die Tatsache ändern wird, dass Sie Qualitätsprodukte entwickeln möchten, die funktionieren. Es spielt keine Rolle, wenn Sie nicht agil sind, wenn Sie die richtige Ausgabe erfolgreich produzieren. Wenn dies nicht der Fall ist, möchten Sie möglicherweise Änderungen vornehmen, aber es besteht die Möglichkeit, dass keine besondere Übung zur Behebung der Probleme erforderlich ist. Sie bleiben menschliche Probleme , die auf verschiedene Arten behoben werden können.

Was professionellen Selbstmord betrifft, wenn Sie wissen, was Sie tun und flexibel sind, brauchen Sie keines der genannten Dinge. Die Leute werden weiterhin neue Wege finden, um die alte Arbeit zu erledigen, und Sie werden immer aufholen. Oder Sie können einfach alle Techniken verwenden, die Ihr aktuelles Unternehmen verwendet, unabhängig davon. Wenn Sie Ihr Unternehmen wechseln, lernen Sie einfach die Techniken, die sie verwenden, und wenden sie an.

Zu viele Kinder hängen an all den neuen Werkzeugen, die sie verwenden könnten, und vergessen, dass diese Werkzeuge für Anfänger wertlos sind. Lernen Sie die Übung zuerst, sobald Sie ein erfahrener Entwickler sind, können Sie anfangen, die Entwicklungspraktiken mit "coolen neuen Dingen" zu "reparieren", aber bis dahin werden Sie hoffentlich bemerkt haben, dass sie bei weitem nicht so wichtig sind, wie Sie derzeit denken, und Nur zu verwenden, wenn sie wirklich gebraucht werden.

gbjbaanb
quelle
4
Sehr nette Antwort (+1), besonders der letzte Absatz. Ein sehr modernes Buch (modern in dem Sinne, dass ich es heute sehr relevant finde), das ich kürzlich lese, ist SICP.
Giorgio
1
+1 für die Angabe, wie schnell sich diese Schlagworte und populären Sprachen ändern. Ein guter Entwickler, der guten Code veröffentlicht, übertrifft jede Methode. Mach was funktioniert und was gut funktioniert!
WeRelic
2
Sie haben zwar Recht, dass diese ordnungsgemäß verwendet werden müssen, aber ich bin nicht der Meinung, dass "sie bei weitem nicht so wichtig sind, wie Sie derzeit denken". Okay, sicher, das mag für einige Praktiken zutreffen (ich bin etwas skeptisch gegenüber Unit-Tests), aber andere sind äußerst wertvoll. Ich hatte die Gelegenheit, frühzeitig mit CI und Automatisierung sowie der Nutzung der Quellcodeverwaltung zu beginnen. Bei der Arbeit an einem Projekt, bei dem diese nicht vorhanden sind, sehe ich alle Probleme, die wir lösen wollten, in Aktion: Fehler, Inkonsistenzen , keiner weiss wo welcher code ist, das klappt. Diese Praktiken machen einen großen Unterschied.
jpmc26
6
Niemand sagt "Löse keine Probleme". Das Problem ist, wenn Lösungen vorgestellt werden, die nach zu lösenden Problemen suchen. Sie sind nicht so wichtig wie viele denken, die Frachtkultisten denken, die Werkzeuge sind der wichtige Teil, wo sie eigentlich nur Werkzeuge sind. Es ist der Praktiker, der zählt, und welche Werkzeuge an den richtigen Stellen eingesetzt werden, entscheiden Sie. Mein Punkt ist, niemals ein Werkzeug zu wählen, nur weil es in der Toolbox ist.
gbjbaanb
2
Ein Narr mit einem Werkzeug ist immer noch ein Narr.
Pete Becker
40

Viele Unternehmen stecken so fest; Es könnte Sie sogar überraschen, dass einige Ihrer Entwicklerkollegen Autodidakten sind und Entwickler ohne jeglichen formalen Hintergrund wurden. Diese Entwickler sind oft besser in ihrer Arbeit, da sie motiviert sind, neue Fähigkeiten zu erlernen und erfolgreich zu sein, anstatt einfach die Arbeit zu erledigen. Leider kann dies auch bedeuten, dass sie zwar hervorragend programmieren können, sich jedoch möglicherweise der Vorteile dieser Praktiken nicht bewusst sind. Tatsache ist, dass dies Best Practices sind, keine gängigen Praktiken. Die besten verwenden sie, aber sie sind nicht unbedingt Voraussetzung für den Erfolg, sie sind einfach Werkzeuge, um den Erfolg zu erleichtern.

Sie haben vollkommen recht, es wird überwältigend sein, alles auf einmal zu implementieren. Sie werden sich wahrscheinlich selbst (und möglicherweise Ihr Team) verbrennen, wenn Sie versuchen, dies zu tun, was zukünftige Anstrengungen zur Einführung neuer Methoden / Technologien demotivieren wird. Das Beste , was wie dies in einer Situation zu tun ist , wählen Sie einSache (Protokollierung ist wahrscheinlich ein guter Anfang, da Sie wahrscheinlich einen schwierigen Weg vor sich haben, um Fehler zu finden, ohne sich zu protokollieren, und es wird sicher Fehler geben) und sprechen Sie mit dem Team darüber. Sie müssen dies nicht im Alleingang umsetzen. Sie können die Vor- und Nachteile viel besser mit dem Team (und Ihrem Chef, der unbedingt an Bord sein MUSS) besprechen und einen Plan für dessen Umsetzung ausarbeiten. Es muss so schmerzfrei wie möglich sein (denken Sie daran, dass Sie den Leuten sagen, dass sie jetzt zusätzlich zu dem, was sie bereits tun , zusätzlichen 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 die Geschwindigkeit von Fixes / Releases langsamer wird, 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, kämpfen Sie bestenfalls in einem verlorenen Kampf, und im schlimmsten Fall werden Sie von ihnen als aktiv sabotiert betrachtet (fragen Sie mich, woher ich das weiß).

Wenn Sie diese Elemente auf den Tisch gebracht haben, besprechen Sie sie mit dem Team, planen Sie, wie sie implementiert werden sollen, und führen Sie die Schritte 2, 3, 8 usw. einfacher durch. Darüber hinaus besteht für das Team und Ihren Chef das Potenzial, Respekt für Sie zu gewinnen, da Ihre Vorschläge umgesetzt und als Mehrwert anerkannt werden. Toll! Stellen Sie einfach sicher, dass Sie flexibel bleiben: Sie drängen hier gegen die Trägheit, und Änderungen sind nicht einfach. seien Sie bereit, langsam klein zu machenÄnderungen vornehmen und sicherstellen, dass Sie den Fortschritt und den erzielten Wert nachverfolgen können. Wenn Sie die Protokollierung in einem neuen Prozess implementieren und dadurch in drei Wochen Stunden beim Auffinden eines Fehlers einsparen können, sollten Sie eine große Sache unternehmen! Stellen Sie sicher, dass jeder weiß, dass das Unternehmen nur XXX $ gespart hat, indem Sie rechtzeitig das Richtige tun. Wenn Sie dagegen einen Pushback erhalten oder eine knappe Frist haben, sollten Sie das Problem nicht 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 dazu zu zwingen, etwas zu tun, das sie nicht tun möchten, und Sie können sicher sein, dass das erste, was sie vorschlagen, die neue "zusätzliche" Arbeit ist (wie das Schreiben von Protokollen oder das Folgen von Aufgaben) ein Styleguide, anstatt es einfach zum Laufen zu bringen.

DrewJordan
quelle
6
Ich bezweifle, dass Sie es ernst gemeint haben, aber ich ärgere mich irgendwie über Entwickler wie mich, die keine Universitätsausbildung haben. Ich habe (leider) die Erfahrung gemacht, dass die Hochschulausbildung wenig mit der Entwicklerqualität zu tun hat. Und in meiner bisherigen Karriere war ich einer der Befürworter und Umsetzer von Best Practices. Ihr Rat ist jedoch großartig.
Dienstag,
5
Eigentlich meinte ich es andersherum: Das OP wäre überrascht, wie viele gute Entwickler es ohne formale Ausbildung gibt. In den letzten 20/30 Jahren haben sich viele technische Stellen geöffnet, die von lernwilligen Menschen anstelle von Kindern mit einem Abschluss besetzt wurden. Und meine Ergebnisse spiegeln Ihre wider: Erfahrung ist immer besser als Bildung. Das ist der Grund, warum das OP langsam voranschreiten muss. Wenn Sie ein Team dazu drängen, neue Praktiken zu schnell einzuführen, werden Sie ihn verärgern, und er wird nicht die Erfahrung haben, diese Einstellungen zu mildern. Es ist auch wichtig zu erkennen, dass einige Teams diese Tools niemals verwenden werden. Dann bekommst du einen neuen Job.
DrewJordan
1
"Viele Unternehmen stecken so fest. Es könnte Sie sogar überraschen, dass einige Ihrer" Entwicklerkollegen "Autodidakten sind und Entwickler ohne jeglichen formalen Hintergrund werden." Aufgrund ihrer Fachkompetenz erweisen sich diese häufig als die wertvollsten Entwickler.
pmf
Richtig, ich stimme vollkommen zu. Der erste Absatz wurde umformuliert, damit er weniger herablassend klingt. Ich wollte nur sicherstellen, dass OP weiß, dass ein großer Teil der Belegschaft dort draußen keinen offiziellen Hintergrund hat. Schlechte Wortwahl meinerseits.
DrewJordan
18

Ich hoffe, Sie haben die Themen Ihren Mitarbeitern nicht so vorgestellt, wie Sie es 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 noch keine Erfahrung haben, die vielleicht ein wenig 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. Mit freundlichen Grüßen, verwenden Sie dieses Wort nicht.

Überprüfen Sie als Nebenproblem, ob Sie Arbeiten ausführen . Ich arbeite seit langer Zeit als einzelner, selbstlernender Programmierer, und ich 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, niemand kümmert sich darum, dass Sie 20 Stunden lang nach Spring forschen, wenn der Bericht, den Sie angefordert haben, nicht fertig ist).

Von allen oben genannten, vermeiden die Lehrer zu sein (es sei denn , es auf ein Feld / Tech , in dem Sie tatsächlich genug Erfahrung haben verwandt ist). Eine neutralere Darstellung würde die Vorteile von beispielsweise automatisierten Tests aufzeigen 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 Jungs von der SE sagen das", machen auch keinen Eindruck ("die Jungs arbeiten hier nicht, also wissen sie nicht wirklich, was für diesen IT-Shop gut ist "). Sie haben ihre Methoden, Routinen, Prozeduren und Dinge "mehr oder weniger" funktionieren. Warum also den Aufwand und die Risiken von Veränderungen auf sich nehmen?

Für den zweiten Ansatz muss die Erkenntnis vorliegen, dass ein Problem vorliegt . Damit:

  • Schieben Sie nicht Tag und Nacht, um automatische Tests durchzuführen. Warten Sie, bis ein Update einige Funktionen nicht mehr unterstützt und das Team Überstunden machen muss, um das Problem zu beheben, und schlagen Sie dann vor, ein automatisiertes Testsystem zu erstellen.
  • Fragen Sie nicht nach Code-Reviews. Warten Sie, bis sich Joe in einem längeren Urlaub befindet und Sie das Modul ändern müssen, das nur Joe kennt, und zeigen Sie Ihrem Chef, wie viel Zeit beim Versuch, Joes Code zu verstehen, verloren gegangen ist.

Natürlich wird der Wandel langsam und fortschreitend sein (in einem großen Unternehmen mehr). Wenn Sie in fünf Jahren die Codeüberprüfung und das automatisierte Testen einführen können, sollten Sie sich zu einer gelungenen Arbeit beglückwünschen. Vergessen Sie jedoch, es sei denn, es gibt aufgrund äußerer Ursachen eine vollständige Neufassung, jede Fantasie, die den Kern-IS auf etwa Spring umstellt ( Joel erklärte dies besser, als ich es jemals könnte, noch bevor Sie geboren wurden 1 ). In dieser Zeit könnten Sie höchstens Spring in die Liste der unterstützten Plattformen aufnehmen, um unkritische Systeme zu schreiben.

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

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

SJuan76
quelle
1
Meist nicht einverstanden. Die einzige Möglichkeit, sich in einem Team zu verändern, besteht darin, dass jemand bereit ist, Nachforschungen anzustellen und den Rest mit sich zu ziehen. Natürlich solltest du produktiv bleiben, aber wenn jeder seinen Kopf niedrig hält, landest du "ein wenig veraltet, aber du erledigst die Arbeit". Und völlig aus Langeweile ausgebrannt.
Winkbrace
@winkbrace Ich behaupte nicht, dass Sie nicht versuchen sollten, zu verbessern (in der Tat sage ich das Gegenteil). Aber diese Änderungen ohne die Unterstützung des Managements und ohne die Autorität eines gewissen Dienstalters durchzusetzen, kann ziemlich schwierig sein und Widerstände hervorrufen. Hinzu kommt, dass das OP selbst kein Experte ist und möglicherweise Probleme mit der tatsächlichen Implementierung hat. Es wäre schön, wenn das OP sich freiwillig an ein Forschungs- / Prototyping-Team wenden könnte, um Änderungen ordnungsgemäß einzuführen. aber es ist ihm untersagt, vorsichtig zu sein, wenn er den richtigen Ansatz wählt, um diese zu fördern und geduldig zu sein.
SJuan76
@winkbrace für die Langeweile bisschen, es hängt von Ihrer Persönlichkeit und was Sie in einem Job suchen. Es ist sinnvoll zu versuchen, in einer Arbeitsposition zu landen, die Sie zufriedenstellt, anstatt irgendwohin zu gehen und zu versuchen, die Organisation nach Ihrem Geschmack zu ändern. Und normalerweise sind große Unternehmen (mit Ausnahme der F & E-Abteilungen) nicht der richtige Ort für Leute, die alle paar Monate eine neue Technologie testen möchten.
Sonntag,
Es ist ein wenig durcheinander zu sagen "Stellen Sie sicher, dass Sie tatsächlich arbeiten". Sicher, Sie sollten die Arbeit machen, aber Sie müssen auch langfristig denken und jeden Tag sollten Sie sich verbessern. Ich habe 5 Monate gebraucht, um unseren Manager dazu zu bringen, sich darauf einzulassen, dass Unit-Tests auch dann hilfreich sind , wenn wir versuchen, "schnell" zu codieren. Aber ich brauchte hier und da alle paar Tage 10 Minuten, damit das passierte.
Rudolf Olah
@omouse Ich habe gerade auf ein Risiko hingewiesen, das mich bei Recherchen manchmal getroffen hat. Sicherlich sehe ich dieses Risiko nicht in der von Ihnen beschriebenen Situation, aber die Form, in der das OP seine Forschung beschreibt ("zuerst habe ich angefangen mit ... dann bin ich schnell umgezogen ..."), hat mich zu dieser Vorsicht veranlasst. Beachten Sie, dass ich nicht behaupte, dass der OP seine zugewiesene Arbeit nicht ordnungsgemäß erledigt (das ist etwas, das ich einfach nicht weiß und das ist sein Chefjob), ich warne ihn nur, um sicherzustellen, dass er nicht zu sehr mitgerissen wird .
SJuan76
12

Sie sollten mit dem Buch Working Effectively with Legacy Code von Michael Feathers beginnen. In der Einleitung des Buches heißt es: "Es geht darum, ein verwickeltes, undurchsichtiges, verschlungenes System Stück für Stück und Schritt für Schritt langsam und schrittweise 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, wenn Sie etwas kaputt machen), und er enthält viele Strategien, um schwierigen Code automatisiert zu testen. Dies ist nützlich für jedes Projekt, das sich noch in der Entwicklung befindet. Sobald Sie eine Grundordnung erstellt 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 erlernen möchten, anstatt dass Ihr aktuelles Projekt es tatsächlich benötigt, sollten Sie es in einem persönlichen Projekt verwenden (in Ihrer Freizeit).

user3067860
quelle
Ich stimme Themen in Effektiv mit Legacy-Code arbeiten zu, aber es ist nicht sehr kompakt. Nehmen Sie es als Referenz und werfen Sie einen Blick auf die Kapitel, anstatt zu erwarten, dass Sie es wie einen Roman lesen.
Lukas
10

Quellcodeverwaltung.

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

Die Quellcodeverwaltung ist das größte Problem, außer in seltenen Fällen, in denen pathologisch etwas anderes erforderlich ist.

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

Emilio M Bumachar
quelle
1
Größter Knaller ist eher wie ein paar ASSERTs an den richtigen Stellen.
Peter Mortensen
@PeterMortensen Stimmt, aber nur, wenn Sie wissen, wo die richtigen Stellen sind.
Emilio M Bumachar
Du warst schneller als ich. Egal in welche Richtung der OP sein Team führt, mit Git wird es viel einfacher und produktiver als ohne.
Dotancohen
6

Eine direkte Antwort

Andere Antworten sind gute „Metapunkte“ für die Annahme besserer Praktiken. Um Ihnen jedoch einige direkt relevante Hinweise zu geben, folgt eine grobe Reihenfolge der bewährten Praktiken, die Ihr Team (oder ein beliebiges Team) (zuerst) annehmen sollte:

  1. Quellcodeverwaltung
  2. Issue Tracking (Projekt- und Aufgabenmanagement)
  3. Automatisierte Builds 1
  4. Automatisierte Bereitstellungen

1 Eine sehr ähnliche Vorgehensweise besteht darin , das Einrichten der Build- und Entwicklungsumgebung für jede App oder jedes Softwareprojekt, die bzw. das Sie entwickeln oder verwalten, zu automatisieren oder zumindest zu dokumentieren . Es ist viel weniger nützlich, weil Sie dies (hoffentlich) selten oder selten tun.

Alles andere

Sie erwähnen einige andere bewährte Methoden - "Komponententests, Protokollierung, Datenbanknormalisierung, ... Refactoring, ... Dokumentation" - aber all diese Methoden können und sollten schrittweise und schrittweise übernommen werden. Keiner von ihnen müssen auf einmal angenommen werden , und Sie werden sie wahrscheinlich besser annehmen überhaupt von ihnen sorgfältig und achtsam Annahme.

Die vier oben aufgeführten Praktiken werden auch das Übernehmen und Experimentieren mit neuen Praktiken so einfach wie möglich machen. Beispielsweise können Komponententests in Ihre automatisierten Builds integriert und Dokumentationen als Teil Ihrer automatisierten Bereitstellungen veröffentlicht werden.

Einige der anderen Praktiken, die Sie erwähnen - "Agile Entwicklung, ... Coding-Style-Guides, ... Code-Reviews, ... standardisierte Dokumentationsmethoden" und Frameworks (z. B. Spring) - sind wirklich optional oder von zweifelhaftem Wert. Und das gilt für viele (die meisten?) Möglichen Praktiken, die Sie entdecken oder denen Sie begegnen werden.

Agile Entwicklung ist offensichtlich keiner anderen Methodik überlegen. Und viele Leute (einschließlich ich) haben schreckliche Erfahrungen damit gemacht. Aber viele Leute mögen es wirklich (oder lieben es) auch. Versuch es!

Das Codieren von Styleguides kann hilfreich sein, insbesondere bei großen Projekten oder in großen Teams, aber es ist auch eine Menge Arbeit, um diese Richtlinien durchzusetzen , und das ist möglicherweise nicht die beste Nutzung der Zeit , die derjenige verwendet, der dies tut.

Code-Überprüfungen können auch sehr hilfreich sein - haben Sie Ihre Kollegen gebeten, Ihren Code zu überprüfen? Denken Sie daran, dass Sie keinen formellen Prozess benötigen, um bewährte Verfahren einzuführen!

Die Dokumentation ist großartig - haben Sie überhaupt welche? Wenn ja, gut für dich! Stehen Sie vor einer Menge zusätzlicher Arbeiten, die durch (mehr) "standardisierte" Dokumentation verhindert werden könnten? Wenn ja, dann lohnt es sich wahrscheinlich, das zu tun. Wenn Ihre Software jedoch von einer kleinen Gruppe von Personen verwendet wird, benötigen Sie möglicherweise keine Dokumentation. (Oder Sie können die Dokumentation direkt in Ihre Software integrieren. Das ist immer meine Präferenz.)

Frameworks sind ... ein (sehr scharfes) zweischneidiges Schwert. Eine gut gekapselte und gut gewartete Lösung für eine Nicht-Kernfunktion Ihrer Software ist großartig ... bis es nicht so ist. Ich bin mir nicht sicher, was "handgeschriebene Front-Controller" genau sind, aber es gibt keine offensichtliche Erklärung, warum sie dem Code, der Spring nutzt, unterlegen sind. Haben Sie darüber nachgedacht, die gemeinsame Logik in all diesen Controllern in Ihr eigenes internes Framework zu integrieren? Das Übernehmen von Spring und das Umschreiben des gesamten vorhandenen Codes kann ein immenses Umgestaltungsprojekt sein (oder, wahrscheinlicher, das Umschreiben), und dies ist möglicherweise nicht die beste Änderung, die Sie an Ihrem Code vornehmen können . Natürlich sollten Sie nicht die gesamte Software schreiben, die Sie verwenden - Frameworks (und Bibliotheken) sind großartig!Aber vielleicht müssen Sie Spring (oder eine Alternative) nicht verwenden, um großartige (oder gute) Web-Apps zu schreiben.

Kenny Evitt
quelle
Ich würde automatisierte Regressionstests mit automatisierten Builds und Deployments genau dort platzieren. Es hat auch den Vorteil, dass Sie inkrementell daran arbeiten können.
Sdenham
Unit-Tests sollten zunächst manuell und immer lokal (oder bei jedem Check-out / Check-in) ausgeführt werden. Anschließend sollte der Rest des Teams sich für automatisierte Regressionstests entscheiden. Es gibt wirklich Entwickler, die aus irgendeinem Grund Angst haben, ständig Tests durchzuführen.
Rudolf Olah
5

Schauen Sie sich in dem Team um, zu dem Sie gehören. Können Sie Beweise dafür finden, 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, sie aber nicht umsetzen können / wollen, weil das Geschäft es nicht zulässt?

Ich halte es für einen guten Weg, mit gutem Beispiel voranzugehen. Die Leute 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 den Rest des Teams oder sogar ein paar andere um eine Präsentation und zeigen Sie ihnen, was Sie getan haben. Was @DrewJordan über das Einsteigen vom Chef gesagt hat, ist wichtiger, als Sie sich wahrscheinlich vorstellen.

markp3rry
quelle
5

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, weil ein Mangel an Normalisierung wahrscheinlich zu fehlerhaften Daten führt, die sonst nicht existieren könnten, während der Rest Fälle sind, in denen bewährte Methoden wahrscheinlich helfen könnten, aber es schwieriger ist, "Fehler" zu sagen A wurde dadurch verursacht, dass die 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 in der Lage sind, einen tatsächlichen Fall inkonsistenter Daten zu finden. Sie haben jetzt zwei Dinge gefunden:

  1. Ein Fehler in Ihren Daten.

  2. Ein Fehler in Ihrem Datenbankschema.

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

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

(Beachten Sie jedoch, dass es Gründe gibt, aus denen man manchmal absichtlich Daten denormalisieren kann. Verwechseln Sie nicht das Verstoßen gegen die Regel mit der Unkenntnis der Regel. Wenn Sie eine Tabelle normalisieren, die absichtlich denormalisiert wurde, um die Suche zu beschleunigen, haben Sie gewonnen Auch hier sollte das Denormalisieren sehr aufwendig sein. Wenn die denormalisierte Tabelle also nicht automatisch auf der Grundlage des Inhalts normalisierter Tabellen erstellt wird, sind noch Fortschritte zu verzeichnen.

Stellen Sie sie im Übrigen vor, wenn sie kurzfristig helfen, um sie später langfristig weiter auszubauen. Wenn Sie beispielsweise einen kleinen Code zum Erstellen erhalten, schreiben Sie einen Komponententest dafür. Besser noch, wenn Sie einen zu behebenden Fehler erhalten, schreiben Sie einen Komponententest, der aufgrund des Fehlers fehlschlägt. Wenn Sie den Fehler behoben haben, erwähnen Sie die Tatsache, dass der Fehler durch das Schließen der Fehler behoben wird (oder senden Sie eine E-Mail, die besagt, dass der Fehler behoben ist , oder Wasauchimmer).

* Übrigens nicht sehr modern. Der Grund ist es genannt wird , Normalisierung und nicht Normalisieren oder etwas anderes ist, dass es an der Zeit , ein aktueller Witz zu halten -ization am Ende der Dinge Spaß des Namen von Richard Nixons zu machen Vietnamization Politik.

Jon Hanna
quelle
4

Ich werde gegen den Strich gehen und sagen: Finde einen neuen Job, nachdem du einige Zeit in diesem verbracht hast, um deinen Lebenslauf ein wenig zu erstellen. Streben Sie ein Jahr oder so an. Obwohl es sich bei vielen Dingen um Modewörter handelt, sind Probleme wie das völlige Fehlen von Komponententests für einen einzelnen Entwickler nicht zu bewältigen. Wenn die dort arbeitenden Programmierer keine Lust zum Testen haben, werden Sie nie etwas kaufen und möglicherweise sogar Ihre Position gefährden im Unternehmen, indem man die Leute dazu bringt, Sie als blasenhart zu betrachten. Sie müssen an einem Ort sein, an dem Sie sich beraten lassen können, und nicht versuchen, die Kultur in Richtung Grundkompetenz zu treiben.

asthasr
quelle
3
Genau das habe ich getan. Es gab nur ein Mal (von ~ 5 Versuchen an verschiedenen Orten), an dem ich erfolgreich neue "gute Praktiken" einführte oder bestehende Praktiken erheblich veränderte. Damals war das Team frisch und wir begannen die meisten Projekte von Grund auf neu . In allen anderen Fällen wurden bewährte Verfahren entweder von oben eingeführt (Teamleiter) oder scheiterten einfach, weil niemand anderes daran teilnahm. Ich glaube, alles hängt von der Fähigkeit ab, Ihre Entscheidung zu erzwingen, indem Sie ein Anführer / Chef sind.
Skript
1

Es gab viele Vorschläge zur Verbesserung des Programmierparadigmas . Die heißesten Schlagworte scheinen nun agiles Programmieren und objektorientiertes Arbeiten zu sein. Oder sind Sie? Beide sind im Vergleich zu vor fünf Jahren erheblich zurückgegangen.

Sie können sich ziemlich sicher sein, dass mit jeder Methode das gleiche Endergebnis erzielt werden kann: Sie können den Ingenieuren helfen, wirtschaftlich ein Endprodukt zu produzieren, das gut genug ist.

Es ist ein Paradigma , das kontrovers in den 1960er Jahren eingeführt wurde: die strukturierte Programmierung : nur „high level“ verwenden Konstrukte wie while, for, repeat, if/ then/ else, switch/ caseAussagen anstelle der stark frequentierten gotoAussage , die standardmäßig akzeptiert worden war. Es gibt immer noch Debatten darüber, ob gotoeine legitime Verwendung überhaupt möglich ist.

Ich akzeptiere, dass gotoes eine gute Sache ist, den Gebrauch zu minimieren , aber wie bei allen guten Dingen ist es möglich, zu weit zu gehen.

Sie erwähnen agileMethoden als etwas Positives. Ich war ungefähr sechs Monate lang in einem Entwicklungsteam, das absichtlich einem vorgeschriebenen agilen Regime folgte. Ich fand es genauso wie aufgeklärte Projektmanagementmethoden vor Jahrzehnten, nur dass alles umbenannt wurde. Vielleicht können Unternehmen durch das Bündeln und Wiederverkaufen von Ideen für die Kommunikation von jemandem ihren Lebensunterhalt verdienen und sich gut fühlen, wenn sie 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 Vielfalt 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 .)

wallyk
quelle