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)?
Réponses:
Je pense que nous devons faire la différence entre la propriété du code:
Le premier doit être encouragé. Si personne n'est responsable de code et de bogues de mauvaise qualité, de mauvaises choses se produiront . Cela ne signifie pas que le bug lié à votre propre code doit vous être attribué à chaque fois: si le code est correctement écrit, n'importe qui peut corriger le bug dans n'importe quelle partie du code. Mais si vous n'avez pas de commentaires sur les bugs que vous faites, vous produirez les mêmes bugs encore et encore .
La propriété du code peut aider beaucoup les gestionnaires et les développeurs, en particulier les développeurs. Si je sais que 80% des bogues du produit étaient dans mon code alors que nous étions trois développeurs travaillant sur le projet, et que 75% de ces bogues étaient liés à l'injection SQL, je serais plus prudent lors de l'écriture de code la prochaine fois, et faire un effort supplémentaire pour écrire correctement les requêtes de base de données.
Le second (propriété du code du style de code / hacks, etc.) est surtout une mauvaise chose. Qu'est-ce que cela apporte au produit? Il n'augmente pas la qualité du produit, mais diminue l'uniformité du code source et rend difficile sa maintenance ces derniers temps .
Pour de nombreux grands projets, les gens ne restent pas à vie à travailler sur le même morceau de code. Et ici, je ne parle même pas de choses horribles comme le développeur heurté par un bus: je ne pense pas que la propriété du code soit la première préoccupation dans ce cas. Mais beaucoup de réflexions mineures se produisent: les gens migrent du développement vers la gestion ou d'autres emplois, ou choisissent d'autres projets, ou travaillent sur d'autres choses, ou commencent à utiliser une autre langue (si plusieurs langues sont utilisées dans un projet), etc.
Un morceau de code d'un projet peut également être réutilisé dans un autre projet, et le développeur travaillant sur cet autre projet souhaite modifier certaines parties du code pour répondre aux nouveaux besoins, sans demander conseil à l'ancien rédacteur du code.
Est-ce une odeur de code? Eh bien, cela dépend de ce que vous entendez par odeur de code. Pour moi, c'est une question de cohérence globale du projet et de bonne gestion . Dans un bon projet,
Pour conclure, la propriété du code doit être suivie via le contrôle de version, mais vous ne devez pas pouvoir dire qu'un morceau de code est écrit par vous ou quelqu'un d'autre dans une équipe .
la source
Nous devons d'abord définir ce qu'est la «propriété du code».
Lorsqu'un morceau (une partie) de code est en cours d'élaboration, il est souvent nécessaire de désigner une ou deux personnes comme "propriétaires" parce que:
Il y a normalement un seul propriétaire pour chaque tâche. La double programmation est possible avec la programmation par paires. Il ne serait pas pratique de le faire sans une "propriété du code" étroitement désignée.
Remarque:
Veuillez consulter la réponse de @ MainMa pour les autres problèmes pendant le développement. Dans ces cas, la «propriété du code» est un symptôme de problèmes plus importants, à savoir: choix sous-optimal de l'architecture, incohérence du style de codage et généralement manque de qualité du code.
Une fois qu'une pièce est écrite et acceptée dans la base de code («terminé»), la question plus générale «propriété du code» apparaît.
Il y aura toujours une partie de la connaissance du domaine (compréhension tacite des exigences des clients, problèmes de compatibilité avec les systèmes obscurs, etc.) qui est difficile à formaliser en spécifications écrites. Par conséquent, quand il y a un événement de calamité, une certaine perte de connaissance du domaine doit être attendue.
Parallèlement à la perte de connaissances du domaine, vous perdrez également les répondeurs experts qui peuvent expliquer les détails du système. Dans cet aspect, la perte de l'expert est une chose universellement mauvaise. Les connaissances auraient dû être saisies plus tôt.
Cela ne signifie pas que l'existence d '«experts» est mauvaise: considérez les experts comme une «cache» des connaissances écrites. Les experts peuvent souvent répondre aux questions plus rapidement que d'avoir à rechercher et à digérer les connaissances écrites.
Cependant, parfois, la «propriété du code» fait référence aux barrières mises en place par les développeurs actifs d'un projet pour empêcher les étrangers de modifier le code.
Il y a de bonnes barrières et de mauvaises barrières:
Dans ce cas, le privilège de modifier le code source d'un autre projet ne doit pas être basé sur la propriété du code, mais il doit être basé sur le mérite.
Enfin, la réponse de @Graham Lee souligne la fragmentation des connaissances et de l'architecture provoquée par la départementalisation.
Dans ce cas, la «propriété du code» est l'un des symptômes de la départementalisation. Un deuxième symptôme est le "manque d'intérêt pour les projets des autres équipes". En tant qu'organisation, les gestionnaires devront prendre des mesures pour encourager le transfert de connaissances et la collaboration entre les équipes et les départements.
la source
Plus insidieusement, certaines entreprises (j'y ai travaillé) organisent leur structure de gestion autour d'équipes fonctionnelles: vous gérez les développeurs clients Windows, elle gère l'équipe installateur, il gère les développeurs backend et ainsi de suite. Non seulement cela conduit à la forte propriété du code que vous décrivez, mais elle le consacre comme le fonctionnement de l'entreprise. Il transforme l'architecture logicielle en un bunfight politique.
Est-ce un problème? C'est si l'architecture est ou devient sous-optimale. Il est impossible de dire (par exemple) que l'installateur fonctionnerait mieux ou serait moins cher à développer s'il ne s'agissait que d'un cas d'utilisation du client, car cela prend le contrôle d'une équipe et de son manager. Les divisions entre les modules fonctionnels sont devenues des faits sur la façon dont le département d'ingénierie est géré, et il faut beaucoup de bouleversements pour modifier ces faits.
[BTW au cas où la discussion ci-dessus ne le rendrait pas clair, ma réponse à votre question est oui. La propriété du code est une odeur de code, car elle peut empêcher des personnes intelligentes ayant de bonnes idées - ou même simplement des personnes disponibles lorsque vous en avez besoin - de travailler sur le code. De toute évidence, avoir des contrôles pour arrêter les changements capricieux est une bonne chose, mais si vous avez un ingénieur qui peut voir comment corriger un bogue et a le temps de le faire, vous ne devriez pas bloquer cet ingénieur simplement parce que quelqu'un d'autre a écrit le code du bogue. ]
la source
Abordant votre question d'un point de vue légèrement différent, la propriété du code n'est PAS une odeur de code. C'est plutôt une odeur de gestion et de ressourcement .
Pensez à ce que signifie une odeur de code. C'est une métaphore qui vous dit quand vous regardez votre code, que quelque chose ne va pas avec le code et / ou la conception du logiciel, mais le problème n'est peut-être pas si évident qu'il est possible de mettre le doigt sur ce le problème exact peut être, mais vous avez probablement une bonne idée malgré tout. Dans votre maison, si quelque chose sent mauvais, vous suivez votre nez jusqu'à ce que vous localisiez la source du problème, puis vous faites quelque chose. De la même manière, si le code a un problème, vous étudiez et le modifiez jusqu'à ce qu'il devienne moins problématique, ou comme certains pourraient le dire, beau ou bien conçu .
La propriété du code, d'autre part, peut être un problème grave. Cela suggère un manque de surveillance et un risque que si le propriétaire du code s'en va, ces informations sur le code et les problèmes spécifiques qu'il résout ne seront plus disponibles pour l'entreprise. Cela n'a rien à voir avec le code lui-même. Cela revient essentiellement à une situation de gestion des risques de la même manière qui nous amène à conserver des sauvegardes de nos données, et s'applique tout aussi bien à la propriété des tâches ou à la propriété des documents dans d'autres domaines de l'entreprise.
Je pense que c'est bien de décrire d'autres problèmes commerciaux comme des odeurs , mais certainement pas de laisser entendre que simplement parce qu'il y a une odeur , cela a spécifiquement à voir avec le code.
la source
Je définis la propriété du code comme la responsabilité personnelle du code que vous écrivez, étant entendu que d' autres travailleront dans votre code à l'avenir . Si vous pensez aux choses de cette façon, vous serez moins susceptible d'écrire un hack car a) les bogues de ce module pourraient être retracés, et b) les membres de l'équipe auraient probablement du mal à modifier le code à l'avenir .
J'ai écrit un article sur ce sujet il y a plusieurs mois, où j'ai soutenu que sans propriété du code, tel que je le définis, une base de code est souvent la proie de la tragédie des communes .
Par votre définition de la propriété du code, je conviens qu'il est mauvais d'avoir du code dans lequel seul l'auteur peut travailler.
la source