Was tun, um als neues Team ein Projekt mit Wartbarkeitsproblemen zu leiten?

Ich bin gerade für ein Code-Projekt mit Wartbarkeitsproblemen verantwortlich gemacht worden. Was kann ich tun, um das Projekt auf eine stabile Basis zu stellen?

Ich befinde mich an einem Ort, an dem wir mit einem sehr großen mehrschichtigen .NET-System arbeiten, dem viele wichtige Dinge wie Unit-Tests, IOC, MEF, zu viele statische Klassen, reine Datensätze usw. fehlen erst 24 aber ich bin seit fast drei jahren hier (diese app ist seit 5 jahren in der entwicklung) und hauptsächlich aus zeitlichen gründen haben wir einfach mehr mist hinzugefügt, um dem anderen mist zu entsprechen. Nachdem ich in meiner Freizeit eine Reihe von Projekten durchgeführt hatte, begann ich zu verstehen, wie wichtig all diese Konzepte sind. Auch aufgrund des Mitarbeiterwechsels bin ich jetzt der Teamleiter bei diesem Projekt und möchte unbedingt einige clevere Möglichkeiten finden, um diese App zu verbessern. Möglichkeiten, wie der Wert dem Management erklärt werden kann. Ich habe Ideen, was ich gerne tun würde, aber sie scheinen alle so überwältigend zu sein, dass ich nicht viel im Voraus gewinnen kann. Jede Geschichte darüber, wie die Leute damit umgegangen sind oder wären, wäre eine sehr interessante Lektüre. Vielen Dank.

Budget Zeit, um technische Schulden anzugreifen. Du musst es einfach tun. Welche Teile Sie zuerst angreifen, hängt davon ab, wo Ihre Entwickler derzeit die meiste Zeit verbringen. Es ist jedoch wichtiger, dass Sie beginnen, als sich mit den idealen Dingen zu befassen. Wenn Sie Scrum verwenden, nehmen Sie bestimmte technische Schulden in Ihren Rückstand auf und behandeln Sie sie wie Funktionen, bis Sie sie in den Griff bekommen.

Effizientes Arbeiten mit Legacy-Code wird dringend empfohlen und ist wahrscheinlich nützlich. Ich habe es nicht gelesen, aber es scheint eine Menge Informationen darüber zu geben, wie Komponententests in Legacy-Code integriert werden können, damit Sie ihn sicher modifizieren und auf den neuesten Stand bringen können.

Verwenden Sie die Kreditkarten-Analogie mit dem Management - Sie "zahlen Zinsen" für alles, was Sie tun, weil es so schwer ist, etwas zu erreichen. Wenn Sie Ihre technischen Schulden bezahlen, werden Sie diese Ressourcen freisetzen und in Zukunft schneller neue Funktionen entwickeln können. Wenn Sie dies nicht tun, werden Ihre (in der Entwicklungszeit gezahlten) "Zinszahlungen" weiterhin akkumuliert und Ihr Team wird neue Funktionen langsamer produzieren.

Beginnen Sie vielleicht mit der Schätzung der Zeit, die Sie in jedem Zyklus mit der Bekämpfung der technischen Verschuldung verbringen, um eine Vorstellung davon zu bekommen, wie viel bereits angehäuft wurde. Beschreiben Sie, wie ein Fix oder eine Funktionsänderung in einem wartbaren System aussehen würde, wie es im tatsächlichen System aussehen würde und welche Änderungen vorgenommen werden müssten oder gute erste Schritte sein könnten, um dahin zu gelangen.

Führen Sie technische Schulden in Bugfixes und Zusatzfunktionen ein.

Ich habe festgestellt, dass ein iterativer Ansatz zur Verbesserung die besten Ergebnisse liefert. Das Mantra bei meiner Arbeit ist, die Qualität des Codes zu verbessern, wenn Sie ihn berühren. Jede Arbeit, ob es sich um eine Fehlerbehebung oder ein Feature handelt, beginnt mit einer Analyse dessen, was behoben / überarbeitet / bereinigt werden kann. Wir versuchen, den Refaktor der zu erledigenden Arbeit anzupassen.

Erstellen Sie eine geordnete Liste der Probleme in der Codebasis. Stellen Sie sicher, dass alle über die Liste und die Prioritätsreihenfolge informiert sind. Wann immer sie eine Arbeit bekommen, sollten sie nach einem Problem aus der Liste suchen, die mit dem Code verknüpft ist, an dem Sie arbeiten werden.

Das wird nicht alles reparieren. Es gibt einige Änderungen oder Korrekturen, die viel Zeit und Ressourcen erfordern. Ich versuche im Allgemeinen, diese mit anderen großen Arbeiten zu verknüpfen, die von Nutzen sind.

Ich könnte nur das Offensichtliche sagen, aber hey.

Schreiben Sie einen kleinen Komponententest, der einen Codeabschnitt ausführt, bei dem Probleme auftreten, und überarbeiten Sie dann den Code, um sicherzustellen, dass der Test weiterhin erfolgreich ist. Fahren Sie mit einem anderen Codeabschnitt fort, den Sie am einfachsten von diesem winzigen Teil des festen Bodens aus erreichen können, den Sie gerade gebaut haben. Aufschäumen, ausspülen, wiederholen.

Dies wird Ihnen auch dabei helfen, sich ein wenig mit der Codebasis vertraut zu machen.

Nachdem Sie das für eine Weile getan haben, werden Sie herausfinden, dass es Zeit ist, ein erweitertes Refactoring durchzuführen. Herausfinden von dupliziertem Code, Verstößen gegen das DRY-Prinzip ... Sie wissen, das Übliche. Bis dahin haben Sie eine wohl anständige Codeabdeckung, die es Ihnen ermöglicht, Methoden zu mischen, Schnittstellen und all diese Annehmlichkeiten zu extrahieren.

Lassen Sie die Codebasis immer etwas besser als zuvor, bevor Sie sich hineinhacken. Ich bin mir ziemlich sicher, dass sich eine kleine Investition auszahlt, auch auf kurze Sicht.

Sie könnten versuchen, die technische Verschuldung dieses Projekts zu erklären, um eine Vorstellung davon zu bekommen, wo Sie anfangen sollen. Sie könnten auch versuchen, zu verhandeln, dass aufgrund von Mitarbeiterwechseln einige Zeit aufgewendet werden muss, um sich mit dem Code vertraut zu machen. Dies bedeutet, dass einige Tests durchgeführt werden müssen, um eine bessere zukünftige Entwicklung zu gewährleisten, da die Tests helfen können, Fehler zu verhindern und die Dinge zu vereinfachen möglicherweise neue Leute, die an dem Projekt arbeiten.

In solchen Fällen versuche ich, das Projekt so weit wie möglich zu rationalisieren. Finden Sie heraus, welche Funktionen unbedingt erforderlich sind, damit es funktioniert. Jedes System, das es schon lange gibt, hat wahrscheinlich einen sehr langen Rückstand. Viele dieser Punkte werden kritisch sein und viele werden nur "Schnickschnack" sein.

In Bezug auf das Testen sind Unit-Tests auf jeden Fall hilfreich, aber Sie können einige der nicht-technischen Mitarbeiter bitten , sich an den Tests zu beteiligen und Fehler an Ihre Teammitglieder zu senden.

Viel Glück.

Eine Möglichkeit ist, Ihren Lebenslauf abzuwischen und mit der Jobsuche zu beginnen.

Eine gute Frage, die Sie sich stellen sollten, ist, ob dieses schlecht geführte Projekt darauf hindeutet, wie das gesamte Unternehmen geführt wird. Wenn die Antwort ja ist, fragen Sie, ob Sie genug bezahlt werden, um in einem schlecht geführten Unternehmen zu bleiben.

Oft können Sie das Refactoring durch das obere Management vorantreiben lassen, wenn Sie feststellen, dass es sich um eine Leistungsverbesserung handelt oder ein vorhandener Fehler behoben wird. Rechnen Sie nicht um, nur um etwas zu ändern, was Sie tun würden, besonders wenn es funktioniert. Fehlerbehebungszeit kann auch ein guter Weg sein, um in ein Refactoring zu passen, da Sie sowieso schon da sind. Sei selbstbewusst und sieh es nicht so an, als wärst du jünger als deine Kameraden. Beginnen Sie mit etwas Kleinem wie dem Einstieg in einige Unit-Tests und arbeiten Sie von dort aus. Sie können einige Fehler aufdecken, die das Management veranlassen kann, Ihnen Zyklen für andere Dinge zu geben.

Momentan lese ich die Brownfield-Anwendungsentwicklung in .NET , in der es darum geht, wie Sie mit den aktuellen Problemen umgehen können. Bisher gefällt mir das meiste, was darin steht (nicht alles - aber dies ist eine Art Buch, das Ihnen hilft, die Probleme auf eigene Faust zu durchdenken, und nicht ein Buch, das vollständig vorschreibend sein soll). Es kann in vielerlei Hinsicht hilfreich sein - es zeigt, dass Sie nicht allein sind; Es wird Ihnen hoffentlich Hinweise geben, wie Sie einige der Probleme angehen können.

Grundsätzlich stimme ich den meisten Ansätzen zu - Sie können das Problem nicht über Nacht beheben, sondern in sehr kleinen Schritten schrittweise verbessern. Und ja - Technical Debt ist die Metapher, die Sie verwenden müssen.

Letztendlich kommt es darauf an, wie gut Ihre Mitarbeiter am Projekt beteiligt sind. Wenn es die gleiche Crew ist, die das Chaos verursacht hat, dann hat man kaum eine Chance, es mit der gleichen Gruppe besser zu machen. Analysieren Sie Ihre Mitarbeiter, finden Sie Ihre schwächsten Mitglieder heraus und ersetzen Sie sie (sofern Sie dazu in der Lage sind).

"Aus dem Ohr einer Sau kann man keine Seidenhandtasche machen".