C'est une chose à laquelle je pense depuis que j'ai lu cette réponse dans le fil d'opinions de programmation controversé :
Votre travail consiste à vous mettre au chômage.
Lorsque vous écrivez un logiciel pour votre employeur, tout logiciel que vous créez doit être écrit de telle manière qu'il puisse être récupéré par n'importe quel développeur et compris avec un minimum d'effort. Il est bien conçu, rédigé de manière claire et cohérente, formaté proprement, documenté là où il doit être, construit quotidiennement comme prévu, archivé dans le référentiel et correctement versionné.
Si vous êtes frappé par un bus , mis à pied, licencié ou quittez le travail, votre employeur devrait être en mesure de vous remplacer à tout moment, et le gars suivant pourrait entrer dans votre rôle, prendre votre code et être debout et en cours d'exécution dans les hauts d'une semaine. S'il ne peut pas faire cela, alors vous avez lamentablement échoué.
Fait intéressant, j'ai constaté que cet objectif m'a rendu plus précieux pour mes employeurs. Plus je m'efforce d'être jetable, plus je deviens précieux pour eux.
Et cela a été discuté un peu dans d'autres questions, comme celle-ci , mais je voulais le reprendre pour discuter d'un point de vue plus "blanc c'est une odeur de code !! " - qui n'a pas vraiment été couvert en profondeur encore.
Je suis développeur professionnel depuis dix ans. J'ai eu un travail où le code était suffisamment bien écrit pour être repris assez rapidement par tout nouveau développeur décent, mais dans la plupart des cas dans l'industrie, il semble qu'un niveau de propriété très élevé (à la fois individuel et collectif) soit le norme. La plupart des bases de code semblent manquer de documentation, de processus et d '"ouverture" qui permettraient à un nouveau développeur de les récupérer et de travailler rapidement avec eux. Il semble toujours y avoir beaucoup de petits trucs et hacks non écrits que seul quelqu'un qui connaît très bien la base de code ("le possède") le saurait.
Bien sûr, le problème évident avec ceci est: que faire si la personne quitte ou "se fait heurter par un bus"? Ou au niveau de l'équipe: que se passe-t-il si toute l'équipe est intoxiquée par des aliments lorsqu'elle sort pour le déjeuner de son équipe et qu'ils meurent tous? Seriez-vous capable de remplacer l'équipe par un nouvel ensemble de nouveaux développeurs aléatoires relativement sans douleur? - Dans plusieurs de mes emplois passés, je ne peux pas imaginer que cela se produise du tout. Les systèmes étaient tellement remplis d'astuces et de hacks que vous "devez simplement savoir ", que toute nouvelle équipe que vous embaucher mettrait beaucoup plus de temps que le cycle économique rentable (par exemple, les nouvelles versions stables) pour que les choses recommencent. Bref, je ne serais pas surpris si le produit devait être abandonné.
Évidemment, perdre une équipe entière à la fois serait très rare. Mais je pense qu'il y a quelque chose de plus subtil et sinistre dans tout cela - c'est le point qui m'a fait penser à commencer ce fil, car je ne l'ai pas vu discuté dans ces termes auparavant. Fondamentalement: je pense qu'un besoin élevé de propriété de code est très souvent un indicateur de la dette technique . S'il y a un manque de processus, de communication, de bonne conception, beaucoup de petites astuces et hacks dans le système que vous "devez juste savoir", etc. - cela signifie généralement que le système s'endette progressivement de plus en plus profondément.
Mais le fait est que la propriété du code est souvent présentée comme une sorte de «loyauté» envers un projet et une entreprise, comme une forme positive de «prise de responsabilité» pour votre travail - il est donc impopulaire de le condamner carrément. Mais en même temps, le côté dette technique de l'équation signifie souvent que la base de code devient progressivement moins ouverte et plus difficile à utiliser. Et d'autant plus que les gens évoluent et que les nouveaux développeurs doivent prendre leur place, le coût de la dette technique (c'est-à-dire la maintenance) commence à monter en flèche.
Donc, dans un sens, je pense en fait que ce serait une bonne chose pour notre profession si un niveau élevé de besoin de propriété de code était ouvertement perçu comme une odeur de travail (dans l'imagination du programmeur populaire). Au lieu d'être perçu comme «prenant la responsabilité et la fierté» du travail, il devrait plutôt être considéré comme «se retrancher et créer une sécurité d'emploi artificielle via la dette technique».
Et je pense que le test (expérience de pensée) devrait être fondamentalement: et si la personne (ou en fait, toute l'équipe) devait disparaître de la surface de la Terre demain. Serait-ce une blessure gigantesque, voire mortelle, au projet, ou pourrions-nous faire venir de nouvelles personnes, leur faire lire les doccos et les fichiers d'aide et jouer avec le code pendant quelques jours - puis revenir affaires en quelques semaines (et retour à la pleine productivité dans un mois environ)?