Premier laissez-moi dire, je ne suis pas un codeur mais je vous aide à gérer une équipe de codage. Personne de l'équipe n'a plus d'environ 5 ans d'expérience et la plupart d'entre eux n'ont travaillé que pour cette société. Nous volons donc un peu aveugle, d'où la question.
Nous essayons de rendre notre logiciel plus stable et envisageons de mettre en œuvre certaines "meilleures pratiques" et des normes de codage. Récemment, nous avons commencé à prendre cela très au sérieux, car nous avons déterminé qu'une grande partie de l'instabilité de notre produit pourrait être liée au fait que nous avons autorisé les avertissements à passer sans fixation lors de la compilation. Nous n'avons pas non plus la peine de prendre des fuites de mémoire assez gravement.
En lisant sur ce site, nous répartissons rapidement ce problème avec notre équipe, mais cela pose la question, quelles autres pratiques pouvons-nous mettre en œuvre une équipe large qui nous aidera?
Edit: Nous faisons un logiciel graphique 2D / 3D assez complexe qui est une plate-forme multi-plate-forme Mac / Windows en C ++.
17 Réponses :
Développement axé sur les tests . TDD aide à vérifier les erreurs de logique lors de la phase de développement.
Il y a beaucoup de consultants / entreprises qui ont des règles de codage pour vous vendre, vous n'auriez pas de difficulté à en trouver un. Cependant, un qui ne vous demande pas d'abord le champ que vous êtes dans (vous ne l'avez pas mentionné dans votre question) vous fournit l'huile de serpent.
@Daniel: fait un sens parfait. Les règles de conception Web sont différentes des règles intégrées.
Vous avez raison qu'il n'y a pas de balle d'argent, mais il y a beaucoup de pratiques qui s'appliquent assez bien à la plupart des domaines.
@Benrick @Daniel Je parle comme une personne qui travaille avec des développeurs de logiciels incorporés critiques (plutôt confidentiels. "Incolidée" rend leurs besoins particuliers et "critiques" les rendent particuliers à nouveau à l'intérieur "intégré").
Typiquement, le niveau de précision / exigeance dans les normes / processus de codage est directement connecté au niveau de sécurité requis. E.G., si vous travaillez à l'aérospatiale, vous contrôlez étroitement à peu près tout. Mais, à l'autre bout du spectre, si vous travaillez sur un site de forum de jeu informatique ... Si quelque chose se casse, pas de biggie. Vous peut avoir Slop. Alors YMMV, selon votre champ.
Le livre classique sur le codage est le code complet 2e édition, par Steve McConnell. Demandez à une équipe de copier et à recommander fermement que vos développeurs l'achètent (ou demandez-la de les obtenir pour eux). Cela satisfera probablement 70% des questions stylistiques. CC traite de la majorité des cas de développement.
EDIT:
logiciel graphique, C ++, Mac / Windows.
Puisque vous faites des travaux multiples-plate-forme, i vous recommanderait d'avoir un processus automatisé "Compile-On-Checkin" pour votre Mac (10,4 (peut-être), 10,5, 10,6) et Windows (XP (peut-être), Vista, 7). Cela garantit votre logiciel au moins compile et vous savez quand ce n'est pas le cas.
Votre contrôle source (que vous êtes utiliser, je suppose), devrait prendre en charge la succursale et votre stratégie de ramification peut également refléter la plateforme-ness. Il est également avantageux d'avoir des branches principales, des branches de devir et des branches expérimentales. Ymmv; Vous aurez probablement besoin de iTER à cela et de consulter avec des personnes qui connaissent la gestion de la configuration.
Comme il est C ++, vous voudrez probablement exécuter Valgrind ou similaire à savoir s'il y a une fuite de mémoire. Il existe des analyseurs statiques que vous pouvez obtenir: je ne sais pas à quel point ils sont efficaces à l'idiome moderne C ++. Vous pouvez également investir dans l'écriture de certains wrappers pour aider à regarder des allocations de mémoire.
Concernant C ++ ... Les livres efficaces C ++, plus efficaces C ++ et efficaces STL (tous de Scott Meyers) devraient être sur l'étagère de quelqu'un, ainsi que moderne C ++ par Andrescu. Vous trouverez peut-être également le livre de Lippman sur le modèle d'objet C ++ utile, je ne sais pas.
hth.
2ème le mouvement de code complet. J'étais sur le point de le poster moi-même.
Ithink Votre réponse est excellente, mais je code strictement tout ce que je fais. Coder strictement avec chaque chose me garde dans la pratique. De plus, étant donné que les petites applications sont plus simples, j'apprends des choses que je n'aurais pas si j'ai écrit du code bâclé. Comme l'autre jour, j'ai trouvé cela, à Perl, vous pouvez ajouter à une liste que vous êtes itération. Pourquoi je ne le savais pas déjà après 10 ans de développement Perl, je n'ai aucune idée.
+1 Pour le contrôle de la source, surtout le contrôle de source distribué.
@Elizabeth: Je ne suis pas préconisant code bâclé. Je notant simplement que la barre de qualité / de formalité / processus / de strictisme se déplace beaucoup plus haut que vous allez vers des systèmes critiques de vie. Vous pouvez toujours sauter haut; Parfois, vous devez sauter haut. :-)
Ce message de blog décrit beaucoup de pratiques communes de Programmation médiocre . Ce sont quelques-unes des problèmes potentiels que vous avez équipe a. Il comprend une explication rapide de la "meilleure pratique" pour chacun.
Vous ne mentionnez aucune langue et, bien qu'il soit vrai que la plupart des normes de codage sont indépendantes de la langue, cela vous aidera également à votre recherche. Sur la plupart des entreprises, j'avais travaillé, ils ont des normes de codage différentes pour différentes langages de programmation. Donc, mes conseils seront:
Maintenant, la logique derrière ceci est la suivante: la plupart des problèmes de la mise à jour d'une norme de codage à partir de zéro sont l'acceptation du développeur. Chacun de nous a un moyen de faire des choses et ça craint quand quelqu'un de l'extérieur croit une façon de faire des choses est meilleure d'une autre. Donc, si les développeurs comprennent la logique et le but des normes de codage, vous disposez de la moitié du travail effectué. L'autre chose est que les normes devraient être conçues et créées spécifiquement pour les besoins de votre entreprise. Il y aura des choses qui auront un sens, et certains qui ne le font pas. Avec l'approche ci-dessus, vous pourriez discriminer les personnes. L'autre chose est que les normes devraient pouvoir changer au fil du temps pour refléter les besoins de la société. Une norme de codage devrait donc être un document de vie.
Obtenez tout le monde à lire et à discuter de diverses normes et directives. Je suggère (aussi bien Stroustrup) suggère le Normes de codage de frappe de frappe conjointe < / a>. Demandez à vos développeurs de classer les directives qui figurent entre
avoir les longues discussions techniques et régler sur un ensemble pour l'équipe à adopter.
Les normes de codage JSF C ++ sont disponibles dans le format .pdf ici: www2. Recherche.att.com/~bs/jsf-av-rules.pdf
La première chose à prendre en compte lors de l'ajout de normes de codage / de meilleures pratiques est l'effet qu'il aura sur le moral et la cohésion de votre équipe. Les développeurs représentent généralement toutes les pratiques qui leur sont imposées même s'ils sont de bonnes idées. Les problèmes de personnes doivent être adressés à un grand changement pour réussir.
Vous devrez impliquer votre groupe dans l'élaboration des normes et essayer de parvenir à un consensus. Cela dit, vous ne recevrez jamais d'accord universel sur quoi que ce soit, vous devrez donc équilibrer le consensus et obtenir des normes. J'ai vu des combats majeurs sur quelque chose d'aussi simple que des onglets par rapport aux espaces dans la source.
Le meilleur livre que j'ai vu pour les directives C / C ++ dans des projets compliqués est Conception logicielle C ++ à grande échelle . Ce livre avec Code complet (qui est un Les classiques indispensables) sont de bons points de départ.
A propos des onglets contre des espaces: il vaut parfois des combats majeurs. :) Les gens reformatant constamment le code avec des onglets / des espaces peuvent faire la fusion des succursales vraiment désagréables.
Je suis complètement d'accord que vous devriez choisir l'un ou l'autre. Évidemment, les espaces valent mieux que les onglets :)
Une chose que vous devriez avoir des règles sur la norme de nommage. Cela rend la vie plus facile pour les gens tout en ne faisant pas vraiment invasion.
Autre que cela, je devrais dire que cela dépend du niveau de votre équipe. Certains ont besoin de plus de règles que d'autres. Les meilleures personnes sont, moins elles ont besoin de "soutien" des règles.
Si vous souhaitez un ensemble complet de règles de codage pour contrôler tous les détails, vous allez dépenser beaucoup de temps à discuter des règles et des exceptions aux règles et à ce que vous devriez écrire des règles. J'irais avec quelque chose déjà écrit à la place.
Si vous êtes préoccupé par la qualité, une chose que vous pourriez faire cela ne concerne vraiment pas les règles, est la suivante: Bâtiment et tests automatisés. Cela m'a beaucoup aidé. Une fois que vous avez trouvé un problème, cela aide vraiment à avoir un environnement où vous pouvez écrire un test pour vérifier le problème. Fixez le problème, puis ajoutez facilement votre test à une suite de test automatique qui veille à ce que le type de problème ne puisse pas revenir sans être repéré. Alors assurez-vous que ceux-ci courent souvent. De préférence chaque fois que quelqu'un vérifie quelque chose dans.
Si vous décidez d'avoir des normes de codage, vous voulez faire très attention à ce que vous avez mis. Si le document est trop long ou se concentre sur des détails stylistiques arbitraires, il sera simplement ignoré et personne ne la dérangera de le lire. Souvent, beaucoup de ce qui se passe dans les normes de codage n'est que les préférences de la personne qui a écrit le document (ou certaines normes qui ont été copiées sur le Web!). Si quelque chose est dans la norme, il doit être très clair pour le lecteur comment il améliore la qualité et pourquoi elle est importante.
Je dirais qu'une grande partie de ce qui rend le code lisible est de faire de la conception plutôt que de la disposition du code. J'ai vu beaucoup de code qui adhérerait aux normes, mais il est toujours difficile de lire (des méthodes vraiment longues, une mauvaise nommage, etc.) - Vous ne pouvez pas avoir tout ce que les normes, à un moment donné, cela revient à l'homme qualifié et discipliné vos développeurs sont - faites ce que vous pouvez accroître leurs compétences.
Peut-être plutôt qu'un document de normes de codage, essayez de faire en savoir plus sur le bon design (plus facile à dire qu'à faire, je sais). Faites-leur conscience des choses comme les principes solides, comment séparer les préoccupations, comment gérer les exceptions correctement. S'ils conçoivent bien, le code sera facile à lire et il n'aura pas d'importance s'il ya suffisamment de lignes blanches ou que les accolades bouclés sont au bon endroit.
Obtenez des livres sur les principes de conception (voir deux recommandations ci-dessous). Peut-être obtenir l'équipe à faire des ateliers pour discuter de certains sujets. Les amener peut-être collectivement à écrire un document sur les principes pourraient être importants pour leur projet. Quoi que vous fassiez, assurez-vous que c'est l'équipe dans son ensemble qui décide quelles sont les normes / principes.
http://www.amazon. Co.uk/prinples-Patterns-Practs-Robert-Martin/DP/0131857258/ http://www.amazon.co.uk/ Clean-Code-manuel-logiciel-artisanat / DP / 0132350882
Si votre cadre nécessite certaines règles de bien fonctionner, mettez ceux-ci dans votre norme de codage.
Ces bases sont bonnes pour la plupart des dimensions de l'industrie ou de l'équipe:
Vous ne pouvez pas vous tromper avec ces bases. Construisez à partir de là avec de nouveaux membres de l'équipe qui ont été là et ont fait cela. Je suggérerais fortement la programmation par paire une fois que vous avez ces gars de l'équipe. C'est le meilleur moyen d'infecter les personnes avec les meilleures pratiques.
Bonne chance à vous!
N'écrivez pas vos propres standards à partir de zéro.
Il y a plusieurs chances que cela puisse déjà définir ce que vous voulez déjà et que vous êtes plus complet que vous ne pouviez proposer vous-même. Cela dit, ne vous inquiétez pas trop si vous n'allez pas d'accord à 100% avec celui-ci sur des questions mineures, vous pouvez échanger dans certaines parties des autres ou vous appeler une infraction à un avertissement plutôt qu'une erreur - en fonction de vos propres besoins. . (Par exemple, certaines normes lanceraient un avertissement si la longueur d'une ligne est supérieure à 80 caractères, je préfère au plus 120 comme une limite difficile, mais assurez-vous qu'il y avait une bonne raison - la lisibilité et la clarté par exemple - S'il y avait> 80).
En outre, essayez de trouver des méthodes automatisées de vérifier votre code par rapport à la norme - y compris vos propres changements mineurs au besoin.
Les critiques de code ont été démontrées pour fournir des avantages significatifs à la qualité du code, encore plus que les tests traditionnels. Je suggérerais d'avoir l'habitude d'accomplir des révisions de la conception et des codes de routine; Le nombre d'étapes à laquelle des examens sont effectués, la formalité et les détails des examens, et le pourcentage de travail sous réserve de contrôle peut tous être définis en fonction de vos besoins en entreprise. Les normes de codage peuvent être utiles lorsqu'elles sont correctes (et si le code de tout le monde ressemble également, il est également plus facile de revoir), mais où vous mettez vos accolades et à quelle distance vos blocs d'indentement ne vont pas vraiment affecter les taux de défaut.
Aussi, il vaut la peine de vous familiariser et de vos pairs avec le concept de dette technique et de bit de travail à la redéfinition et d'améliorer les parties du système lorsque vous entrez en contact avec eux. Toutefois, à moins que vous ne disposiez de tests et / ou de processus d'unité complètes en place pour assurer une qualité de code élevé, cela peut ne pas aider les choses.
Étant donné que ceci est le débordement de la pile, une personne doit renvoyer Le test de Joel . J'aime automatiser autant que possible, alors en utilisant LINT est également un must.
Outre les livres déjà recommandés, je mentionnerais également
Normes de codage C ++: 101 règles, directives et meilleures pratiques de Sutter et Andrei Alexandrescu (Paperback - 4 nov, 2004)
auteurs bien recommandés. Je ne l'ai pas lu moi-même, mais je suis sûr que c'est bien.
Si vous programmez sur vb.net, assurez-vous que option explicite et
J'aime beaucoup:
Misra C standard (c'est un peu strict tho 'mais les idées contiennent pour C ++)
et hi-integrity's http://www.codingstandard.com/hicppcm/index.htmlled > Norme C ++ qui emprunte lourdement de MISRA
LDRA (un outil d'analyse statique) utilise ces normes pour noter votre travail (ce que je n'utilise pas comme c'est cher), mais je peux garantir une bonne exécution de CPPCheck comme un bon vérificateur d'analyse statique «GRATUIT / LIBRE».