utilisation du contrôle de version
SVN est très commun, mais mercurial est plus beau, puissant et a un support gui solide.
développement piloté par les tests
eh bien, si vous faites des tests unitaires, vous êtes déjà du côté gagnant. pour les outils, c'est une question de choix. les tests doivent être aussi simples que possible, c'est la raison pour laquelle j'ai abandonné PHPUnit pour SimpleTest.
code de débogage
avec les tests unitaires, vous aurez à peine besoin de xdebug. J'utilise xdebug généralement pour le profilage uniquement. (consultez KCachegrind btw)
utilisation de diagrammes UML
le plus gros problème avec tout ce qui reflète la logique du code est qu'il faut beaucoup de travail manuel pour rester synchronisé. vous pouvez automatiser certaines tâches, mais ce n'est pas très utile, car vous voulez généralement utiliser uml avant d'avoir quelque chose. l'autre problème est que les outils de diagramme sont beaucoup plus difficiles à utiliser que le stylo et le papier ou un tableau blanc. utilisez uml si vous devez communiquer un problème avec plusieurs développeurs ou si vous avez besoin d'une abstraction pour vous-même. ("dia" est un bel outil gratuit. les outils de cartographie mentale sont également très pratiques pour le brainstorming, certains peuvent en fait rivaliser avec le stylo et le papier.)
utilisation de la POO pour le code maintenable et réutilisable
eh bien, oop fonctionne dans une certaine mesure. :) un bon conseil: composition> héritage. l'héritage est un outil puissant à réutiliser à première vue, mais l'entretien et le couplage lâche en souffriront. deuxième bon conseil: entretien> réutilisation. un système abstrait peut être très puissant, mais aussi difficile à maintenir.
utilisation de frameworks (comme Zend Framework pour php) pour le développement rapide d'applications
RAD est une bonne chose pour sortir votre application tôt. mais certains composants - en particulier l'ORM - tireront sur vos pieds, du moins en ce qui concerne l'évolutivité. le problème majeur ici est que vous liez votre logique de domaine pour travailler avec des objets, ce qui devient très difficile à prendre en compte si vous avez besoin d'une solution optimisée de base de données évolutive pure. Soyez conscient de cela et encouragez vos développeurs à utiliser la base de données sans couches d'abstraction de haut niveau. l'abstraction de la base de données est un mythe, orm est un mensonge.
BAISER
les nouveaux arrivants veulent généralement appliquer toutes ces meilleures pratiques, mettre en place des normes de codage, utiliser toutes les belles chaînes d'outils, peu importe. cela fonctionne pour certains développeurs, mais certains se heurteront à un blocage mental si les choses sont trop strictes. les tests unitaires et la scm sont vraiment un must have, mais quelqu'un de nouveau dans les tests unitaires doit vraiment apprendre sa valeur avant de l'adorer. N'en faites pas trop, appliquez les pratiques étape par étape et voyez comment cela fonctionne. KISS se résume également au code. parfois, la meilleure façon de résoudre un problème difficile est de le résoudre mal. vous avez besoin d'un algorithme de séparation à six degrés ? il suffit de choisir des amis au hasard. vous pouvez créer une application complète autour d'elle, avec une mauvaise logique. si le client décide finalement de l'abandonner, tout le monde économise beaucoup d'argent.
agile
en savoir plus sur les méthodologies agiles, la programmation extrême, la mêlée, etc. il existe de nombreux livres. n'importe quel livre améliorera votre équipe, mais il est préférable de faire participer chaque coéquipier.