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.
Contrôle de version: Si sur Windows, TortoiseSVN est le meilleur, le plus intuitif et le plus facile à utiliser de mon expérience.
Framework: CodeIgniter . Mains sur la meilleure plate-forme de développement Web pour PHP.
IDE: Netbeans est le meilleur IDE pour PHP que j'ai utilisé sur Windows.
Test unitaire: Il existe plusieurs options, une recherche google en révélera plusieurs. CodeIgniter dispose également de son propre testeur d'unités.
Débogueur: Xdebug.
Bibliothèque Javascript: Jquery
Programme FTP: FileZilla
Administration de la base de données: PhpMyAdmin
Wireframing : Balsimus Mockup, ou utilisez un tableau blanc.
Divers: utilisez WAMP sur Windows pour installer, démarrer, arrêter et redémarrer facilement apache, mysql et php en un seul paquet.
De plus, si vous allez travailler sur de nombreux sites Web différents, et la plupart de ces sites Web auront des fonctions communes comme l'inscription, la connexion / déconnexion, une section d'administration pour rechercher des utilisateurs, etc., je recommande de construire un petit projet dans n'importe quel cadre. vous choisissez et en utilisant ce projet comme base pour chaque nouveau projet que vous démarrez. Normalement, j'appelle ce projet «squelette». Si je vais commencer à travailler sur xyz.com, je copierais le répertoire squelette et le renommerais «xyz.com», remplirais certains fichiers de configuration, et j'aurais une copie de xyz.com avec certaines des fonctionnalités Déjà en train de travailler.
la source
Framework: CodeIgniter. Hands on the best web development platform for PHP.Franchement, ce sont des conneries. Si vous avez déjà utilisé symfony, rails ou django, vous verrez des problèmes majeurs. Il n'y a pas de structure de répertoire modulaire, pas d'interface de ligne de commande. Ensuite, vous avez des composants de base comme les formulaires et les modèles qui prennent beaucoup de code. Si vous connaissez des modèles de logiciels, vous verrez que le codeigniter craint beaucoup. À tout le moins, utilisez Kohana, qui est un IC fourchu et fait correctement après la mort de la communauté.Je suis principalement d'accord avec la publication de Click Upvote, mais si vous travaillez sur un site relativement grand, je recommanderais certainement d'utiliser le framework Symfony couplé à l'ORM Doctrine.
Si votre projet est prévu pour l'année prochaine, je dirais que prenez le temps d'investir dans Symfony2 et Doctrine2.
De plus, je ne saurais trop insister sur l'importance de développer sur un système basé sur Unix, Ubuntu est ma préférence et un excellent serveur Web. Je travaille principalement sur Windows mais je développe sur Ubuntu fonctionnant sur une machine virtuelle VMWare sur mon bureau (ou serveur lorsque je suis au travail).
Quant à l'IDE, je recommande fortement d'utiliser NuSphere PHPEd ou Storm PHP, malheureusement comme toutes les grandes choses, ils ne sont pas gratuits.
la source
L'utilisation du diagramme UML est agréable mais est entièrement facultative. Tous les diagrammes feraient l'affaire tant que votre équipe comprendrait ce qu'ils signifient. Essayer d'utiliser la norme que personne ne connaît vraiment bien peut entraîner des problèmes et du temps perdu.
Je recommanderais de commencer chaque page à partir d'une maquette ( http://balsamiq.com ) ou de demander à votre concepteur de la dessiner pour vous. Ne vous attendez pas à ce que les développeurs soient bons en esthétique visuelle et créent de bonnes pages à partir de nulle part.
Demandez à quelqu'un d'être affecté à la fonction de révision du code, si vous avez plusieurs membres de l'équipe sénior - faites-leur faire des révisions en rotation ( Commission de révision )
la source
Lorsque vous travaillez avec un travail collaboratif, vous avez besoin de:
• utiliser le contrôle de version: je pense que Git ou Subversion fonctionnera assez bien
• développement piloté par les tests: je commence à apprendre que c'est un must, mais ne le prenez pas à l'extrême
• code de débogage (xdebug pour php): xdebug est mon choix
• utilisation de diagrammes UML: Cela aide lorsque tout le monde a une connaissance pratique de la programmation OO et des modèles de conception, néanmoins c'est toujours une bonne pratique
• utilisation de la POO pour le code maintenable et réutilisable: Et la FLEXIBILITÉ, je pense que c'est l'aspect clé de la POO.
• utilisation de frameworks (comme Zend Framework pour php) pour le développement rapide d'applications: Mon conseil est SYMFONY, le premier framework php (pas une boîte à outils). Il a une très grande communauté, beaucoup de documentation et est entièrement implémenté sur php. Je travaille avec lui depuis un an et il se lie totalement avec la POO
• vous pouvez également avoir besoin d'un système pour suivre les bogues, les demandes de fonctionnalités, etc. comme: Mantis ou Track . Ces systèmes sont assez simples et directs. Ils vous permettent également de lier votre subversion et de relier vos commits à certaines fonctionnalités ou bugs que les gens publient.
Enfin, il est toujours important que vous dirigiez une équipe de développement pour organiser périodiquement de petites réunions afin que tout le monde connaisse l'état du système à un certain moment et peut-être que de cette façon, vous serez capable de planifier ou de voir comment les choses fonctionnent.
Dans mon entreprise, je dois envoyer un e-mail chaque jour pour dire sur quoi je travaille et s'il y a des complications.
Bonne chance!
la source
Éditer
J'ai oublié la chose la plus importante: les spécifications. Écrivez de vraies spécifications pour votre projet avant de toucher à un code. Gardez à l'esprit tous les diagrammes d'interaction utilisateur. Cela vous fera gagner des siècles.
la source
Contrôle de version Puisque vous travaillez en équipe, il est dans votre intérêt de choisir quelque chose de distribué. Vos candidats sont Git et Mercurial. Cela signifie que votre équipe peut valider localement sans interrompre le projet, mais toujours suivre son travail, puis envoyer ces validations au serveur central. Il est également beaucoup plus rapide et a moins de conflits de fusion car le code est suivi en tant qu'ensembles de modifications plutôt que révisions. Lisez le guide hginit (écrit par le co-fondateur de stack overflow pas moins) et vous comprendrez un peu plus ce qu'est un DVCS. http://hginit.com/
Vous devez également utiliser le référentiel pour le déploiement au lieu de rsync ou ftp.
Développement piloté par les tests Selon ce que vous faites, les tests peuvent perdre beaucoup de temps. Je ne dis pas que vous devriez l'ignorer complètement, pour les petits projets, c'est une surcharge. Si vous écrivez une bibliothèque ou un grand projet à long terme, écrivez bien des tests pour cela. Les tests aideront dans la phase de maintenance. Sachez que TDD ne trouve pas tous vos bugs. Il y aura des problèmes d'expérience utilisateur, des problèmes de mise en page, des problèmes de performances, etc.
Le débogage de Xdebug est fondamentalement votre seul choix ici. Il s'intègre bien avec Netbeans. Si vous ressentez le besoin d'imprimer des variables, vous devez utiliser un fichier journal. Utilisez la fonction de log des frameworks, c'est beaucoup plus sûr en production.
Planification / Diagrammes Si vous utilisez un bon cadre, vous ne devriez pas avoir besoin de faire trop de diagrammes détaillés. Restez simple et travaillez dans des cycles de version plus courts, il est facile de sur-planifier. Les exigences et les spécifications d'un projet sont appelées à changer, donc je n'y consacrerais pas tout votre temps. N'oubliez pas que la spécification du code EST au niveau le plus détaillé.
Utilisez votre outil de suivi des bogues (voir ci-dessous) pour diviser la spécification en tâches que vous pouvez attribuer aux membres de l'équipe. Utilisez un outil central pour documenter les projets, le bug tracker aura probablement un wiki.
Vous pouvez utiliser un outil comme Mysql Workbench pour concevoir des schémas de base de données dans des diagrammes et les exporter au format SQL.
Cadres et POO C'est probablement la partie la plus importante. Trouvez-vous un framework populaire qui soutiendra le développement rapide et la réutilisation du code. Certaines personnes n'aimeront pas que je dis cela, mais un cadre devrait dicter votre façon de travailler. Il doit fournir une structure pour qu'un développeur puisse changer de projet et savoir exactement où se trouve le contrôleur pour une certaine page, quelles sont exactement les variables du modèle et comment interroger le modèle. Certains cadres offrent ici trop de flexibilité et vous constaterez que les développeurs n'utilisent pas toujours le cadre de la même manière. J'aime la philosophie du python; il devrait y avoir une façon évidente de tout faire. C'est pourquoi j'aime django et rails, ils sont assez perspicaces et cela signifie que je peux regarder le code de quelqu'un d'autre et comprendre ce qu'il fait. Symfony ressemble à la meilleure option ici,
Il y a beaucoup de questions sur quel framework sur le débordement de pile comme celle-ci: /programming/2648/what-php-framework-would-you-choose-for-a-new-application-and-why
Suivi des bogues Obtenez votre équipe un bon traqueur de bogues qui est fait pour les développeurs. N'utilisez pas quelque chose de trop simplifié comme basecamp. Redmine et Unfuddle sont deux exemples d'excellents suiveurs de bogues, ils peuvent également suivre le temps et s'intégrer à vos référentiels. Votre équipe doit utiliser cet outil pour communiquer sur les problèmes plutôt que par e-mail ou messagerie instantanée. Cela facilite la tâche d'un nouveau développeur lorsqu'il existe un historique de bogues et de documents disponibles. Cet article explique exactement ce que tout bon traqueur de bogues doit faire et pourquoi. http://www.joelonsoftware.com/articles/fog0000000029.html
la source
Je recommanderais de regarder Bazaar pour le contrôle de version. Comparé à Git, il présente l'avantage majeur d'être facile à utiliser et à installer sur Windows, Mac OS et Linux. De plus, les commandes bzr sont très similaires à ses homologues svn, donc quelqu'un qui a déjà travaillé avec Subversion peut facilement utiliser Bazaar sans trop de courbe d'apprentissage. Je te regarde Git.
En dehors de cela, je suis fermement convaincu de ne rien imposer à vos développeurs. Cela étant dit, laissez-les utiliser l'IDE, le système d'exploitation, etc. qu'ils préfèrent.
En dehors de cela, je vous recommande fortement de faire des tests wirte pour tout votre code, peu importe à quel point c'est fastidieux.
La décision pour ou contre un imho du cadre n'est pas quelque chose que vous pouvez faire en fonction des recommandations formulées ici. Je vous suggère de répertorier celles qui vous semblent prometteuses en fonction de leurs fonctionnalités, puis d'écrire une petite application de test dans chacune d'elles. (Écrivez le même à chaque fois.)
la source