Question

Je suis à un moment de ma carrière indépendante où j'ai développé plusieurs applications Web pour les petites et moyennes entreprises qui prennent en charge des tâches telles que la gestion de projet, les réservations / réservations et la gestion des e-mails.

J'aime le travail, mais je constate que mes applications finissent par atteindre un point où la surchauffe de la maintenance est très élevée. Je repense au code que j'ai écrit il y a 6 mois et constate que je dois passer un certain temps à réapprendre comment je l'ai codé à l'origine avant de pouvoir apporter une correction ou des ajouts de fonctionnalités. J'essaie de m'exercer à utiliser des frameworks (j'avais déjà utilisé Zend Framework et j'envisage Django pour mon prochain projet)

Quelles techniques ou stratégies utilisez-vous pour planifier une application capable de gérer un grand nombre d’utilisateurs sans casser les tâches tout en maintenant le code propre afin de le maintenir facilement? Si quelqu'un a des livres ou des articles à recommander, cela serait également très apprécié.

Était-ce utile?

La solution

Bien qu'il existe certainement de bons articles sur ce sujet, aucun d'entre eux ne remplace l'expérience réelle.

La maintenabilité n’est rien que vous puissiez planifier, sauf sur de très petits projets. C'est quelque chose dont vous devez vous occuper pendant tout le projet. En fait, créer à l'avance des charges de classes et de code d'infrastructure peut générer un code encore plus difficile à comprendre que le code spaghetti naïf.

Mon conseil est donc de nettoyer vos projets existants en les restructurant en permanence. Examinez les éléments difficiles à modifier et cherchez des solutions plus simples, plus faciles à comprendre et à ajuster. Si le code est même trop mauvais pour cela, pensez à le réécrire à partir de zéro.

Ne démarrez pas de nouveaux projets et attendez-vous à ce qu'ils aboutissent, simplement parce que vous avez lu plusieurs articles ou utilisé un nouveau cadre. Au lieu de cela, identifiez les échecs de vos projets existants et corrigez leurs problèmes spécifiques . Chaque fois que vous devez modifier votre code, demandez-vous comment le restructurer pour prendre en charge des modifications similaires à l'avenir. C’est ce que vous devez faire quand même, car il y aura des changements similaires dans le futur.

En faisant ces refactorings, vous tomberez sur diverses questions spécifiques auxquelles vous pouvez poser et lire des articles. De cette façon, vous en apprendrez davantage que par le simple fait de poser des questions générales et de lire des articles généraux sur la maintenance et les frameworks.

Commencez à nettoyer votre code aujourd'hui . Ne le confiez pas à vos projets futurs.

(Il en va de même pour la documentation. Les premiers documents de chacun étaient très mauvais. Après plusieurs mois, ils s'avéraient trop verbeux et remplis de choses sans importance. Complétez donc la documentation avec des solutions aux problèmes que vous réellement

Autres conseils

Je recommanderais honnêtement de consulter Martin Fowlers Modèles d'architecture d'application d'entreprise . Il aborde de nombreuses manières de rendre votre application plus organisée et plus facile à gérer. De plus, je vous recommanderais d'utiliser des tests unitaires pour vous donner une meilleure compréhension de votre code. Le livre de Kent Beck sur le développement piloté par les tests est une excellente ressource pour apprendre à traiter changer votre code par des tests unitaires.

Pour améliorer la facilité de maintenance, vous pouvez:

  • Si vous êtes le seul développeur, adoptez un style de codage et respectez-le. Cela vous donnera confiance plus tard lorsque vous naviguerez dans votre propre code concernant des choses que vous auriez pu faire et des choses que vous ne voudriez absolument pas. En sachant où chercher, quels éléments rechercher et quels éléments ne pas rechercher, vous gagnerez beaucoup de temps.

  • Prenez toujours le temps de mettre à jour la documentation. Inclure la tâche dans le plan de développement; inclure cette heure dans le plan dans les modifications ou les nouvelles fonctionnalités.

  • Gardez la documentation équilibrée: des diagrammes de haut niveau, des commentaires significatifs. Les meilleurs commentaires indiquent qu'il est impossible de lire le code lui-même. Comme pour des raisons professionnelles ou "pourquoi" derrière certains morceaux de code.

  • Incluez dans le plan l’effort de mise à jour de la structure du code, des noms de dossiers, des espaces de noms, des noms d’objets, de variables et de routines, afin de refléter ce qu’ils font réellement. Cela contribuera grandement à améliorer la maintenabilité. Appelez toujours un "chat". Évitez les gros morceaux de code, structurez-le avec les moyens disponibles dans la langue de votre choix, attribuez-leur des noms significatifs.

  • Couplage faible et cohérence élevée. Assurez-vous de connaître les techniques permettant d’atteindre ces objectifs: conception par contrat, injection de dépendance, aspects, modèles de conception, etc.

  • Du point de vue de la gestion des tâches, vous devez estimer plus de temps et facturer des taux plus élevés pour les travaux non continus. N'hésitez pas à informer le client que vous avez besoin de temps supplémentaire pour effectuer de petites modifications non continues réparties dans le temps, par opposition à des projets continus plus importants et à une maintenance continue, car les frais d'administration et d'analyse sont plus importants (vous devez gérer et analyser chaque modification, y compris son impact). sur le système existant séparément). Un des avantages que votre client va obtenir est une plus longue durée de vie du système. L'autre est une documentation précise qui préservera leur option de demander l'aide de quelqu'un d'autre s'ils le souhaitent. Les deux protègent les investissements des clients et constituent de solides arguments de vente.

  • Utilisez le contrôle de source si vous ne le faites pas déjà

  • Conservez un journal détaillé de tout ce qui a été fait pour le client, ainsi que de toute communication importante (un simple ordinateur ou un CMS sur papier). Actualisez votre mémoire avant chaque affectation.

  • Tenez un journal des problèmes laissés en suspens, des idées, des suggestions par client; rafraîchissez à nouveau votre mémoire avant de commencer une mission.

  • Planifiez la manière dont le support post-implémentation sera effectué, discutez-en avec le client. Faites vos systèmes sont faciles à entretenir. Planifiez le paramétrage, les outils de surveillance et les contrôles de cohérence intégrés. Vendez au client une assistance post-implémentation dans le cadre du contrat initial.

  • Développez en embauchant, même si vous avez besoin de quelqu'un juste pour fournir ce support post-implémentation, faites les bits admin.

Lectures recommandées:

Le conseil le plus important que je puisse donner après avoir contribué à transformer une ancienne application Web en une application Web extrêmement disponible et très demandée consiste à tout encapsuler. , en particulier

.

  1. Servez-vous des principes et des frameworks MVC appropriés pour séparer votre couche de vision de votre logique métier et de votre modèle de données.
  2. Utilisez une couche de persistance robuste pour ne pas coupler votre logique métier à votre modèle de données
  3. Planifiez le comportement sans état et asynchrone.

Voici un excellent article sur la manière dont eBay aborde ces problèmes http://www.infoq.info/articles/ebay-scalability-best- pratiques

  1. Utilisez un système framework / MVC. Plus votre code est organisé et centralisé, mieux c'est.

  2. Essayez d’utiliser Memcache. PHP a une extension intégrée, il faut environ dix minutes pour le mettre en place et vingt autres pour mettre votre application. Vous pouvez mettre en cache tout ce que vous voulez - je cache tous mes enregistrements de base de données - pour chaque application. C'est errant.

  3. Je vous recommanderais d'utiliser un système de contrôle de source tel que Subversion si ce n'est déjà fait.

Vous devriez peut-être envisager d'utiliser SharePoint. C'est un environnement qui est déjà conçu pour faire tout ce que vous avez mentionné, et qui comporte de nombreuses autres fonctionnalités auxquelles vous n'avez peut-être pas pensé (mais dont vous aurez peut-être besoin à l'avenir :-))

Voici certaines informations du site officiel.
Vous pouvez utiliser 2 environnements SharePoint différents: Windows Sharepoint Services (WSS) ou Microsoft Office Sharepoint Server (MOSS). WSS est gratuit et livré avec Windows Server 2003, tandis que MOSS n'est pas gratuit, mais comporte beaucoup plus de fonctionnalités et couvre presque tous les besoins de votre entreprise.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top