Transfert de projet

Question

Je voudrais connaître votre expérience lorsque vous avez besoin de prendre en charge le projet logiciel d'un autre utilisateur - d'autant plus que le développeur original a déjà démissionné.

Answer 1

Cas où devs originaux feuilles avant la remise du projet sont toujours le plus intéressant: vous êtes coincé avec une base de code dans un état inconnu. Ce que je trouve toujours intrigant, c'est comment les nouveaux développeurs font souvent de leur mieux pour commenter la façon dont le code est mal conçu: ils oublient les contraintes auxquelles les anciens développeurs pouvaient être confrontés, les raccourcis qu'ils auraient dû faire. Le dicton est toujours Vieux dev == mauvais dev. Que pensez-vous: Je dirais même que c'est une mauvaise pratique officielle: dénigrer ceux qui ont été avant nous.

J'essaie d'adopter une approche aussi pragmatique que possible: apprenez la base de code, flânez un peu. Essayez de comprendre la relation entre les exigences et le code, même s'il n'y a pas de relation initiale claire du tout. Il y aura toujours le «moment aha» quand vous réaliserez pourquoi ils ont fait quelque chose de ce genre. Si vous êtes toujours convaincu que quelque chose est mal implémenté, faites vos refactorings si possible. Et isoler les morceaux de code que vous ne pouvez pas changer: unité les tester en utilisant un cadre moqueur.

Salut au développeur de maintenance.

Answer 2

Le plus grand succès que nous avons eu avec cela est de "tout" wiki. Pendant la période de préavis, demandez au développeur sortant de vous aider à documenter tout ce qui se trouve dans le wiki de l'équipe et de l'entreprise et vérifiez si vous pouvez faire des revues de code avec lui et ajouter des commentaires au code. Il est préférable pour le développeur "preneur" d'écrire les commentaires dans le code sous la supervision du leaver.

Answer 3

Nous avons en fait un ensemble spécifié de "Deliverables" qui doit être présent pour nous permettre de prendre en charge un projet.

Si nous avons la chance, nous essayons de pousser l'une de nos personnes au sein du groupe à développer le projet au début. De cette façon, nous obtenons un knowledgde de première main avant que notre groupe prenne le code. (Dans la ligne de ce que @Guy a écrit)

Cela étant dit, la partie la plus importante pour moi serait:

• Une sorte og aperçu de haute activité (dessin?) De ce que le code ne.
• Accès facile à poser des questions aux gens qui ont écrit en fait le code

Ce pour moi alpha oméga lors de la prise sur le code et les projets

Answer 4

Une fois, j'ai rejoint une équipe qui s'est vue confier un tas de conneries fumantes provenant de l'externalisation. Le projet original - un gestionnaire de contenu multimédia basé sur Java, Struts, Hibernate | Oracle - était bien structuré (il semble que ce soit le travail de deux personnes, la programmation en binôme, l'utilisation judicieuse des motifs, quelques tests unitaires). Puis quelqu'un a hérité d'autre projet et fonctionnalités empâtées-copie sans fin, desserra les règles métier, patché, ramifié jusqu'à ce qu'il devienne un énorme monstre de spaghetti avec beau morceau Recouverte de codes comme:

List<Stuff> stuff = null; 
if (LOG.isDebugEnabled()) 
{ 
    stuff = findStuff(); 
    LOG.debug("Yeah, I'm a smart guy!"); 
    for (Stuff stu : stuff) 
    { 
     LOG.debug("I've got this stuff: " + stu); 
    } 
} 
methodThatUsesStuff(stuff); 

caché parmi l'autre ingéniosité brillante.J'ai apprivoisé la bête par la refactorisation des patients (extraction des méthodes et des classes plus de fois), en commentant le code de temps en temps, en réorganisant tout jusqu'à réduire la base de code de 30%, devenant de plus en plus gérable.

Answer 5

J'ai dû reprendre à plusieurs reprises le code de quelqu'un d'autres degrés de qualité. D'où les conseils:

• Faire l'effort de prendre des notes structurées de toute information importante de minutes un: noms des acteurs, des règles commerciales, le code et les lieux de documents, etc. Il est préférable de dédier un cahier à spirale frais, donc vous pourriez arracher des pages si vous deviez. Utilisez l'un des meilleurs outils d'indexation gratuite et de recherche sur le bureau disponibles sur le marché (Google Desktop Search, MS Windows Search fera l'affaire). Ajoutez tous les documents, e-mails, emplacements de code. Avant de développer quoi que ce soit, faites de l'analyse de documents: trouvez tout ce que vous pouvez mettre en pratique électroniquement sur des documents réseau et imprimés, faites des efforts pour simplement les lire. Il y a étonnamment beaucoup d'informations utiles, même dans des projets inachevés.

• Mappez le code, l'architecture, etc., au fur et à mesure. Avec des systèmes moins documentés et maintenus, vous aurez inévitablement des moments de désespoir susceptibles de vous pousser en mode de procrastination. Surtout au cours de vos premiers jours ou semaine où la quantité de nouvelles informations que votre esprit doit digérer est accablante. Dans ces moments-là, il est bon d'avoir quelqu'un pour vous rappeler (ou simplement le faire vous-même) de vous calmer, de vous concentrer sur des choses importantes et de faire des pas plus petits pour essayer de comprendre plutôt que d'essayer de progresser. Continuez à prendre des notes, à créer des diagrammes, à dessiner des images riches et à réaliser une cartographie de l'esprit. Cela aide vraiment à digérer les quantités abondantes de nouvelles informations, pour la plupart désorganisées.

Hei, bonne chance!