Comment normalisez-vous le style de codage parmi plusieurs développeurs isolés?
Nous sommes une petite/moyenne entreprise avec une douzaine de développeurs de logiciels, développant notre propre logiciel interne pour une utilisation interne. Étant donné que nous sommes si peu nombreux et qu'il y a tellement de travail à faire, la plupart du temps, chaque développeur gère une partie distincte du système et ne partage pas beaucoup son travail avec d'autres développeurs. Chacun a son "domaine" pour ainsi dire.
Parfois, cependant, les domaines se chevauchent et nous devons collaborer; et aussi l'arrangement signifie qu'il est difficile de remplacer les gens et quand quelque chose ne va pas, nous devons être là pour réparer les choses parce que personne d'autre ne peut le faire (du moins pas rapidement). Cet arrangement est donc à la fois Nice (nous avons chacun un contrôle créatif total) et pas Nice (nous sommes fondamentalement obligés d'être sur appel 24/7, bien qu'en pratique c'est un peu plus détendu que ça).
Récemment, nous avons essayé un petit "atelier" entre nous pour promouvoir de meilleures normes de codage, à savoir les tests unitaires. (Ouaip, nous sommes une des personnes qui ne le font pas encore ...) Au cours de la réunion de 2 heures, nous visions à créer un petit exemple de programme avec des tests unitaires, juste pour avoir une idée de le faire.
Cela a été un plaisir de 2 heures, et nous avons finalement réussi à produire un peu de code, mais un problème intéressant est devenu douloureusement évident: après avoir vécu tant d'isolement pendant si longtemps, chacun de nous a fondamentalement son propre style de codage.
Maintenant, je ne parle pas d'onglets vs d'espaces, d'un étui à chameau vs d'un étui à serpent ou d'une autre différence cosmétique. Je parle des principes d'organisation du code. Comment nommer les choses. Dans quels dossiers et espaces de noms les placer. Dois-je diviser ce code en 3 classes ou une seule? 5 petits fichiers ou 1 gigantesque? L'abstraire avec des interfaces et des usines, ou l'appeler directement? Getters et setters ou champs nus? Etc.
Parfois, l'écriture du programme absolument trivial a failli se transformer en un match de cris, même si nous avons heureusement pu garder notre sang-froid à la fin et aucun sentiment n'a été blessé.
Cela m'a donc amené à me demander - comment normalisez-vous le style de codage parmi plusieurs développeurs chevronnés avec chacun leurs propres préférences? Les différents styles sont certainement sont gênants lorsque nous faisons devons interagir avec les codes des autres, sans parler de la confusion pour les nouveaux arrivants. Et quand un morceau de code est transmis du domaine d'une personne à un autre, il y a toujours le fort désir de le réécrire pour l'adapter à vos propres moyens.
Tout d'abord, existe-t-il des règles sur la façon de disposer votre code? Des normes? Jusqu'à présent, je n'ai vu que des trucs cosmétiques sur les espaces et les cas. Fondamentalement, comment formater votre code une fois qu'il est écrit (dans votre tête au moins). Mais existe-t-il des guides sur la façon de écrire votre code, comment l'organiser et comment le nommer? Où et comment le diviser en morceaux et comment faire interagir les morceaux?
S'il n'y a pas de norme et que nous devons créer la nôtre, comment procédez-vous lorsque tout le monde a une forte opinion de ce qui est bien et de ce qui ne va pas? Maintenant, attention, nous sommes tous des développeurs chevronnés ici; nous nous rendons compte qu'aucune de nos approches n'est intrinsèquement meilleure ou pire qu'une autre - juste que chacune d'elles a certaines forces et certaines faiblesses. Mais nous avons également une opinion bien arrêtée sur les points forts et les points faibles les plus importants. Alors, comment décidez-vous de The Right Way ™ et comment vous assurez-vous que tout le monde y adhère sans trop blesser les sentiments?
Une façon dont j'ai entendu parler est de sélectionner un Glorious Leader qui impose ensuite son style préféré aux autres (via les revues de code et les réunions et autres), mais ... vous avez besoin d'un très bon Glorious Leader qui est en effet la tête et les épaules au-dessus des autres . Et si vous n'en avez pas, et nous sommes vraiment tous égaux ici?
- Avoir une norme de codage. Si la boutique pour laquelle vous allez travailler en a déjà une en usage, c'est celle que vous suivez. Évitez les normes de codage qui font des dizaines de pages; ce n'est pas si compliqué. Au lieu de cela, regardez le code que vous aimez sur Github et suivez ce style. Trouvez les idiomes bien établis pour votre langage de programmation particulier (camelCase, etc.) et utilisez-les.
- Laissez le IDE et les outils de style de code faire la plupart du travail pour vous. Par exemple, Visual Studio a déjà la plupart des règles importantes en place. Je n'aime pas comment un morceau de code est formaté? Demandez à Visual Studio de le reformater pour vous. Problème résolu.
- Embauchez des développeurs de logiciels qui savent ce qu'ils font. Ils écriront du bon code sans avoir à suivre servilement un guide de style.
- Faire réviser le code. Rechercher un consensus basé sur la fonction et la lisibilité. Vous n'aimez pas le consensus? Une personne est le bris d'égalité; leur décision est maintenue.
- Ne cherchez pas la perfection; vous ne l'obtiendrez jamais (pour de nombreuses raisons qui sortent du cadre de cette question). Efforcez-vous plutôt de vous améliorer.
- Essayez de ne pas perdre beaucoup de temps et d'argent sur des choses qui ne comptent pas. En particulier, ne réécrivez pas du code qui fonctionne déjà et qui est déjà bien testé, juste pour satisfaire vos propres sensibilités à quoi ce code devrait ressembler.
- Apprenez à écrire des fonctions et des méthodes qui font une chose et le font bien. Si vous faites cela, votre dénomination devrait prendre soin d'elle-même (le nom est une courte phrase verbale qui décrit ce que fait la fonction) .
- Si vous faites de l'OO, apprenez à écrire de petites classes qui ont une responsabilité/point de modification. Si vous faites cela, votre nom devrait prendre soin de lui-même (le nom est une courte phrase nominale qui décrit ce qu'est la classe).
- Apprenez à écrire du code facilement testable. Si vous faites cela, les tests unitaires prendront soin d'eux-mêmes.
- Choisissez vos batailles. Est-ce que cette petite propension obscure que l'un des développeurs présente vraiment? Évitez les religions et les dogmes.
- Enfin, rappelez-vous que le code n'est pas le vôtre. Ne soyez pas sentimental à ce sujet. Vous devez le "posséder" et apporter les modifications nécessaires (donc, dans ce sens, il vous appartient), mais il est là pour servir un objectif. Être trop attaché au code ne fait obstacle à cela qu'en empêchant une analyse objective des avantages et des inconvénients des changements ou des décisions à grande échelle sur la structure du code et en vous opposant aux compromis.
La première étape (et il semble que vous soyez déjà sur la bonne voie) consiste à obtenir l'accord de tous les développeurs qu'il y a un problème et qu'il doit être corrigé. Ils doivent tous comprendre qu'ils peuvent avoir besoin de changer certaines de leurs habitudes pour le plus grand bien. Il est presque certain que tout le monde devra changer au moins une chose au sujet de la façon dont il écrit du code, mais j'espère qu'il pourra également continuer à faire certaines choses comme il l'a toujours fait. Tout le monde doit y souscrire.
Deuxièmement, vous devez identifier exactement les différences et les noter dans une liste. Comme vous le faites remarquer à juste titre, certains de ces éléments sont triviaux et esthétiques, et certains sont beaucoup plus logiques. Mais il doit être capturé par des mots afin que vous puissiez l'apprivoiser.
Troisièmement, vous devez trouver les fruits bas, peut-être en utilisant une sorte de système de vote parmi les développeurs. Certaines de vos différences vont être difficiles à résoudre, car tous les développeurs ont une forte préférence et c'est une répartition uniforme. Cependant, certains seront plus d'une répartition 75/25, ou ils seront également divisés, mais un côté en ressent beaucoup plus que l'autre. Ces problèmes sont plus faciles à résoudre. Identifiez-les et prenez-les un par un. Faites savoir aux développeurs le résultat du sondage et assurez-vous que tout le nouveau code à suivre sera conforme à l'approche préférée du groupe.
Enfin, vous avez besoin d'un moyen de faire appliquer la décision, et la solution à cela est tout simplement la révision du code. TOUTES les modifications doivent être examinées par au moins un autre développeur. C'est un bon protocole même si vous n'essayez pas de normaliser le style de codage. Les examinateurs doivent rechercher les bogues potentiels, le code peu clair, les commentaires trompeurs et, bien sûr, la conformité aux directives de style de codage.
Une fois qu'un changement est effectué, passez au suivant. À mesure que les développeurs s'habitueront à ce processus, ils deviendront plus ouverts d'esprit à mesure que vous aborderez les questions les plus litigieuses.
Votre objectif déclaré pour la réunion était de discuter des tests unitaires pour améliorer la qualité du code parmi un groupe de développeurs expérimentés. Vous vous êtes alors retrouvé à discuter:
Comment nommer les choses. Dans quels dossiers et espaces de noms les placer. Dois-je diviser ce code en 3 classes ou une seule? 5 petits fichiers ou 1 gigantesque? L'abstraire avec des interfaces et des usines, ou l'appeler directement? Getters et setters ou champs nus?
Aucun des sujets ci-dessus n'est critique pour les tests unitaires, ils sont purement de style de codage, et je m'attends à ce que tout développeur chevronné soit capable de sauter dans une base de code avec l'une des options susmentionnées et d'écrire du code stylistiquement compatible sans hésitation.
À cet effet, je prendrais un peu de recul, me rendrais compte que vous vous êtes engagé dans un débat sur rien de vraiment important et vous remettez sur la bonne voie avec le sujet des tests (pas seulement limité aux tests unitaires).
Soulignez l'importance des tests parmi les développeurs et donnez-leur du temps/de l'espace pour écrire ces tests de la manière qui correspond le mieux à leur style individuel. Tant qu'ils documentent clairement où/comment trouver/exécuter les tests pour leur code, alors tout va bien.
N'ont pas de norme de codage autre que celle habituelle pour la plate-forme. Et supposez que vos développeurs sont tous des adultes.
Deux règles: si vous éditez un fichier, vous vous adaptez à son style de codage. Et le nouveau code est écrit dans le style du développeur qui l'écrit.
Et soyez tolérant. Pas besoin de crier. Qui crie est faux.
Je pense que vous essayez de résoudre le mauvais problème. Si je comprends bien, votre problème est que chaque développeur travaille dans son silo et que les autres développeurs n'interviennent que si les problèmes sont graves. Bien sûr, avoir un style commun (codage profond) peut aider dans ce cas, mais je pense que la meilleure option est de briser les silos en premier. Tant que vous travaillez isolément, tout le monde continuera à coder selon ses normes. Cela n'a pas besoin d'être une intention malveillante (parce que vous n'êtes pas d'accord avec la norme), il peut simplement s'agir d'interprétations différentes. Nous avons nos normes de codage depuis des années avec la même équipe de base depuis des années, mais nous rencontrons toujours parfois le problème qu'un examen du code révèle des interprétations différentes de la norme de codage pour différentes personnes. Ce qui n'est d'ailleurs pas une mauvaise chose car seules les discussions et les désaccords permettent à une norme de codage d'évoluer.
Donc, ma recommandation est d'essayer de briser les silos en premier. Il y a peut-être un nouveau projet à venir où 2-3 développeurs peuvent créer cela ensemble. Vous pouvez peut-être associer plusieurs développeurs sur un groupe de projets similaires. Laissez ces mini-équipes développer leurs normes de codage dans la pratique et vérifier l'interprétation de la norme abstraite en pratiquant des révisions de code.
Passer de la propriété individuelle au collectif (et une norme commune en est un élément) ne se fait pas du jour au lendemain et ne peut pas être décidé en réunion. C'est un objectif que vous visez et atteignez par des améliorations quotidiennes progressives.
Puisqu'il ne s'agit pas seulement du style superficiel, mais de la façon dont les gens écrivent, je soupçonne fortement que si vous forcez une façon de se tordre et de penser à tout le monde, sous la forme d'une "norme", vous va étouffer la créativité des membres de votre équipe, et cela pourrait tuer votre équipe/entreprise. Ce que vous devez faire, c'est travailler à transformer ces allumettes en quelque chose de plus productif; et apprenez à garder vos opinions fortes plus librement.
N'introduisez pas un grand changement, vous rencontrerez une résistance; au lieu de cela, fixez-vous un objectif ("nous voulons un niveau de compétence de conception plus unifié au sein de l'équipe" par opposition à "nous voulons un style de codage spécifique"), et déterminez ce qu'est une petite étape pour aller dans cette direction. Ensuite, lorsque vous sentez que vous y êtes arrivé, déterminez la prochaine étape. Je pense que vous pouvez tous convenir que les endroits où le code d'une personne doit interagir avec le code d'une autre personne ne devraient pas être la responsabilité d'une seule personne, et que le code à ces interfaces exige que les parties impliquées soient plus attentives à la conception et passer du temps à mieux comprendre le problème de l'interaction. Alors commencez par là; introduire l'idée que le code aux limites n'est pas décidé par, ou même détenu par une seule personne. Demandez-leur d'examiner et de convenir explicitement des dépendances et des relations de "puissance" entre les systèmes/composants.
Une autre chose que vous pouvez faire est de les faire commencer à incorporer une certaine forme de programmation par paires dans leur routine (pendant une fraction des heures de travail, éventuellement avec un schéma de rotation), d'une manière qui ne perturbe pas trop (vous devrez comprendre ce que cela signifie par rapport à la façon dont vous travaillez actuellement). De cette façon, ils peuvent acquérir des compétences les uns des autres et "s'affronter" entre eux lorsqu'il s'agit de concevoir le code; car contrairement à une discussion animée lors d'une réunion, ils résoudront de vrais problèmes et pourront ainsi contester les idées des autres, les évaluer et les tester dans leur contexte. Cela aiderait également votre problème où personne ne comprend vraiment le code de quelqu'un d'autre que le leur.
P.S. Puisque vous débutez avec TDD, je ne forcerais pas cela non plus sur l'équipe. Au lieu de cela, je trouverais un moyen pour eux de le pratiquer sur un projet parallèle, puis de l'incorporer lentement dans leur travail quotidien, car, à l'OMI, le TDD nécessite une certaine quantité de pratique et un certain niveau de (rédaction de test et conception ) compétence avant de pouvoir être utilisée efficacement. Sinon, ils pourraient finir par écrire une suite de tests qui ne leur facilite pas la vie, ils finiront donc par l'ignorer et/ou développer une hostilité envers la pratique. Vous pouvez également envisager de faire appel à un bon consultant, d'organiser plus d'ateliers, etc.
Si la culture d'équipe fonctionne bien avec chaque développeur ayant son propre domaine et ses propres styles, et que les gens sont satisfaits de la situation, alors n'essayez pas de changer cela. Si cet isolement n'est pas un problème, n'en faites pas un problème.
Faites en sorte que le respect des normes locales soit la règle générale. Le chef de file de chaque domaine doit décider quelles sont les normes pour son domaine et si les gens travaillent en dehors de leur domaine, ils doivent respecter le style de codage du chef de domaine local.
Cela ne veut pas dire que vous ne devriez pas avoir de norme de codage. Certaines normes de codage vont être assez simples et avoir des accords généralisés, alors normalisez-les. Mais pour les plus controversés, n'essayez pas d'unifier les opinions de chacun.
Étant donné que nous sommes si peu nombreux et qu'il y a tellement de travail à faire, la plupart du temps, chaque développeur gère une partie distincte du système et ne partage pas beaucoup son travail avec d'autres développeurs. Chacun a son "domaine" pour ainsi dire.
C'est plus un problème qu'il n'y paraît. Le fait de n'avoir qu'un seul développeur sur un projet encourage ce type de surprotection et présente d'autres risques de "facteur bus" - si la seule personne qui connaît un sous-système est heurtée par un bus ou autrement soudainement inapte ou part.
Afin de se comporter en équipe, ils doivent travailler en équipe, ce qui signifie une répartition plus égale du travail. Ce n'est pas du tout facile et nécessite une contribution de gestion continue, mais cela en vaut la peine à long terme.
Tout en faisant cela et en examinant le travail de chacun, ils finiront par discuter des détails - mais par paires, plutôt que dans un grand groupe. Cela devrait encourager l'émergence d'un consensus. Sauf s'il y a une personne "la plus déraisonnable" qui essaie d'imposer sa volonté.
Ce n'est pas clair pourquoi le style de codage est important pour vous. Est-ce parce que cela a provoqué un désaccord, ce qui a fait perdre du temps et créé des frictions, ou est-ce parce que cela cause des problèmes dans le fonctionnement du logiciel, ou est-ce parce que cela rend difficile l'écriture/la maintenance du logiciel?
Donc, la première chose à faire est de trouver le pourquoi ou le quoi et le comment vous échappera probablement (bien que toutes les autres réponses ici ont de bonnes idées sur les choses que vous devriez faire).
Ce que je ferais probablement dans cette situation est:
- écrire dans interfaces
- écrire des tests d'intégration qui confirment le fonctionnement du logiciel lors de l'utilisation de ces interfaces
- documenter mon travail à fond
- faites tout cela pour mon travail uniquement
Jusqu'à ce que vous obteniez le pouvoir par consensus ou le pouvoir par l'autorité comme celle d'un gestionnaire, la seule façon de faire les choses est par l'exemple. Quiconque touche à votre travail devra désormais utiliser les spécifications que vous avez fournies, ce qui entraînera moins d'erreurs dans votre travail, prouvant ainsi son propre point. Vous gagnez l'autorité de cette façon (la meilleure façon).
En fin de compte, si les interfaces génèrent les bonnes choses quand on leur donne les entrées attendues, pourquoi vous souciez-vous si le code a 3 classes ou 5? Parce que vous ne pouvez pas lire leurs trucs ou que vous ne les aimez pas? Vous avez besoin de meilleures raisons pour essayer d'appliquer un style que ce que vous avez.
Enfin, si vous n'avez pas de spécifications/tests, peu importe si vous avez donné à un singe une machine à écrire pour coder et que vous n'aimez pas son style, vous avez de plus gros problèmes.
réponse de Robert est super, mais il y a un peu plus à dire sur l'impact de vos conceptions techniques sur le travail d'équipe.
tests unitaires. (Ouaip, nous sommes l'une des personnes qui ne le font pas encore ...)
Les tests unitaires ne sont pas ... nécessaires, si vous n'utilisez pas OO. Si vous utilisez OO, testez aide pour vous avertir lorsque votre code casse. Mais les tests sont soumis aux mêmes règles que tout autre code, et ils peuvent se briser de manière inattendue de la même manière que le code ordinaire.
Si vous utilisez un style plus fonctionnel au lieu de OO, les tests unitaires cessent simplement d'exister. S'ils existaient, ils ressembleraient exactement à copier-coller votre code, auquel cas vous ne le faites tout simplement pas, vous pouvez donc garder votre code petit et lisible. Voir ci-dessous pour un exemple.
Dois-je diviser ce code en 3 classes ou une seule? 5 petits fichiers ou 1 gigantesque? L'abstraire avec des interfaces et des usines, ou l'appeler directement? Getters et setters ou champs nus?
Vous pourriez vous retrouver dans des arguments à ce sujet, mais vous devez trouver une bonne réponse. Les interfaces, l'abstraction, les usines, les classes, les getters et les setters sont tous des concepts arbitraires qui sonnent bien, mais devoir comprendre comment ils fonctionnent et comment ils s'intègrent dans votre logiciel, est une surcharge pour les développeurs. L'overhead donne envie aux développeurs de trouver de nouvelles solutions pour ne pas passer autant de temps à résoudre des puzzles. Comme ces concepts n'ont aucun avantage mesurable, vous pouvez les ignorer complètement pour rendre votre code plus facile à lire et à manipuler.
Sortir de ces arguments peut être délicat. Soyez à l'écoute, posez les bonnes questions, posez vos questions de façon courte, précise et précise, et percez les conceptions tôt. Si quelqu'un suggère d'utiliser un modèle d'usine, vous voudrez peut-être contrer avec un exemple qui utilise moins de lignes de code. S'ils disent quelque chose d'improuvable comme `` moins de code n'est pas toujours meilleur '' ou `` ce n'est pas conforme aux normes '', alors vous voudrez peut-être leur demander d'expliquer cela, afin qu'ils introspectent leur idée pour trouver l'erreur. S'ils échouent, ils seront confus et frustrés. Laissez le choix glisser, travaillez dessus et réessayez une autre fois. Ils s'amélioreront dans l'introspection à chaque fois que vous leur demanderez.
Si vous ne parvenez pas à faire introspecter le développeur à plusieurs reprises et qu'ils ne semblent pas s'améliorer, alors vous avez un problème de développeur. Si toute votre équipe est de la même manière, il est peu probable que vous puissiez améliorer la situation. Acceptez les arguments ou trouvez un travail différent.
Vous commenté sur la réponse de Robert
nous avons trop d'expérience et chacun a sa propre opinion basée sur cela
Sur la base de vos descriptions, je ne pense pas que vous ayez atteint trop d'expérience. Lorsque vous atteignez ce niveau, vous obtenez un consensus avec d'autres développeurs au même niveau, pas des opinions différentes. La réponse est vraie et ne présumez pas que vous êtes au-dessus - trouvez quelqu'un qui peut montrer qu'il sait ce qu'il fait et demandez-lui de vous guider dans la bonne direction.
Sur les tests unitaires pour les styles fonctionnels
Ce n'est pas très pertinent pour la question d'origine et est un peu long, alors sautez ceci sauf si vous êtes intéressé. On m'a demandé de l'expliquer, alors ..
Un serveur fonctionnel ressemblerait à ceci:
//main
http.Listen((request,response)=>{
response.write(request.username);
});
Et un test pourrait ressembler à:
//test that it returns the right value
var username="billy";
http.request({username:username}, response=>{
if(response!==username){
console.error("test failed");
return -1;
}
});
Mais une fois que mon serveur de base doit faire autre chose, je briserais le test. Le refactoring est nécessaire, mais maintenant je dois le faire en deux endroits.
Le test a également échoué de la même manière que le logiciel! Si le nom d'utilisateur n'est pas défini, nous essayons de lire une valeur indéfinie et lançons une erreur. Nous pouvons également rédiger un test pour cela, de façon vraiment rouge-verte:
//red: write the test first which will find undefined values
http.request({}, (response,error)=>{
if(response){
console.error("got a valid response, test failed");
return -1;
}
if(error){
return 0;
}
});
puis corrigez le code pour le vert:
//main
http.Listen((request,response, error)=>{
if(!request.username) error.write("no username");
else response.write(request.username);
});
Mais encore une fois, même problème. J'ai simplement écrit mon code deux fois, rendu la refacturation plus difficile, ajouté plus de lignes à lire et les tests n'ont rien fait d'utile.
Alors, quand le test est-il utile? Dans OO. Le test est un style fonctionnel en soi, où la fonction vise à maintenir le flux du programme stable, tout en guidant les développeurs à écrire du code plus petit et plus propre.
class server{
listen(IPerson request,string response){
response.write(request.username);
};
}
interface IPerson{
string username;
}
class Person{
string username;
}
class TestPerson inherits IPerson{
string username{
get{usernameCheckedCount++; return _username;}
set{_username=value;}
};
string _username;
int numTimesUsernameWasChecked=0;
}
static int TestServer(){
//setup
var didTestFail=0;
var srv=new server();
var invalidPerson=new TestPerson{username=null};
var validPerson=new TestPerson{username="billy"};
//test that an invalid person throws an error
srv.listen(invalidPerson,(string response, string error)=>{
if(error==null) didTestFail=1;
});
//test that a valid person throws no error, the server checks the username, and the response is the username
srv.listen(validPerson,(string response, string error)=>{
if(error != null) didTestFail= 1;
if(validPerson.numTimesUsernameWasChecked == 0) didTestFail=1;
if(response != "billy") didTestFail=1;
});
//return
return error;
}
Si je n'avais pas écrit cela en pensant aux tests, j'aurais très bien pu commencer par créer un service, 2 interfaces et un fichier d'injection de dépendance différent avant de commencer le travail lui-même, ce qui rendra certainement le travail beaucoup plus difficile. C'est vraiment difficile de garder une trace de tout!
En plus des suggestions ici, je vous recommande fortement d'utiliser le partage d'écran pour effectuer des sessions de programmation par paires afin que les développeurs puissent travailler ensemble. PAS toute la journée tous les jours, juste quelques heures par semaine à travailler en binôme et à mélanger les paires avec qui auront un énorme gain en termes de pratiques de normalisation et partager des conseils les uns avec les autres.
Pour autant que j'ai compris votre question, le simple fait que les gens ont des styles de codage et des préférences de conception différents n'est pas un problème. Un problème ne survient que lorsque
les domaines se chevauchent et nous devons collaborer
et ces styles et préférences entrent en collision les uns avec les autres. Votre plan consiste maintenant à résoudre ce problème en "normalisant" le style de codage.
Pour moi, la normalisation est un mot assez étrange dans ce contexte, car comment un style de codage serait-il plus normal qu'un autre? Comment les styles de codage actuels ne sont-ils pas normaux? Qu'est-ce qui définit un style de codage normal? C'est peut-être parce que je ne suis pas un locuteur natif anglais, mais votre choix de Word peut déjà être un indice que vous vous dirigez un peu dans une mauvaise direction ici.
Les gens développent généralement un style de codage qui les aide à écrire un meilleur code. Comme toutes les personnes sont différentes, parfois plus, parfois moins, leurs styles de codage seront également différents. Bien sûr, vous pouvez créer un style de codage commun et forcer tout le monde à l'utiliser, mais c'est un peu comme forcer tout le monde à utiliser la même main pour écrire, même si certains sont droitiers tandis que d'autres sont gauches. les préposés.
Un style de codage commun est généralement un compromis et ne conviendra à personne d'aussi bon que le sien. Certaines personnes auront moins de mal à le faire car le style est proche de leurs préférences, alors que ce sera un vrai problème pour d'autres. Ce que j'essaie essentiellement de dire ici: imposer un style de codage aux développeurs matures les fera produire un code pire en général, parfois juste un peu pire, parfois bien pire, cela dépend de votre choix de style. Et je ne sais pas si les améliorations dans les zones qui se chevauchent compenseront la perte dans toutes les autres zones.
Ce que j'ai lu dans votre question, c'est que le fait que tout le monde ait son propre style de code n'ait jamais été un problème sérieux jusqu'à présent en général, je ne sais pas si c'est intelligent d'en faire un problème grave en forçant un style de code commun pour tout le monde et tout le temps, tu vois ce que je veux dire?
En ce qui concerne la collaboration, immédiatement un bon vieux modèle de conception m'est venu à l'esprit:
programme aux interfaces, pas aux implémentations!
Pour la collaboration, il est nécessaire de se mettre d'accord sur des interfaces communes. Il n'est pas nécessaire de se mettre d'accord sur une implémentation commune derrière ces interfaces. Voici donc ma suggestion:
Laissez à chacun son style de codage préféré mais lors de la conception d'interfaces pour les sections où les domaines se chevauchent (ou peuvent se chevaucher à l'avenir), assurez-vous qu'aucune personne ne les concevra seule. Soit les concevoir dans une réunion d'équipe ou faire une règle comme au moins trois ou quatre personnes doivent travailler ensemble sur chaque interface. De cette façon, vous obtiendrez de bien meilleures interfaces et de meilleures interfaces mèneront automatiquement à un meilleur code. Ils répondent également à des questions telles que la façon de diviser vos problèmes en morceaux ou comment nommer les éléments et, plus important encore, comment les morceaux vont interagir les uns avec les autres.
Et gardez à l'esprit: Une bonne interface peut survivre très longtemps, car vous pouvez toujours remplacer l'implémentation derrière elle sans avoir à toucher à un autre code. C'est pourquoi les interfaces sont plus importantes que les implémentations, car elles remplacent les interfaces, ce qui est vraiment un travail difficile. Cependant, quelle que soit votre qualité, vous ferez des erreurs lors de la conception d'interfaces par vous-même. Vous oublierez les problèmes, vous oublierez les détails manquants et avoir quelques yeux supplémentaires à côté de vous sera vraiment utile.
Ma suggestion suit essentiellement une autre vieille sagesse de développeur:
Ne touchez jamais un système en cours d'exécution. Du moins, sauf si vous le devez. Imposer un style de codage à tout le monde reviendrait à reconcevoir votre système à partir de zéro, malgré le fait qu'il semble avoir très bien fonctionné jusqu'à présent, n'est-ce pas? Ne réparez pas la partie du système qui n'est pas cassée. Concentrez-vous uniquement sur le problème réel et ce sont les domaines où les domaines se chevauchent.